Add AVR C++ standard library

[salkinium]

I wanted to use initializer lists as a function argument, and this of course works for arm-none-eabi, however, it does not for avr-g++ since it does not come with any stdlibc.

So I've researched what the state-of-the-art seems to be for adding it, and I think this port of uClibc++ seem to be it: https://github.com/kibergus/StandardCplusplus

Perhaps we don't need to add everything in one big swoop, but at least the free stuff especially from C++11 (everything with constexpr) should be there.

[salkinium]

It'll be an uphill battle to keep the stdc++ lib up-to-date with the one that comes with ARM targets.

It may also be interesting to look at other libraries as well:

• ETLCPP/etl: C++03 only, but optimized for embedded and may be very suitable for AVRs.
• cbiffle/etl: C++14 ready with some very cool language candy, not as fully featured as could be though
• avr-stl: C++03, but at least somewhat standardized.
• ustl: Not really targeted for embedded.

[malachib]

I know this is a super old issue, but thought I'd throw my fledgeling effort into the ring:

https://github.com/malachi-iot/estdlib

It's kind of a mess at the moment, but already has some useful tidbits and I'm actively improving it.

It's C++11 though can #Ifdef out to C++03.

Love your xpcc lib, wish I could use it on my targets :) but that's a discussion for a different thread :) keep up the good work!

[salkinium]

Hm, I dunno. My patience with Atmel is wearing a little thin. The official avr-gcc is stuck at v5.x, and Ubuntu still ships with v4.9.3. We'll see how long I can last until I break down and just remove AVR support. There's also the thing where the new generation of AVRs are this frankenstein-mashup of AVR core with Microchip peripherals. No thanks.

Love your xpcc lib, wish I could use it on my targets :) but that's a discussion for a different thread :) keep up the good work!

Thanks! Check out the successor to xpcc: http://modm.io. Same people, (mostly) same API, but better code generation under the hood.

[malachib]

Cool, yeah it looks very similar. The "love 'em and leave 'em" nature of embedded software support from the Vendors themselves is pretty disappointing I agree. I finally learned not to look for the the most interesting hardware, but instead what I expect will get supported. Do you have any other targets on your horizon that you are pondering?

[salkinium]

Do you have any other targets on your horizon that you are pondering?

Mostly other ARM Cortex-M vendors, I'm so done with the other architectures (but I worked at Arm, so maybe I'm biased ;-). EFM32 is pretty interesting for low-power, NRF5x for BLE.

The issue is getting good data to do the HAL generation with. I'm working on some PDF parsing tech that should remove that limitation, but there are other priorities at the moment (like transitioning everyone from xpcc to modm).

[malachib]

I am definitely a fan of the ARM architecture. It feels so well thought out and cohesive, a necessity when you can't simplify things down like in the desktop world. I play around with the ESP32/ESP8266 a lot but only because they are convenient. I'd prefer an ARM+WiFi module , but good luck getting a good one for only $3 lol. Looks like we aren't saving that conversation for another thread after all :)

[salkinium]

This has been fixed in modm.