AVR Freaks

I can write C programs in C++ - I can even use some of the new features (function overloading is nice.)

A lot of "book-learned C++" seems to be "look at all these neat Standard Template Libraries that do great stuff, are heavily dependent on dynamic memory allocation, and unsuitable for embedded use!"  :-(

And there are extremists.  I continually shake my head at the example here: https://softwareengineering.stac...

Embedded C++ (EC++) removes templates, etc.   But still I prefer C for small spaces.  If you use only a fraction of code in a C++ class the compiler will drag along all the unused stuff into your flash.

Same here. And yeah, the fact that most books teach C++ as if the STL library is the alpha and omega of C++, when it's just a library, and that C++ is all about OOP, also ticks me off.

I don't care about OOP, or "proper C++" or whatever. I care about the features of C++ that help me with code modularity and readability without introducing bloat.

And there are a few, overloading is nice, as you mentioned, default function arguments also help sometimes; references, templates and constexpr can be used as a (vastly more powerful) replacement for the preprocessor.

I think c++ is a great choice for an mcu. For a small mcu like the avr, you are in a little different world as you don't have access to many things other than the language itself. Move up to 32bit, and you have both a compiler that probably has all the usual c++ things available (libraries), and possibly an mcu with the room to use them.

Even without access to all the stuff they show in the books (which are pc focused), there are plenty of things in the language itself that are very nice. There are a number of features that make life easier, and most of them have no cost in terms of code size. Most of the books and info online like to assume you are using a pc, so it does take some sifting to get at the parts that are useful.

Very simple example, just create a pin from the Port class/struct (as named in the datasheet), the constructor takes care of setting up the pin- invert in this case so can then use on/off things and they do not have to know that low is on for the led, set the pin in an off state (high in this case), and set the dir to output, then just turn on the led-

#include "Port.hpp"
int main(){
    Port<PINS::PA0, PINS::OUTL> led; //output, low is on
    led.on();
    for(;;){}
}

resulting asm output, which you are not going to do any better in c (or asm)-

0000026c <main>:
 26c:    80 e8           ldi    r24, 0x80 //set invert bit
 26e:    80 93 10 04     sts    0x0410, r24 //in pinstrl (now inverted, so below out/in cbi/sbi do the opposite)
 272:    08 98           cbi    0x01, 0    ; 1 //off()
 274:    00 9a           sbi    0x00, 0    ; 1 //dir output (dir is not inverted, so sbi)
 276:    08 9a           sbi    0x01, 0    ; 1 //led.on()
 278:    ff cf           rjmp    .-2 

you now have a pin with a name, so no need for a define, that pin has methods so no need to use a macro, and if you wanted to create a number of pins in global namespace they will all be init in startup code.

You can also start doing things that are not possible in c (this is just an example file I use to test things out)-

https://github.com/cv007/Avr0PlusPlus/blob/master/Example1.cpp

for example, I created a struct to take care of eemem (including userrow), that uses operator overloading and a tweak to the default linker script. Now eemem and userrow can be treated as a normal var- read/write. 

#include "Nvmctrl.hpp"

URMEM URvar<uint32_t> ur_bootcount; //a uint32_t to count # of boots the mcu has done- 32bits a little excessive :)

int main(){

    ur_bootcount++; //increment boot count

    for(;;){}

}

Another big benefit in my eyes, is you can mostly do away with defines and macros. In the above github folder there are a total of 4 defines I use, which are for the the above nvmctrl eemem functions and are simply to eliminate the need to use the __atrtibute specifier directly for the section name (URMEM above). In the pic32mm code I have on github, I have a driver for every peripheral and the only defines I had to use were in creating the usb descriptors because there was just no way I could come up with a c++ way to do what I wanted (c++ 11 anyway).

Once you eliminate defines and macros, you are now mostly in the compiler world and get the benefit of everything the compiler has to offer without having a word processor in between rewriting everything (defines/macros).

I can write some c++ in the pc world, but there are too many other languages or variations that are probably better for many users (c#, python, etc.)., so maybe the pc world in some ways eventually moves on in many areas but the embedded world can certainly make good use of c++ and mostly has not begun to do so. I think the problem we currently have is manufacturers do not seem to want to change, and a c++ user is left either using the c parts provided by the manufacturer (for peripherals) or going it alone and writing your own peripheral drivers.

This is basic code I made for a stm32g031 for the gpio class using the same ideas I used for pic32mm, avr0/1-

https://godbolt.org/z/JVJVXy

you can skip down to main to see what usage ends up being- in this case you can just specify which pin you want (and if you want 'low is on'), any of the properties you want set (specified in any order)-

using namespace PINS;

Gpio<PA0L> led(PULLUP, OUTPUT, SPEEDHI); //pullup makes little sense here, but just showing

led.on();

So, the 'HAL' layer is both the low level and the high level all in one. There is no need for a upper level interface to some lower level code. There is also no need to traverse some trail of includes to find what is going on, as all the info is in the single file (and in this case is a header only file). Now the problem is there are 30+ other chapters in the datasheet to tackle and if you want to do the same thing for all peripherals you are on your own (which I have done for a pic32mm, and am doing for the avr0/1- but it takes time).

2002.   Wow.  I thought it was active more recent than that.  The last C++ coding I did was a few years prior to that. 

In my experience most C++ programmers don't really understand the side effects of what they code.  For example, while some templates are OK for embedded, the fact that others may not be is a reason to eliminate them.

My post was missing the