When mbed was first released this article inspired me to start using Eclipse as an offline IDE. It worked pretty brilliantly, being Eclipse as configurable as it is, and given OpenOCD debug is supported. But the thing is, at first mbed projects were straight C++, now with mbedOS it seems to me a large amount of… stuff, is being defined in .json files, which makes it kinda impossible for code completion to work properly and populates my code with a ton of undefined symbol warnings.
Is it my mistake, or the way Yotta environment was designed is really making it a lot dificult to integrate to it with standard C/C++ development tools?
I mean, why store pin labeling and things like that in a .json? If it was done in a standard .h file it would be much cleaner and… well standard.
Thanks James, I hadn’t realized that Eclipse was allready ‘supported’ out of the box!
I followed your instructions and now I’m able to open my project in Eclipse, using File>Import>General>Existing Projects into Workspace. But then I can’t find the source files, originally located in the <project_root>\source directory. And I’m guessing that’s because generated .project is rooted at <project_root>\build\<target>.
I found in here that extra argument -DCMAKE_ECLIPSE_GENERATE_SOURCE_PROJECT=TRUE ..\<path_to_source> should be used when using out-of-source builds. However this raises CMake Error: The source directory <path_to_directory> does not appear to contain CMakeLists.txt...
So I’m still not able to use Eclipse to develop my projects. Is yotta build --generate-only missing this or am I doing something wrong?
OK, thanks for reporting that! Definitely a bug – I’ll open an issue on yotta to track it (Source Files Missing from Generated Eclipse Project · Issue #622 · ARMmbed/yotta · GitHub). Possibly we could generate eclipse project files in the source directory instead, or this might be a bug in CMake itself: for yotta the “source” directory is technically the build directory, which refers to source files in a separate directory
yotta 0.11.0 released this morning as the fix for this
You can now do:
yotta build -G "Eclipse CDT - Ninja"
And it should generate a project file including the sources for the module you’re using. See this cmake guide for how to import and use the generated project.
However now when I try to yt build -G "Eclipse CDT4 - Ninja" I get the error below, and I’m not sure if it has to do with CMAKE generator or something else. I noticed yt build is able to compile same project sucessfully, though.
Info: Paths were edited for clarity
(workspace) C:\Users\[me]\Documents\[project-root]>yotta build -G "Eclipse CDT4 - Ninja"
info: generate for target: st-nucleo-f401re-gcc 0.2.0 at C:\Users\[me]\Documen
ts\[project-root]\yotta_targets\st-nucleo-f401re-gcc
-- Eclipse version is set to 3.6 (Helios). Adjust CMAKE_ECLIPSE_VERSION if this
is wrong.
GCC version is: 4.9.3
CMake Warning at C:/Users/[me]/Documents/[project-root]/yotta_modules/uvisor-lib/source/CMakeLists.txt:43 (message):
*******************************************************************
* WARNING (uvisor-lib): unsupported platform; your code will still
* work but no security feature is provided;
* UVISOR_DISABLED is set by default
*******************************************************************
suppressing warnings from mbed-hal-st-stm32cubef4
-- Configuring done
-- Generating done
-- Build files have been written to: C:/Users/[me]/Documents/[project-root]/build/st-nucleo-f401re-gcc
[154/156] Linking CXX static library y...ubef4\source\mbed-hal-st-stm32cubef4.a
FAILED: cmd.exe /C "cd . && C:\yotta\gcc\bin\arm-none-eabi-ar.exe -cr ym\mbed-h
al-st-stm32cubef4\source\mbed-hal-st-stm32cubef4.a @CMakeFiles/mbed-hal-st-stm32
cubef4.rsp && cd ."
C:\yotta\gcc\bin\arm-none-eabi-ar.exe: ymmbed-hal-st-stm32cubef4sourceCMakeFiles
mbed-hal-st-stm32cubef4.dirccbdd7a4028f10738500b05043ae53fbsourcestm32f4xx_hal_s
pi.c.o: No such file or directory
ninja: build stopped: subcommand failed.
error: command ['cmake', '--build', u'C:\\Users\\[me]\\Documents\\[project-root]\\build\\st-nucleo-f401re-gcc'] failed
Hmm, the .project file should still have been created – so if you import and do the build from within eclipse do you get the same error?
It seems possible this is related to path lengths hitting the limit (the hash in the filename implies CMake is trying to workaround the path length limit), so if you could also try the build in a very short path (like C:\somedir), that would be a useful datapoint!
Hi @jamcro01, sorry it took me so long to test it.
Moved the project to C:\blinky. yt build -G "Eclipse CDT4 - Ninja" yelds the same result.
The .project was created indeed, when i try to compile from within Eclipse i get this:
[154/156] Linking CXX static library ym\mbed-hal-st-stm32cubef4\source\mbed-hal-st-stm32cubef4.a
FAILED: cmd.exe /C "cd . && C:\yotta\gcc\bin\arm-none-eabi-ar.exe -cr ym\mbed-hal-st-stm32cubef4\source\mbed-hal-st-stm32cubef4.a @CMakeFiles/mbed-hal-st-stm32cubef4.rsp && cd ."
C:\yotta\gcc\bin\arm-none-eabi-ar.exe: ymmbed-hal-st-stm32cubef4sourceCMakeFilesmbed-hal-st-stm32cubef4.dirC_blinky-yotta-011yotta_modulesmbed-hal-st-stm32cubef4sourcestm32f4xx_hal_qspi.c.o: No such file or directory
ninja: build stopped: subcommand failed.
The file ym\mbed-hal-st-stm32cubef4\source\CMakeFiles\mbed-hal-st-stm32cubef4.dir\C_\blinky-yotta-011\yotta_modules\mbed-hal-st-stm32cubef4\source\stm32f4xx_hal_qspi.c.o actually exists, so I’m guessing some path issue. Maybe it is some backslash issue while using CMake in WIndows?
That did the trick for me! Now compilation works both from yotta console and Eclipse. Thanks @jamcro01.
There’s a minor issue with the path linking the source folder: it should be absolute path but it’s missing C:\ at the beginning, which causes eclipse to intially say it’s pointing to an non-existing location. Manually adding the missing C:\ fixed it.
Also, and I’m not sure if it can be solved somehow, pin ‘aliases’ like USBTX, USBRX or LED1 trigger Symbol cannot be resolved warning on the IDE. That may be because CDT is not prepared to look for them in the .json files they’re declared, is there some workaround?
The missing C:\ should be fixed easily, I will make another PR The symbols I’m a bit confused about: do the errors persist even after you’ve run the build once?
The definitions for these are generated in a header file which is included normally , so once you’ve built once (or if you have build-in-the-background enabled) I would have thought it’ll be picked up.
Applied the fix for source folder path, however the problem persisted. Taking a closer look at the .project file I see the generated path is using backslashes:
Manually changing that to forward slashes fixes the problem.
About the symbols not found, I’m only including mbed-drivers/mbed.h right now, but I had no luck searching the project folder for another header containing the definitions. The closest I got was yotta_config.h but it still missed the symbols Eclipose is complaining about.
mbed-drivers/mbed.h (or mbed-drivers/AnyAPI.h) should include these definitions indirectly. They are actually defined in the generated mbed-hal/[chip-]pins.array files which are included from this header.
To be clear is the build succeeding – it’s just the code-completion that’s failing? Or is the build also failing?
OK really sounds like I should install Eclipse in my windows VM to test this thoroughly
Yes, compilation suceeds and the generated binary runs fine too.
The issue is with code completion only. Checked those .array files and they’re all present, definitions are there too, however Eclipse seems to think YOTTA_CFG_HARDWARE_PINS is not defined. Which causes mbed-hal/chip_pins.array and mbed-hal/pins.array to not be included from GeneratedPinNames.h.
Got it working by including yotta_config.h from blinky.cpp which is located on the [project_root]/source folder:
Shouldn’t it be included indirectly by mbed-drivers/mbed.h too? yotta_config.h not being included could cause some other side-effects on the IDE behavior right? I’m not familiar with Ninja, is it using it’s own set of include paths during compilation?
I’m sorry I can’t solve this on my own, I’ll try to gather more knowledge about Ninja / CMake.
yotta_config.h is included on the build command line (–preinclude). Possibly it would be better to include it explicitly where it’s used (and to make that possible with a more generic path), which would solve this.
I’ve updated to the latest version of Yotta and after running:
yotta init
yotta target frdm-k64f-gcc
yotta build -G “Eclipse CDT4 - Ninja”
The .project file is created in build\frdm-k64f-gcc. So, when I import it into Eclipse, the source files are not accessible. Is there something I’m doing wrong?
There should be a linked folder in your project tree, named something like projectName-source. If that’s the case, and Eclipse complains about an invalid path, on Windows, try replacing the backslashes in the generated path.
Yup there should be a linked folder, which will work even though the generated project file is in a subdirectory (it’s a link to the source folder, not to the whole top-level directory).
Let us know if that isn’t there/working properly with the latest yotta (0.12.2) (with this version the correct slashes should be used in the path in the project file).
The current version should be an absolute path, but possibly there is still some issue preventing that from working correctly
Inclusion of the config header so that pin definitions complete correctly is an unsolved issue: you could add an explicit #include "../../yotta_config.h" to workaround it for now, but that’s something that may cause problems if left lying around, so don’t do it lightly! The best fix is probably to avoid using a pre-include flag for that header, and instead require people to explicitly include it. (tracking this here)
The build system should be correctly aware of everything in your dependencies, so you should be able to include things normally, even though the dependencies source files aren’t in the linked folder. Is the problem you have that they aren’t visible, or that including doesn’t work? (We could possibly add additional linked folders for the dependencies, and other directories).
