Mbed Studio 1.4.2 linter bugs

I am still seeing the same problem with 1.4.3 and GCC 9 2020-q2-update
I am using a Nucleo F429ZI

Using the latest Mbed Studio version (1.4.3) I no longer experiment the described issues. Thanks for the fix!

I spoke too fast… After the latest update I’m getting the following error when compiling for a NUCLEO-F103RB target:

{
	"resource": "file:///c%3A/Users/user/Mbed%20Programs/project/main.cpp",
	"owner": "file:///c%3A/Users/user/Mbed%20Programs/project/main.cpp",
	"code": "pp_hash_error",
	"severity": 1,
	"message": "In included file: \"Compiler generates FPU instructions for a device without an FPU (check __FPU_PRESENT)\"",
	"source": "clang",
	"startLineNumber": 5,
	"startColumn": 9,
	"endLineNumber": 5,
	"endColumn": 17
}

Just for info
Updated libraries now get Error about FPU Nucleo f103rb - Mbed OS - Arm Mbed OS support forum

BR, Jan

1 Like

please post the solution for printf like issue

Hello @mgordon01,

Is there any update of this bug?

I am still having the same issue: false intellisense report when using GCC.
Eg: In included file: 'stdint.h' file not foundclang(pp_file_not_found)

Setup:

Build and flash works, but Intellisense keep throwing errors.

Regards.

EDIT: Same intellisense errors using GCC 9 2020-q2-update as written here.

EDIT2: I confirm that rolling back to MbedStudio 1.4.1 make intellisense work again with GCC.

EDIT3: The website documentation has been update recently (March 1st), new recommended version is GCC 10.3-2021.07. Intellisense still not working with this version of the toolchain.

Still not working using new version of Mbed Studio (1.4.5) :

Hello,

That does not surprise me in the slightest. Two years on, some things still are not fixed. See this post here for instance: https://forums.mbed.com/t/target-restrict-size-doesnt-pad-out-the-bin-file/14553/3. Simply ridiculous.

The fact that I am still getting notifications from this forum two years after last working with this despicable piece of software, says a lot to me.

If you are thinking of using the bootloader feature of Mbed OS, do not bother, that’s all.

Kind regards,

Tijn Losekoot



|
Target.restrict_size doesn’t pad out the .bin file
I use target.restrict_size like so in the mbed_app.json file. { “target_overrides”: { “MAX32630FTHR”: { “target.device_name”: “MAX32630”, “target.bootloader_supported”: true, “target.pad_to_restrict_size”: true, “target.restrict_size”: “0x16000” } } } I even added the extra parameter “pad_to_restrict_size” after coming across this old Github post: Add padding up to restrict_size by statropy · Pull Request #11043 · ARMmbed/…
forums.mbed.com
|

  • | - |

======================================================================================================================================== E-maildisclaimer: Aan dit bericht, waaronder ook de eventuele bijlagen worden bedoeld, kunnen geen rechten worden ontleend. Dit bericht is uitsluitend bestemd voor de geadresseerde en bevat persoonlijke en vertrouwelijke informatie. Het bekend maken, kopieren en verspreiden van een bericht dat niet voor u bestemd is, is niet toegestaan. Als u dit bericht per ongeluk heeft ontvangen, verzoeken wij u vriendelijk het direct te vernietigen en de afzender te informeren. Twijfelt u over de juistheid of volledigheid van dit bericht? Neem dan contact op met de afzender. ======================================================================================================================================== This message and any associated attachments cannot be deemed as legally binding under any circumstances. This message is intended for the exclusive use of the person(s) mentioned as recipient(s) and contains personal and confidential information. Directly or indirectly copying, disclosing, distributing, printing, publicising and/or in any way using this message or any part thereof by any means is strictly prohibited if you are not the intended recipient(s). If you have received this message in error, please notify the sender and delete this message from your system immediately. If you are in doubt regarding the correctness and/or completeness of this message, please contact the sender.

Hello @Tijn_Losekoot,

Thanks for the input,
Indeed I think you’re right.

The fact that linter/IntelliSense doesn’t work correctly with GCC (and with custom targets) is a major drawback for us.

I liked the idea to have an “out of the box” IDE to instantly play with MbedOS.
It’s a good way to easily introduce the software to students or collaborators.

Unfortunately, MbedStudio is not usable for us in its current state.
And I do not want to use the online “Keil Studio Cloud”.

So right now, among solutions to write code for MbedOS, we mainly use VSCode after typing mbed export -i vscode_gcc_arm in the root of the project.
Clion is also an excellent IDE using mbed export -i cmake_gcc_arm.
But in both cases, people must be comfortable using mbed in command line for compiling or uploading.

The following is off-topic:

Additionally to the post you provide, I still don’t understand why “Mbed CLI 1” was frozen, when “Mbed CLI 2” (or mbed-tools) is still in beta, and rarely updated (Last true closed issue: september 2021. Last merged PR: 1 year ago. Last real repo update: 1 year ago).
We’re still using Mbed CLI 1, even with MbedOS 6.17, and fortunately it still works great (provided you use a .mbedignore file to accelerate building).

Generally speaking, as said in previous post and messages on this forum (here, here, here … ), MbedOS development seems to be on hold. And it is difficult to seek a clear response from arm about the future of the software.

A lot of people are using Mbed, it’s an “easy” embedded OS, a big step from Arduino, but not as big as moving to Zephyr (for example). It’s a good in-between, It would be a shame if arm stop working on it. Nevertheless, MbedCE seems to be a promising community fork/evolution.

Best regards.

1 Like