AVR Freaks

// This is to work around "because it is not the address of a variable" error
// where template argument is refused because it's not a pointer to a variable.
// https://stackoverflow.com/questions/37303968
constexpr uintptr_t PortD() {
  return (uintptr_t)&PIND;
}

You are in violation of Standard. You are not allowed to use reinterpret_cast in constexpr. The macro PIND has a reinterpret_cast inside, therefore it can't be used inside constexpr, EVER! <- picture rabid C++ standard code lawyer here.

The C++ Standard inquisitors are on to you.

Those people, who when you ask certain questions at stackoverflow give you that moronic answer: "Why would you ever need to do that?"

Those people, who have an encyclopedic knowledge of the C++ standard, and in their hubris believe that is all the knowledge there is.

Those people, who can barely grasp the peculiarities of MCU programming.

Yes, we all know them well...

And so, even though your workaround works on avr-gcc 7.x.x currently used by the Arduino IDE, it's a dangerous bug </sarc> already fixed in more recent versions.

The dreadfully permissive version 5.x.x currently used by Atmel Studio doesn't even need this workaround. <- kill it with fire!!!!! 

That's right, you could even put the address directly as template argument like this <(uintptr_t) &PIND> on v. 5.x.x, can you imagine the dreadful Pandora's box that opens? I tremble just to think about it.

V. 7.x.x already fixed that hole, but left the exploit you are using wide open!!!!

"Fortunately", it has now been fixed in more recent versions.

I, El Tangas, have devised a new workaround for more recent versions. It's secret, of course. I dare not share it publicly, lest the Code Inquisitors get wind of it

