C++ on the boards

[BytesGalore]

RIOT now provides a seamless c and c++ handling in the RIOT build system for user applications.
But using c++ on specific boards requires adjustments, e.g. (un)set specific compiler and linker flags, provide/change system calls or even provide a custom tweaked compiler.

Here we can track the progression of board support and discuss related issues.

• Family: native
  • native
• Family: ARM
  • Airfy Beacon
  • Arduino Due
  • cc2538dk
  • f4vi1
  • IoT LAB_M3
  • mbed_lpc1768
  • MSB-IoT
  • MSBA2
  • Mulle
  • OpenMote
  • PCA1000x
  • Phytec phyWAVE KW22
  • Samr21 xpro
  • Spark Core
  • STM32F0discovery
  • STM32F3discovery
  • STM32F4discovery
  • UDOO
  • yunjia-nrf51822
• Family: ATmega
  • Arduino Mega2560
  • Arduino Uno
  • Arduino Duemilanove
• Family: MSP430
  • eZ430-Chronos
  • MSB-430H
  • TelosB
  • WSN430
  • Zolertia Z1
• Family: x86
  • Intel Galileo

[BytesGalore]

Family: ARM compile tests

• pttu w/ MCU lpc2387 (compiles)
• avsextrem w/ MCU lpc2387 (compiles)
• redbee-econotag w/ MCU mc1322x (Does NOT compile, errors)

./RIOT/cpu/mc1322x/include/mc1322x.h:26:10: error: 'struct CRM_struct::<anonymous union>::CRM_SYS_CNTL' invalid; an anonymous union can only have non-static data members [-fpermissive]
...
./RIOT/cpu/mc1322x/include/mc1322x.h:200:66: error: invalid conversion from 'void*' to 'volatile CRM_struct*' [-fpermissive]
./RIOT/cpu/mc1322x/include/mc1322x.h:223:10: error: 'struct TMR_struct::<anonymous union>::TMR_CTRL' invalid; an anonymous union can only have non-static data members [-fpermissive]
...
./RIOT/cpu/mc1322x/include/mc1322x.h:292:69: error: invalid conversion from 'void*' to 'volatile TMR_struct*' [-fpermissive]
...
./RIOT/cpu/mc1322x/include/mc1322x.h:332:24: error: 'struct ITC_struct::<anonymous union>::ITC_INTCNTL' invalid; an anonymous union can only have non-static data members [-fpermissive]
...
./RIOT/cpu/mc1322x/include/mc1322x.h:342:9: note: in expansion of macro '__INTERRUPT_union'
...
/RIOT/cpu/mc1322x/include/mc1322x.h:354:66: error: invalid conversion from 'void*' to 'volatile ITC_struct*' [-fpermissive]

[dangnhat]

ping @BytesGalore : do we have any progress on this ? ;-)

[BytesGalore]

no, I haven't tested the implementation for some time if something changed 😊
I will extend the list for with the new boards tomorrow and update it with current results.

[N8Fear]

For AVR I think I can say that there seems is currently no real C++ support on the side of avr-libc. Especially libstdc++ is missing. So while it is possible to use language constructs like classes (I'm not sure if a C++ compiler is included in the default toolchain, Gentoo's crossdev builds one), C++ experience on AVR won't be seamless (without extensive work or switching to another libc, which implies extensive work again ;-) ).

[LudwigKnuepfer]

Arch Linux comes with avr-g++.

[jnohlgard]

@N8Fear It is not really viable to expect a full libstdc++ or similar on a microcontroller platform because of flash and RAM considerations, but there are lighter alternatives for a C++ template library if just the C++ support is there, e.g. http://msharov.github.io/ustl/ (I haven't tried that one yet, but I have been meaning to do it for some time)

[N8Fear]

Ok - in this case: If C++ support means "there is a compiler" AVR should be fine.. ;-)

[dangnhat]

@N8Fear : at least we want some basic object-oriented programming can be done, after that we can consider the support for other stuffs like STL (after evaluate the resource needed and real-time capacity on uCs ). ;-)

For AVR I think I can say that there seems is currently no real C++ support on the side of avr-libc.

