Problem with Designated Initializers in SDK when using C++

[zrrr]

Hi,

I want to program the nrf51822 with C++ and from what I've found here it should be possible.

But nrf_drv_gpiote.h contains designated initializers wich aren't supported by C++. I'm including all SDK headers inside an extern "C" {...} block but still get the following error when I use the GPIOTE_CONFIG_OUT_SIMPLE macro:

sdk/components/drivers_nrf/gpiote/nrf_drv_gpiote.h:85:5: sorry, unimplemented: non-trivial designated initializers not supported
 }
 ^
src/main.cpp:648:46: note: in expansion of macro 'GPIOTE_CONFIG_OUT_SIMPLE'
 nrf_drv_gpiote_out_config_t led_config = GPIOTE_CONFIG_OUT_SIMPLE(0);

I'm using SDK version 10 and compiling all .c files with GCC (-std=gnu99) and all .cpp files with G++ (-std=c++14).

How to deal with this problem?

[RK]

Change the macro to fill in all the fields properly in order and use that instead of the one in the SDK.

Importing inside an extern "C" {} block won't help as that just works for the definition of the macro, it doesn't help when you use it which is in 'c++' context.

Or factor out the functions you use it in and make them extern "C" {}

[zrrr]

That I can fix this by modifying the macro is obvious but i wanted a more general approach as the SDK uses designated initializers in many places and I don't want to reimplement/modify too much in the SDK. I temporarily fixed it by filling the struct manually instead of using the macro just to run into the next problem. Some inline assembler statements don't work with g++ and throw compile errors. Seems like the SDK was never designed with C++ in mind. That is sad as I really liked the SDK (especially the exceptionally good documentation compared to other manufacturers) but C++ support is mandatory for me.

[RK]

which assembler? Most of the C++/g++ assembler problems are well-known and documented here in the forums and lots of us use pretty much only C++, so it's quite do-able.

[zrrr]

sdk/components/softdevice/s110/headers/nrf_svc.h:57:6: error: impossible constraint in 'asm'

But I also get more "asm operand 0 probably doesn't match constraints" warnings than I can count in other softdevice headers.

[RK]

yeah that's a known bug, the cast in there is to uint8_t instead of uint16_t. We discuss this every time a new SDK release comes out. it's currently on the list of known issues and may get fixed one day. Until then, modify the file to say uint16_t and continue on with the day.

devzone.nordicsemi.com/.../

You'll come across a few more here and there but they're all pretty trivial, although the designated initialisers are annoying.

[RK]

and try the search - all this is discussed constantly in lots of threads, with fixes and workarounds and advice. Search box is ^^ up there