USART bitmask changed in newer versions of the DFP

[simengangstad]

USART_RXMODE0_bm is changed to USART_RXMODE_0_bm in the newer versions of the DFP (I'm testing with 2.2.159). Just to provide a heads up when you update the DFP the core uses. The only place I found where this was an issue is at this line:

DxCore/megaavr/cores/dxcore/UART.cpp

Line 553 in 44efdd2

ctrlb |= USART_RXMODE0_bm; // set the U2X bit in what will become CTRLB

[SpenceKonde]

By DFP do you mean ATPACK? Because I'm already using the new ATPACks where you guys did something that I have trouble charachterizing in polite company, and changed the names of all the bitfields and all the bit positions every name that represented a multibit bitfield. I will be sure to correct that scroll a few screens down in core_devices.h in megaavr/cores/dxcore - use a combination of findall w/regex, copy, pasted into new file, several times, in order to that gigundo block (something 3k lines) of obnoxious preprocessor stuff to make sure that the old names work.

Because if I upgrade the ATPACK version to support new parts or whatever - and it breaks something, I can point my finger and you guys, but the people are still pissed at me and start telling all their friends "Don't use his core, it used to be good be now none of my old code works, he refuses to fix it, so that cores no good anymore does anyone know if there's is there any WORKING core for these part that isn't written by some moron like that dude?"

So every time you break compatibility, I have to put in backwards compatibility hacks, and despite days of trying I haven't been able to maker a deprecation notice show. I can make a deprecation notice show whether they used the old names or not (worse than useless), but not make it show only when the deprecated constant has been used.

Now if I could get the avr-gcc __attribute__((warning)) to work it'd be easy-peasy. But I cant, Tried many times, asked every expert on stuff like that I know..... and nothing! None of them could make it work either. There's got to be a way to make a deprecation warning appear ONLY IF THE DEPRECATED THING IS USED right?!

[simengangstad]

Yeah, sorry about that. I'm not on that team, but such changes are never fun. Please let us know if there is something we from MCHP can help with. We're more than happy to help. Forgot to use my MCHP github account here, but my work account user name is M65649 and has the Microchip logo as an avatar. I'm the one who added the PORTC ISR pull request.

Regarding the deprecation notice. You have the [[deprecated]] attribute for things which are not defines at least: https://en.cppreference.com/w/cpp/language/attributes/deprecated. With some abuse of macros you can do this for tokens:

#define STRINGIFY(x) #x
#define GCC_WARN_MESSAGE(x) STRINGIFY(GCC warning #x)
#define DEPRECATED(x) _Pragma(GCC_WARN_MESSAGE(Deprecated - use #x instead)) x

// Just a dummy value, I don't remember the actual bitmask
#define USART_RXMODE_0_bm (0x08) 
#define USART_RXMODE0_bm DEPRECATED(USART_RXMODE_0_bm)

#include <stdint.h>

int main() {
    volatile uint8_t test = USART_RXMODE0_bm;
    return 0;
}

See the compiler output here: https://godbolt.org/z/esj4vhKzP. With that you get a warning when that token is used, but not otherwise. It will fallback to the item provided in the DEPRECATED call, so as you can see in the assembly on godbolt, the value for USART_RXMODE_0_bm is used. I guess one can also change warning to error to scale it up to an actual compilation error if one would like that.

Seems like this works only with avr-gcc >= 5.4.