AVR Freaks

You are making it more complicated than it needs to be. If I was required to write this in my application code I think I would skip C++ -

    (new Port_c_device)->Set_pins_direction_out(Port_device::Pin7);
    (new Port_c_device)->Set_out_pins_high(Port_device::Pin7);

No offense meant, but that is what we are trying to escape. How are you going to get a friendly name attached to that? There lies a problem, and the solution to get a name attached to pin c7 will most likely end up similar to what one would do in C.

Wouldn't you rather have something like this-

    Pin<A0> sw { LOWISON, INPUT, PULLUPON }; //options in any order
    Pin<B2> led{ OUTPUT, LOWISON };
   
    while( sw.isOff() ); //press sw to start

    while(true){
        led.toggle();
        waitms( 500 );
    }

You get to specify the name of the pin and set its properties all in one line, and the resulting code will be as minimal as anything. Now you have a name you can use that has a set of functions 'attached' to the name. Yes, a little template learning is required but is worth the time to at least figure it out to some degree. Template use for peripherals probably becomes less important when you have an mcu that is more capable, but even with a more powerful mcu there is little downside to using templates for peripherals.

Here is a simple C++ style (or outline) I put up on github a few days ago, just because I wanted it written down somewhere-

https://github.com/cv007/C-PlusP...