IMHO, I think it's the problem with C++ support on that platform in general not specific RIOT. I guess our main goal should be providing the build system to build C++ easily and making sure our source code don't do anything to violate C/C++ compatibility. In other words, it's something like "if some people can use C++ on a platform then they can use C++ with RIOT like normal because our build system can mix their code with RIOT and we don't mess anything up with C/C++ compatibility" ;-)

C++ experience on AVR won't be seamless (without extensive work or switching to another libc,
which implies extensive work again ;-) )

Therefore, if the "normal situation on a specific platform" has some difficulties with C++ then provide the better C++ support for that platform should be nice to have for RIOT but not mandatory. :-)

BTW, arduino can do some C++ programming on avr, right?

[N8Fear]

BTW, arduino can do some C++ programming on avr, right?

Honestly I don't know, but since the AVR arduinos use avr-libc themselves I guess that if it is possible, it's limited the same way as for us (no stdlib).

[dangnhat]

@gebart :

http://msharov.github.io/ustl/

I also haven't tried this one but it looks really nice. I have a C++ project on RIOT with stm32 so I'll try it out. ;-)
Thanks.

[dangnhat]

it's limited the same way as for us (no stdlib).

yeah, I have looked into some forums, it seems to be quite limited. I guess when we have time, we should get one and find out by ourselves. :D

[dangnhat]

Because the deadline of my thesis is closing in, I will postponed the C++ support for msp430 and avr for several weeks, and the C++ support for these platforms probably can't make it into next release. I'll come back with this topic in 2, 3 weeks.
Cheers,

[haukepetersen]

Just successfully tested for the mbed_lpc1768.

[BytesGalore]

@dangnhat good luck for your thesis!
I will take a look on eZ430-Chronos, as we have this HW here. The TI toolchain for msp in >=4.9 seems to be very complete with c++ support (I had just a quick look) and maybe we can manage to build RIOT with it for the board.

[dangnhat]

@haukepetersen : good new! :D
@BytesGalore : thanks! Did you mention about proprietary TI compiler, or Red hat & TI's MSP430-gcc or community's MSPGCC? ;-) (Just out of curiousity )

[BytesGalore]

@dangnhat The Red hat one.

[kausthub]

hi i am a new comer , can you help me on how to get started with this issue ? few links or what am i looking to resolve ?
thanks in advance

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

[fjmolinas]

This should have had tracking Issue Tag, should not have been closed. Re-open.

[mfp20]

For AVR, this guys did an awesome job. It generates a fairly complete C++ lib for the target, and they are focused on performance. It could be a good companion for RIOT.

The only annoying thing is their extensive use of C++17 features, forcing the use of avr-gcc v7+; all major distros are stuck at v5.4 or alike, so a custom toolchain must be built. They distribute a pre-made v9.2 toolchain tough.
There's a big question mark about the future, because GCC will disable AVR target in v10 and remove in v11. And llvm avr target is unstable.

[miri64]

@mfp20 would you be interested in looking into porting this e.g. as a package? The caveats can be dealt with later as long as there is documentation on it.

[maribu]

Basic C++ support on RIOT is working on pretty much every board (except native on FreeBSD or so?). With the ETL package even a usable standard template lib exists.

More native C++ wrappers for the C APIs that do make use of C++ features such as OOP, RAII, etc. where sensible would be nice, but that is orthogonal to this issue.

Also, some platforms are still missing a C++ standard lib, at least AVR does. For AVR https://github.com/modm-io/avr-libstdcpp could be used. But I personally do not feel the itch to package that to just tick a box. If there would be users actually needing this, I could be motivated to do so.

IMO this issue can be closed. Even thought there are still areas of improvement for C++ users, IMO new issues that are more explicit and focused on a single issue should be opened instead.

But if someone disagrees: Feel free to reopen.

[mfp20]

@miri64 I apologize, I must have missed the notification mail of your message in 2020. I've just noted the thread now, on closing by @maribu. I am currently not using RIOT, relying on readily available firmware for my application, just for simple time/money availability constraints (in my life). So no, can't develop anything isn't a paid commercial project. But I hope to be able to change this whenever possible.