In case you are not aware (sounds like a new discovery), this has been a thing for many years. Back in the early PIC days (80's or something),  I had a paper clip as my touch sensor on some pic16 and I'm quite sure it was an old idea at the time also.

That is not meant to detract from what you have, and if you discovered it to some degree on your own then that is a good thing. There are plenty of discoveries where many people end up in the same place from different routes. It is sometimes a little sad when you end up at the north pole and discover you are number 10,001.

Trying to relive my early pic days (although pic was in asm)- I have a bare wire hanging from a pin and turning an led on by touching it (just a crude example, no pullup used at all)-

//tiny817 Xplained
//default 3.33MHz
#include <avr/io.h>
#include <stdbool.h>
#define F_CPU 3333333ul
#include <util/delay.h>

static void led_on(){ VPORTC.DIR |= PIN0_bm; VPORTC.OUT |= PIN0_bm; }
static void led_off(){ VPORTC.DIR |= PIN0_bm; VPORTC.OUT &= ~PIN0_bm; }

bool touch(){
    static uint8_t tmin = 255, tmax = 0;
    VPORTA.DIR |= PIN2_bm; //PA2 = output
    VPORTA.OUT |= PIN2_bm; //high
    VPORTA.DIR &= ~PIN2_bm; //PA2 = input
    uint8_t v = 0;
    while( (VPORTA.IN & PIN2_bm) && v < 255 ) v++;
    if( v < tmin ) tmin = v;
    if( v > tmax ) tmax = v;
    return v > ((tmax - tmin)/2 + tmin); //if v > 1/2 difference = on
}

int main(){
    for(;;){
        if( touch() ){
            led_on();
            _delay_ms(50); //'debounce'
        } else {
            led_off();
        }
    }
}

I'll have to add that to my avr0/1 c++ library since atmelchip does not want anyone to see the secret touch peripheral-

//Touch.hpp

#pragma once
#include "Port.hpp"

template<PINS::PIN Pin_>
struct Touch {
    static bool isOn(){
        static uint8_t tmin = 255, tmax = 0;
        Port<Pin_, PINS::OUTL>::init(); //init output, high
        Port<Pin_, PINS::INH> p; //back to input
        uint8_t v = 0;
        while( p.isHigh() and v < 255 ) v++;
        if( v < tmin ) tmin = v;
        if( v > tmax ) tmax = v;
        return v > ((tmax - tmin)/2 + tmin);
    }
};

Touch<PINS::PA0> touch1;

if( touch1.isOn() ){ /*do something*/ }

>What is the point to setup the pin to output high before switching to input?

There are many variations, but I just chose to start 'high' (output/high), then back to input and let the pin drift downward until it trips the low point (inc a var while waiting). If my finger is on the wire, it takes longer to discharge of course. The pullup could also be used instead of output/high, but output/high would charge anything attached faster and make sure I'm starting as high as possible (since it is really unknown where exactly the starting point is- high just above the high level or high close to Vdd are both high). Didn't put a ton of thought into it, just was trying to show minimal code that shows a mostly reliable simple on/off. Not much resolution either (3.3Mhz), but I probably wouldn't try for more than on/off anyway as I doubt anything more would be reliable (there is a reason they created specific touch peripherals).

I'm not Arduino man, but I do have it on the pc somewhere.

I would try to make the template parameter something that is common/already created-

https://godbolt.org/z/zvmMTa

they already have this contraption built to deal with pins so I'm not sure I would want to now force a user to figure out port letters and numbers in addition to all the other translating taking place (probably not as bad as I imagine), plus you can then eliminate your problem parameter and do static_assert at the same time. I'm not sure I pieced together the Arduino pin rube goldberg machine correctly, but I think its close enough for the example.

Indeed it is. Still beats not working at all.

edit: in fact I never actually finished the code because I decided to use a different approach. The draft I have is very basic and works only for addresses of SFRs that are in the memory space, not I/O.

edit2:

These are the macros for stringification and a test:

#define STRINGIFY(content) #content
#define EXPAND_AND_STRINGIFY(input) STRINGIFY(input)

static_assert ( false, EXPAND_AND_STRINGIFY(PORTA) );

the part I never did get quit right is parsing the strings at compile time. I know it should be possible because of this:  https://akrzemi1.wordpress.com/2011/05/11/parsing-strings-at-compile-time-part-i/

edit3: actually I found the rest of my draft code, so here it is a full example, for the ATmega4809:

#include <avr/io.h>

#define STRINGIFY(content) #content
#define EXPAND_AND_STRINGIFY(input) STRINGIFY(input)

constexpr uint8_t char2val(const uint8_t val){
    return 
        ( ( val >= '0' ) && ( val <= '9' ) ) ?
            ( val - '0' ) : (
        ( ( val >= 'A' ) && ( val <= 'F' ) ) ?
            ( val - 'A' + 10 ) : 0xFF );
}

constexpr uint16_t val(const char * const str, const uint16_t previous = 0){
    return ( char2val(str[0]) != 0xFF ) ? ( val(str+1, 16 * previous + char2val(str[0])) ) : ( previous );
}

constexpr uint16_t str2val(const char * const str){
    return
        ( (str[0] == '0') && ( ( str[1]=='x' ) || ( str[1]=='X' ) ) ) ?
            val(str + 2) : (
        ( (str[0] == '\0') || ( str[1]=='\0' ) ) ?
            0 :	str2val(str + 1) );
}

int main(void)
{
    PORT_t & portA = *(PORT_t*) str2val( EXPAND_AND_STRINGIFY( PORTA ) );
    portA.DIR = 0;
    return str2val( EXPAND_AND_STRINGIFY( PORTA ) );
}

Sorry for the lack of comments... This is meant for C++11 so constexpr functions can only have the return statement in their body. That's why they are somewhat weird and recursive.

The asm output is:

000000b2 <main>:
  b2:	10 92 00 04 	sts	0x0400, r1	; 0x800400 <__TEXT_REGION_LENGTH__+0x700400>
  b6:	80 e0       	ldi	r24, 0x00	; 0
  b8:	94 e0       	ldi	r25, 0x04	; 4
  ba:	08 95       	ret

I don't remember if I actually tested it as template argument, maybe it's lost somewhere in my drive.

I use Atmel Studio as the IDE. The toolchains I currently have installed are

• the native one that comes with AS7, which is avr-gcc 5.4.0 with a few modifications made by Atmel/Microchip
• the toolchain that currently comes with the Arduino IDE, which is avr-gcc 7.3.0 with a few modifications
• avr-gcc 10.0.0 built by SprinterSB, from here:  https://sourceforge.net/projects/mobilechessboar/files/avr-gcc%20snapshots%20%28Win32%29/

This is a simple test code:

#include <avr/io.h>

constexpr uintptr_t PortB() {
    return (uintptr_t)&PORTB;
}

template <uintptr_t data>
uint8_t example() {
    return data;
}

int main(void)
{
    return example<PortB()>();
}

I compiled for both ATmega328P and ATmega4809. They both have the PORTB macro. So here is what happens:

• 5.4.0 compiles for both targets
• 7.3.0 compiles for ATmega328P, fails for ATmega4809. This is because the PORTB macro is defined in a different way for each, for m328P is a volatile uint8_t, but for m4809 is a structure containing several volatile uint8_t
• 10.0.0 fails for both, this is the behaviour required by standard compliance

The error reported by v. 10.0.0 goes like this for m328P:

 error: no matching function for call to 'example<PortB()>()'
           21 |  return example<PortB()>();
              |                          ^
 info: candidate: 'template<unsigned int data> uint8_t example()'
           15 | uint8_t example() {
              |         ^~~~~~~
 info:   template argument deduction/substitution failed:
 error:   in 'constexpr' expansion of 'PortB()'
 error: 'reinterpret_cast<volatile uint8_t* {aka volatile unsigned char*}>(37)' is not a constant expression
           11 |  return (uintptr_t)&PORTB;

the important part is the one I highlighted in red, that results from the macro expansion. In terms of C++, the normal cast from C is actually a reinterpret_cast which can't occur in a constexpr function according to the standard.

So if you want your code to be compliant, you'll have to manage for it to compile with v. 10.0.0 without errors. I think it's possible to install a different toolchain in the Arduino IDE manually, so if you feel adventurous give it a try.

https://store.arduino.cc/arduino-uno-wifi-rev2

https://store.arduino.cc/arduino-nano-every

Yes, it doesn't matter what you throw at it, neither constexpr functions, nor enums, no form of constant expression can penetrate the impervious anti reinterpret_cast shield implemented in recent avr-gcc versions.

And even if you could find something that can, it would be considered a bug and fixed later.