Loading...
 

Zephyr project on STM32

   Zephyr Workbench, a VSCode extension to manage Zephyr on STM32.
It enables users to easily create, develop, and debug Zephyr applications.
Main features:
  • Install host dependencies.
  • Import toolchain and SDK.
  • Create, configure, build and manage apps.
  • Debug STM32.
You can directly download it from the VSCode marketplace
For more details, visit the Zephyr Workbench

System Workbench for STM32


Creating and working with header files is confusing for users

I tried to create a new header file. So I right-clicked on Application/User inside the Project Explorer view, and created a new header file. Little did I know, that the file would be created in the folder PROJECT_LOC/SW4STM32//Application/User. In result, the header file was not found by the compiler. I expected it to end up in the same folder as main.c, but it didn’t. Next I tried to right-click on the Inc folder (which is only visible after unfolding the “Includes” inside the project). But there’s no right-click-menu to create header files.

Then I started to realize that all the *.c files that I see inside the Project Explorer are linked resources. To make matters worse, the structure in the Project Explorer doesn’t match the structure in the filesystem. Anyhow, I created the header file on the command line in the PROJECT_LOC/Inc folder. And behold, I could include it, the compiler found it, and I could edit it from Eclipse.

Except: making changes to the header file wouldn’t trigger the CDT indexer. For example, after adding a define in the header file and using the define in main.c, Eclipse would complain that the symbol is not defined. Building the project would work fine, but Eclipse wouldn’t stop complaining until I rebuild the CDT index manually (right click on project, index->rebuild). Basically, I have to rebuild the index every time I add or remove defines.

I believe the reason for the latter is that the include files are not linked to the project. So the indexer somehow doesn’t consider them.

I believe all of the above issues could be resolved and the user experience could be much improved, if you would not link individual files, but if you would link whole folders. A list of folders to be linked would be

  • PROJECT_LOC/../../Src
  • PROJECT_LOC/../../Inc
  • PROJECT_LOC/../../Drivers
  • PROJECT_LOC/../../Middlewares


Right clicking on the linked Inc folder would allow users to create new header files without a hassle.
Right clicking on the linked Src folder would allow users to create new C files without a hassle (the same issue as described for headers also exists for C files).
Also, editing header files would probably update the CDT index without manual intervention.

However, I couldn’t test my last claim right now, as my project seems broken since I edited some Eclipse files by hand. Also, every time I generate code, CubeMX will overwrite the .project file. It will again link every individual file.

I’d like to strongly suggest that you reevaluate the decision to have linked files (instead of linked folders). It seems to have quite unpleasant implications that may confuse even experienced (Eclipse) users.

Things are complicated by the fact that the .project file is in fact generated by CubeMX. So the generator of CubeMX would have to be changed, I guess.

It seems there is a bug, when I link the *.s file to the root folder of the project. Then the assembler is invoked with a non-existing path for some reason. After I link the *.s file to a subfolder of the project, everything is working fine.

So to summarize: I removed all the linked resources from the project and I only linked 1 file and 4 folders into the project:

  1. the *.s file (linked into a subfolder, see screenshot)
  2. Src folder
  3. Inc folder
  4. Drivers folder
  5. Middlewares folder


The project builds just fine. I can create header files by right-clicking the (linked) Inc folder and they also end up in the Inc folder in the filesystem. I can create new *.c files by right-clicking the (linked) Src folder, and they also end up in the Src folder in the filesystem. I can change defines in the header files and that properly triggers the CDT indexer. E.g. errors will be shown in other editors when the old macro name is used after the macro has been renamed.

Now the obvious drawback is that my .project file will be overwritten every time I generate code from CubeMX.
However, working with the project is so much more convenient now.


The issue I describe above is only present if the “Generate Under Root” option in STMCubeMX is deselected.
So enabling that option is an easy workaround for the problem.


 

Newest Forum Posts

  1. Монтаж камина с грилем в Москве - установка и барбекю by KpddomErorb, 2025-05-10 18:28
  2. SPI on Nucleo_STMH533RE by royjamil, 2025-05-04 20:13
  3. SPI on Nucleo_STMH533RE by higginsa1, 2025-03-25 07:37
  4. SPI on Nucleo_STMH533RE by royjamil, 2025-03-23 11:31
  5. SPI on Nucleo_STMH533RE by higginsa1, 2025-03-23 09:33
  6. Configuring DMA for ADC in SW? by sam.hodgson, 2025-03-04 12:58
  7. Build a project in "release" mode by info@creosrl.it, 2025-02-20 18:12
  8. Build a project in "release" mode by info@creosrl.it, 2025-02-20 17:05
  9. Build a project in "release" mode by tang, 2025-02-20 10:36
  10. Build a project in "release" mode by info@creosrl.it, 2025-02-19 17:35

Last-Modified Blogs