Using C structs imported from a C library

PlatformIO IDE
,
1

After successfully following along the guides in this thread I was able to get my base project building in PIO, but after trying to convert to a C++ project, I’m having some struggles with some of the C-based structs from the CMSIS_RTOS library after i changed main to C++. Mind you the library already is wrapped in an “extern C” and it builds in cubeIDE, but something is missing from my platformio config which is preventing it from building successfully there.

This is the error I get:
Core\Src\main.cpp:77:1: sorry, unimplemented: non-trivial designated initializers not supported }; ^
and it’s with regards to this portion of generated code:
image

I was hoping for some help here since I realize that i will continue to come across issues like this since the entire backbone of the RTOS library depends on structs and it does build in cubeIDE so there must be some missing piece of the puzzle.

2

The compiler just won’t let you do it this way in a C++ file (main.cpp).

You may try to give every struct field in the order they were declared in .field = value form

or leave out the .field and only a comma separated list of values.

Which fields do exist in this struct probably depends on your CMSIS-OS version.

3

I was thinking of trying that as a mitigation, but I’m not sure how things will behave if I define things that were left undefined. But the reason I believe that there is a way of getting this to build is the fact the same project does successfully build in CubeIDE using g++14

4

Oh? And the above code was in a .cpp file too, not a .c file?

5

Yep it’s the exact same project that I have configured based on the originally linked tutorial to be opened either in CubeIDE or Platformio.

There is a python script that scrapes the compiler arguments from cubeIDE and adds them to platformIO but that only works with the C configurations, so my best guess is the reason it isn’t working in platformIO is I’m missing some compiler/linker flag that CubeIDE is using but I can’t quite figure out what.

I’ve tried copying over all the compiler flags manually but things don’t quite work that way.

Here’s some proof the same project builds in CubeIDE and these are the settings:

image
image2246×1231 280 KB

image
image1539×798 53.4 KB

image
image1330×650 16.3 KB

6

You can check the exact compiler invocation using Project tasks → Advanced → Verbose Build.

The compiler versions and used C++ language versions may be different too, so check for that in the command and with --version in the STM32Cube used compiler. You can change to a different compiler using platform_packages for toolchain-gccarmnoneeabi with a version from the registry.

7

yep building with verbose mode on PIO shows that it was using g++14, which is the same version CubeIDE is using as well. I tried updating the toolchain in PIO and using the g++20 standard which explicitly supports this type of struct usage, and that does work but what I’m a little hung up on is the fact that cubeIDE is doing something to make it build correctly without any warnings or errors using g++14, whereas when I switched to 20, there is 2 lingering warnings, 1 of which seems semi serious:

image
image1674×207 16.9 KB

8

Soo what’s the arm-none-eabi-g++ --version in the CubeIDE compiler?

9

I’m not actually quite sure how to check that directly in CubeIDE. running the command in the terminal doesn’t seem to yield anything. Best I can do is look at the flags passed in
image

and this
image

10

PlatformIO does not have that exact 11.3 version. Can you find the path to the compiler that CubeIDE is using?

If yes, copy the whole folder somewhere else, add a package.json to the folder like

{
  "name": "toolchain-gccarmnoneeabi",
  "version": "1.110301.0",
  "description": "GNU toolchain for Arm Cortex-M and Cortex-R processors",
  "keywords": [
    "toolchain",
    "build tools",
    "compiler",
    "assembler",
    "linker",
    "preprocessor",
    "arm"
  ],
  "homepage": "https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain",
  "license": "GPL-2.0-or-later",
  "system": [
    "windows_amd64"
  ],
  "repository": {
    "type": "git",
    "url": "https://gcc.gnu.org/git/gcc.git"
  }
}

and reference it with

platform_packages =
  toolchain-gccarmnoneeabi@symlink://<full path to copied folder>
11

I will try this in a bit but it seems using the newer toolchain in platformio mostly fixed my problem.

The only issue remaining at the moment is for some reason, in this state, platformio isn’t grabbing the startup script from Core/Startup, even if I have it included in a build flag like so:

build_flags = -ICore/Startup/

The only way I was able to fix the warning: cannot find entry symbol Reset_Handler; defaulting to 08000000 was by moving the startup_stm32h723zgtx.s file to the src directory which seems a little jank and it’s a bit strange I can’t force it to get included with the build flags

12

This is correct. -I just means “add this folder to the include path” so that when some .c,.cpp or assembly file in the source build tree does #include it has the chance to find it. It does not add any files to the “to be compiled / assembled file list”. Source files that you want to be compiled or assembled must be in src/ or in a folder in lib/.

Also to PlatformIO it makes a difference whether the file is .s or .S, which is the difference between invoking with the c++ preprocessor or only the assembler.

13

Is there a way to get it to compile that file without moving it?

14

…why, moving it should be the easiest way. Any source files should be in folderes dedicated for source files.

You can probably hack around by referencing the relative path (to src/) to the file in a build_src_filter or use an explicit env.BuildSources().

15

fair enough, I was just wondering mostly because it all worked as is before the whole C++ fiasco. It’s probably to do with the script not working perfectly with C++ configurations but I think I finally hit a point where I can actually start working on this project and not spending all my time setting it up.

I’ll probably be back in this thread with more questions in the near future if something breaks again with regards to this setup but just in case I don’t come back, you’ve been a great help, thanks!

16

Does -Wmissing-field-initializers help?

17

platform_packages =toolchain-gccarmnoneeabi@>1.12

fixes the original problem, although it seems something with that version in the pio registry is broken if you want to use the debugger.