Improved Eclipse usage

[rjmaris]

A generic disadvantage of using Eclipse according to the instructions on the Debugging docs page is the fact that the build directory as a subdirectory of the source directory would not be supported well in eclipse (hm, I don't see that point). Well, I think that the main problem is that the two files .project and .cproject are in the build subdirectory after applying -G"Eclipse CDT 4 - Ninja". Which also means that configuration is lost after each clean build. Normally, these files are in the project root.

Some time ago, I created symlinks to achieve that boards and src appear as a subdirectory of build in order to make indexing work beyond the source code itself.
Far better is it to move the two eclipse config files (and .settings folder) into the project root and delete that "@build" at line 3 of .project.
(however it may make sense to incidentally repeat the -G"Eclipse CDT 4 - Ninja" procedure, when major changes are executed)

Remaining problems:

• The macros in prj.conf should anyway be imported. Without that, whole code sections may become a gray background and these sections are excluded from indexing.
• The indexing marks a couple of apparent errors that are no errors at all. Most of them symbols that could not be resolved (but F3 may still navigates to the source file where the symbol is defined - important while one is going to understand what's under the hood in Zephyr).

Just as a sidenote: I'm not sticked to Eclipse. Another IDE could be used as well. But the docs page Tools and IDEs don't tell anything.
Just before writing this, I watched the video that summarizes the new 3.6 release. I was not able to identify the IDE that is used in the video.

[kartben]

Just a quick reply to your to sidenotes:

_Just as a sidenote: I'm not sticked to Eclipse. Another IDE could be used as well. But the docs page Tools and IDEs don't tell anything.

Hoping to get CLion documentation added soon #60204
Also hoping to refresh the Eclipse CDT instruction soon (have started something here a while ago but I need to find some time to finish it)

Just before writing this, I watched the video that summarizes the new 3.6 release. I was not able to identify the IDE that is used in the video._

I am using VS Code in this video.

[rjmaris]

Follow-up after some experiences with CLion:
After I found that peripheral view does only show peripheral register values but do not allow to edit them (when program execution is halted), I contacted the support. Indeed this is not possible and is said to be in a feature request phase (https://intellij-support.jetbrains.com/hc/requests/6123440).
Immediately after notifying that, I was asking myself whether CLion supports live (non-intrusive) view of variables. Years ago I was very happy with this feature using an eclipse clone by Code Red (later aquired by NXP and renamed to LPCxpresso). It was the first time I was able to run an Eclipse-based IDE with non-intrusive live view/watch of variables (with LM3S-family).

I am aware now that a commercial product (CLion) would never expand to a complete forked family of Vendor-tied IDEs. At the same time I am also aware that I should take a look at STM32cubeIDE. Also a 'customized' Eclipse fork (with supposed optimal vendor related debugging features). After I discovered that this Eclipse clone supports CMake projects, I got to work on it. Final result: I am excited! build within the IDE (as is the case with CLion), modifyable peripheral registers, but especially: excitingly quick live view! Variables that hold a representation of ADC values update on a rate of clearly beyond 10 Hz!

Until the weekend I have priority in coding - after that I'll document the steps to get it working in STM32CubeIDE.

[rjmaris]

Thanks for this information. After having read a really short comparison of Eclipse and CLion (https://stackshare.io/stackups/clion-vs-eclipse), I decided to install the latter, due to the notified integration with CMake as well as being specialized as C/C++ IDE. When it works okay, it would be worth the yearly charge for licensing. I followed the instructions according to your #60204 link and I got it working, building & debugging from within the IDE. In this case, instead of Segger, ST-link V3 is used. In a separate discussion (because of ST target and project outside of `zephyr` tree) I'll report some experiences & topics to take into attention. This does not mean yet that Eclipse is out of focus. Am 05.03.2024, 18:30 Uhr, schrieb Benjamin Cabé ***@***.***>:

…

Just a quick reply to your to sidenotes: > > _Just as a sidenote: I'm not sticked to Eclipse. Another IDE could be used as well. But the docs >>page Tools and IDEs don't tell anything. Hoping to get CLion documentation added soon #60204 Also hoping to refresh the Eclipse CDT instruction soon (have started something here a while ago but I need >to find some time to finish it) > > Just before writing this, I watched the video that summarizes the new 3.6 release. I was not able >>to identify the IDE that is used in the video._ I am using VS Code in this video. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.

[kartben]

Great that you got it working!
@MarinaKalashina - you might be interested in hearing from early testers/adopters of the CLion instructions :)

[rjmaris]

According to what I mentioned end of last week, yet I'm going to describe a (very) successful implementation of Eclipse integration, using STM32cubeIDE. Which should more or less also work with comparable debugging capabilities when e.g. MCUxpresso is being used - all of them operating with good capabilities out of the box, including peripheral view and live view.

Introductory note: the instructions here (https://docs.zephyrproject.org/latest/develop/debug/index.html#debug-with-eclipse) seems to be obsolete when the steps as outlined hereafter are carried out. This also means: no (bloated) .project and .cproject in the build directory., but instead smaller project files in the target project directory.

It is supposed that the eclipse (STM32cubeIDE) workspace is anywhere on the system, not as part of the zephyrproject tree.
First, the standard instructions in AN5952, "How to use CMake in STM32CubeIDE" (search AN5952 on https://st.com), must be followed. E.g. from chapter 2.1 on - use case existing CMake project, 2.1.2), continuing with 3.1 (CMake build settings), where you can also set Other options. It shows that it is sufficient to only enter the -DBOARD=<your board> option. In the case of an out-of-zephyr(root) project, also add -DBOARD_ROOT=./ (as is also the case upon build
using commandline west). If you want another Build directory than config_default, please take care that the other name is also used in fields upon subsequent steps, e.g. debugger configuration.

After these steps are done, you should see <your project name> (in <a directory of the existing project>).
In order to prevent greyed out code sections beginning with #include CONFIG_<FEATURE>, one must tell Eclipse that autoconf.h (generated from prj.conf) is used in the indexer as follows: Project Properties C/C++ General->Preprocessor Include. Add the following path (Languages GNU C), CDT User Settings Entries: config_default/zephyr/include/generated/autoconf.h. Watch the addition as an Include File:

From now on, no other efforts except adding a debug configuration (not described in AN5952) are needed to start debugging. In short (with STM32cubeIDE): add new configuration based on STM32 C/C++ Application. In the Main tab, in the field C/C++ Application, config_default/zephyr/zephyr.elf should be entered. In the Debugger tab, select ST-Link (OpenOCD) or Segger or whatever. Other settings should already be okay.

The only remaining 'problem' is the fact that the underlying build process uses make. However, quick Ninja build can be established as follows:

In Project Properties, C/C++ Build, Tab Cmake Settings, the fixed Generator suggests that only make is supported. But then... add -G Ninja to Other options.
Then in the tab Builder Settings unset Use default build command and enter ninja in the
text field. Build location should be taken as is from former steps.
Finally in the tab Behavior, assure that only -C config_default (or another build directory) is
specified. Any extra VERBOSE=1 should be removed, because ninja throws an error with it.

The resulting hex file is verified to be the same as upon using west build.

Note: the decisive hints regarding the latter two tabs came from http://blog.peschla.net/2012/09/build-chromium-in-eclipse-with-ninja-and-clang/ (2012!). This old post suggests that no specific CMake Settings tab would be prerequisite in order to get it done as desired.

The screenshot below shows a shapshot of debugger usage with live view, in this case in a modbus application frontend that translates modbus addresses to addresses of VOLATILE registers, EEPROM area or e.g. OTP area. The values with yellow background changes when an mbpoll command is executed in a terminal.

[erwango]

@rjmaris This is a great post which I think could be really valuable to others. While I managed to make it work once to verify newly available cmake support in CubeIDE allowed to build Zephyr, I never took the time to document it.
If you feel like it, don't hesitate to contribute it directly in Zephyr documentation (I guess we could find a way to make it in a boards/st/common/stm32cubeide.rst which then could be made visible through boards documentations). And, if you don't want to do this yourself, you would allow to re-use this post by someone else to make it available in zephyr doc ?

[rjmaris]

@erwango I'd suggest to first try to arrange the same with MCUxpresso as well (next week, without debug config). I am experienced with this platform as well. I'd try also to install a Cmake plugin from the marketplace in the case that this appears to be required.
If that succeeds, one could present all of Eclipse related instructions onto a specific page dedicated to Eclipse based instructions for configuarion (and usage). With specific sections for each branded Eclipse and probably also original Eclipse.
I could contribute a text as above (with modified introduction) with RST syntax, but I'd suggest that any one collaborator commits that (under his or her name) since I don't fork the repository.