It starts with a mega328p (I don't even use a mega328, but makes for a simple example), and then has a few more advanced for a mega4809. I could add more, but the rest is mostly just the same. I use this style on any mcu and any peripheral and they all end up looking basically the same and work quite well.

I have refined this 'style' for a while now, and seems to work well (avr0/1, nRF52, a little stm32, etc.). For the avr0/1 I have most peripherals done (each chapter in the datasheet), (redone again, now even better), and for things like the nRF52 I just 'take over' a peripheral as wanted/needed (the rest ends up with a C++ layer on top of the manufacturer provided things). All files are header only, a single file per peripheral, and to use it- just include it. 

What you get is a nice way to create a peripheral struct that is specific in its properties at compile time (the things that separate it from the other peripheral instances), you get a set of enums that are specific to the peripheral (and enum types are great for function arguments as they naturally 'assert'),  the peripheral register layout is contained within if wanted, and the functions end up short and simple because the register access is simple. A peripheral contained in a single header, which never needs adding to the project source list.

As already mentioned, it doesn't take long before any comparison to a C equivalent becomes hard to do. For the most part, you do equivalent things you are going to get equivalent results unless you code your C++ like you are programming a pc. C++ gives you an easy way to do things that are awkward to do in C, so you soon get to a point where you can imagine what it takes to do the equivalent in C, but you certainly are not going to take the time to prove the point to yourself. You can already see there is no way you are going to give up C++ even if the resulting binary size is a little bigger.

What does happen, is you get a system that is easy to use so you use it (size increases)- have a Buffer class and a Usart class that can optionally take in a Buffer? little reason not to use it as only requires a line of code to create the Buffer and you no longer block on any uart output. Nice buffer in place, so why not send debug info out the uart at high speed (no major effect on running mcu), turning on/off the debug output as needed (single line of code). Rtc and Time classes in place? Well, since we now have a system time in unix seconds and fractional time in 0-999ms, may as well output the system time in the debug output. Hey, we have a system time with resolution down to a ms, so now that can be used for both tasks and long term events in addition to providing clock time- one universal time for everything outside any precision/hardware required timing needs. Your binary sizes increase because you are simply doing more, you are doing more because it is easier to do so.

Well, if you look at the Arduino AVR source code, new is basically just a wrapper for malloc. So if someone abuses new everywhere, don't go blaming the bloat on C++, it's malloc.

https://github.com/arduino/ArduinoCore-avr/blob/master/cores/arduino/new.cpp

Well, I think it's well known that Arduino libraries are not exactly the pinnacle of optimization, quite the opposite in fact.

In my code I'd do something like this.

#define LED_PORT  Port_c_device

#define LED_PIN    Port_device::Pin7

You would rather create a set of defines just like C?

    (new LED_PORT)->Set_pins_direction_out(LED_PIN);
    (new LED_PORT)->Set_out_pins_high(LED_PIN);

Why not just stick to C then?

    LED_PORT->DIRSET = LED_PINbm;

    LED_PORT->OUTSET = LED_PINbm;

Rather, how about just doing something C++ like-

    Pin<B2> led{ OUTPUT };

    led.on();

No defines, one line, we get a name to use, and have a set of functions attached to the name. Need to change the pin? change the B2 to something else, done.

I probably sound harsh, but am just trying to point out that there is a better way (I think so, anyway). I have already posted enough links to examples so will try to refrain from showing any more. My last post has 'another example' which is an Ac peripheral in a mega328p. All peripherals end up looking like that- a single header file for each peripheral with no need to touch any peripheral registers when writing app code, no need for an mcu header since its easy to create a register layout struct for register access where its needed (in the peripheral struct), and all the needed enums also live in the peripheral struct. One file and we have everything we need to run a peripheral, and only need to include it to use it. For the most part the functions inside stay pretty simple and just take the drudgery out of doing the common-

    //a Buffer class of 64 u8's (with all the functions you will need- append,remove,+ a dozen more)

    Buffer<u8, 64> txbuf;

    Usart0alt uart; //usart0, alternate pins

    //turn on tx (+set portmux, + set pin to output), optionally provide a buffer(will then use tx irq),

    //230400 baud (run time calculated from current cpu speed, can also do compile time calculation if wanted)

    uart.txOn( txbuf, 230400 );

    //now can Print using printf style

    Print( uart, "Hello World\n" );

So something like the above to setup a way to print from a uart becomes easy, and with 3 lines of code we are all set. You also have easy access to the source of anything- want to see what txOn() does? you will be taken directly to the source in Usart.hpp, where the function will be simple and everything you want to see will be in that file with no need to be bouncing around headers until you finally reach what you were looking for.

These device classes only need to be written once.  Atmel should have written them years ago.

It may be a good thing these manufacturers do not touch C++. Somehow I think they would turn it into something closer to awful than good.

As long as I'm filling up the avrfreaks server storage with my comments, I will add that I have projects in C++ on github (which I use mainly for backup/storage) that I would probably cringe a little if I go and take a closer look at them again. I think what I do now in C++ is much better, but I always hold out hope for better than what I have now and may end up looking back at the 'now' and cringe about it in the future.

>Whar?  Since when is giving us a class touching C++?

>I've written a lot of classes but that doesn't do anything to C++.

As soon as you are required to use a C++ compiler, you are touching C++. I take it your code compiles in C? of course not.

> If you add the new operator and inheritance,  that's about all I know and need to know about C++

That is potentially what a manufacturer would conclude, and we would be required to use 'new' for everything if we want to use their headers. Most likely they would not do that, but its not hard to imagine they end up using other ideas that are also not so great.

>That should make it fairly easy to do pretty much anything one wants,

You can use the existing headers, but you end up in an awkward spot because they may not give you any register bit position information in the register struct they provide (register wide names only). So now you have the rest of the needed information scattered in various enums and simple defines, as bitmasks and bit positions (with names created in a way as to avoid all the other define names- so names are larger than really needed). In the end it becomes easier to just create your own register layout and enums.

There are times it is not so bad to use existing headers, other times it just doesn't work very well. With only a little work, you can use something that ends up being easier to read and understand-

(pinctrl is a reference to the correct PINnCTRL register)-

SA  inMode   (PINS::ISCMODE e) { pinctrl.ISC = e; }
SA  pullupOn ()                { pinctrl.PULLUP = 1; }

SA  pullupOff()                { pinctrl.PULLUP = 0; }

sw.inMode( BOTHEDGES );

using existing headers-

SA  inMode   (PORT_ISC_t e)    { pinctrl = (pinctrl bitand ~PORT_ISC_gm) bitor e; }
SA  pullupOn ()                { pinctrl or_eq PORT_PULLUPEN_bm; }

SA  pullupOff()                { pinctrl and_eq ~PORT_PULLUPEN_bm; }

sw.inMode ( PORT_ISC_BOTHEDGES_gc );

They both will end up doing the same thing, but the former is easier to read as you do not need to spell out to the compiler how to clear/set bits inside a register. 

An example for an nRF52 Gpio-

https://github.com/cv007/nRF52_B...

I'm not sure what it would look like if using the supplied headers, but you will end up digging around various headers just to find what you are looking for and still end up with names that are 30 chars wide with a handful of underscores. Easier to just spend the 60 minutes and create your own register struct and required enums and be done with it, never again needing to use/look at the manufacturers header(s) for that peripheral.