GCC processor ID macro

[wa2mze]

Is there a way using an #IFDEF that my code can query GCC as to which processor I'm using? Specifically, I'm writing an Arduino library, and I'd like to pass a PORT address into the constructor. BUT the port address structure is different between the good old atmega processors (such as atmega328, atmega2560, etc) and the DXCORE and MEGACOREX processors. You know, DIR, PORT and PIN vs PORTx.IN, PORTx.DIR, PORTx.OUT and also VPORTx.PIN, VPORTx.OUT, etc.....
SO when I pass in the port address Device(volatile uint8_t * port) do I use it as port.DIR or (port-1)* ?
I've looked in the source files for DXCORE and MEGACOREX but didn't find any #define AVR xxxxx
I suppose I could just create a LONG macro combining the processor name macros for all of the suitable targets such as
#IF_DEFINED (AVR_atmega4809 || AVR_atmega4809 || .... ad nausum ) but there must be a better way?

[SpenceKonde]

#if __AVR_ARCH__ >= 100 

is true for all modern AVRs and all xMegas (the modern AVRs are more xmega-like than they feel. They realized nobody wants an 8 bit mcu with a 1500 page long programming manual in addition to the datasheet, and so they excised the byzantine peripherals that made everyone pause when looking at xmega and replaced them with simpler more modern peripherals that kept most of the capability but lost the mindboggling complexity.

• 104 is a AVR128XXpp (or some 128k xmega)
• 102 is an AVR64XXpp (or some 64k xmega)
• 103 is a tinyAVR 1/2/3 or megaAVR 0-series (or some 32k or smaller xmega)
• the smaller AVRssXXpp parts are 103 - some guy told me that they reported 102, but I think he was mistaken because the device_spec file clearly states that they are classified as avrxmega3, which is 103.
• Anything under 100 is a classic AVR.
• Anything with 103 has the whole flash mapped to ram and MAPPED_PROGMEM_START tells you what program space addresses are offset by in the data space.
• Otherwise, MAPPED_PROGMEM_START and MAPPED_PROGMEM_SIZE tell you where the mapped flash starts, and how large the mapped area is, if MAPPED_PROGMEM_SIZE > PROGMEM_SIZE then there are multiple FLMAP options to select the section of flash that is mapped. Note that the 2 FLMAP bits are always there if any part in the part family uses at least one FLMAP (eg, a 16k DD will have the FLMAP bits in NVMCTRL.CTRLB though they will do nothing, but a tinyAVR 3227 would not because there is no 64k 2-series tiny .
• To tell yucky xMegas apart from nice modern AVRs, test for NVMCTRL- the modern AVRs have that defined, while the yucky xMega parts called it NVM.
• megaTinyCore also defines MEGATINYCORE, and DxCore defines DXCORE - if you look at Ref_defines.md (in megaavr/extras from manual install or on github (recommended - extras isn't included in the board manager version. there's a list of more easily parsed defines to delineate what exactly you're working with if you're on one of my cores.

The new parts themselves get defines of the form __AVR_AVR128DA64__ or __AVR_ATmega4809__ just like always. These are not supplied by the core, or even by the header files, but from an even more fundamental level in the device_spec files. In fact, these defines are how the compiler knows which io headers to use - look at io.h - it's a gigantic series of

#if defined(__AVR_partnumber__) 
#include "iopartnumber.h"
#elif defined(__AVR_otherpartnumber__)
and on and on and on for like 700 lines.

The new part numbers are decoded as:
ss = size - 1-3 decimal digits flash size in kb
XX = two capital letters, denoting the architecture and featureset (D = 12-bit pseudodifferential ADC and selectable oscillator that is rated for 24 goes to 32 and takes a crystal up to 48 MHz (if crystal is supported, using extended temp range parts at at room temp) and where the derivative of F_CPU_max(Vdd) = approx 0 (ie, voltage does not impact max speed), E = 12-bit true differential ADC with 1x-16x PGA and auto-accumulate up to 1024 samples so you can oversample+decimate to 17 bit resolution, though you need a very good design if you want all of those bits to be signal not noise, unfortunately saddled with the 16/20 fuse-selectable oscillator like a tinyAVR, the shitty D-like tuning with only 32 steps and autotune support. There doesn't seem to be a pattern with the second letter other than that if it has native USB, it'll be a U (as in the upcoming DU-series) - seems sequential, skipping any letter that would make a confusing abbreviation (hence Dx went DA, DB (respectively gimped flagship and real flagship), DC was skipped because it's an established electronics abbreviation, then DD which is a lower priced lower pincount part with most of the features of the DB, and the DU is next after the EA), while Ex is going EA (mid-range - not flagship parts as they only go to 64k flash and 48 pins), EB (low pincount, single usart, and two new timers that we know nothing about other than that one may have up to 8 channels (but they may not be independent - it could be 4/3rds of a TCA and do split mode, or (if we're unlucky) 4 channels and 4 inverted ones like the classic t861 had 3 channels and 3 inverted ones) and will be nominally 16 bit, and the other one is either 16 or 24 bit (the brief gives both numbers, with 2 waveform output pins, but worryingly it says "for frequency generation" which may mean "haha, you wanted PWM? No this is just a FREQUENCY generator, you get 50% duty cycle only"), and it may or may not have an on-chip pll, which if it does will be able to clock one or both of the timers, as there's nothing else on the chip that could plausibly be PLL clocked"
pp = pincount.

Modern tinyAVRs have numbers that decode as ssfp where ss is 1-2 digits indicating the size, f is 0, 1 or 2 indicating the family and hence featureset - 0 being the ones that chopped out a huge number of features to make a budget part that costs a whole 0-5 cents less than the 1-series, the 1-series being where they tested stuff for the DA/DB (triple analog comparator with window mode, TCD, etc), and the 2-series being the first appearance of the snazzy new ADC (testing it for the EA - they seem to use the tinies as testbeds for new features, or they were doing that for a while at least) and p is a code representing the pincount - 2, 4, 6, or 7 for 8, 14, 20 or 24 pincount parts. Beware that both of the last two conditions must be true on a modern tinyAVR - the tinyAVR 828 has the flash size as the first digit, a 2 as the second digit - but the last digit is an 8 so it's not a modern tiny - it's a classic AVR, likewise the 1634 has has the flash size at the start, and ends with a valid pincount code, but the tens place is a 3, and there isn't a tinyAVR 3-series

A nice consistent and systematic change from the to old part numbering system, if you can call that mess a system.... AT[mega|tiny|90[CAN|PWM]] ss[x]pyyy of the old parts, where ss was 1-3 digits of flash size, x was optionally a c, m, or u indicating CAN, PSC (power stage converter - the timer that turned into TCD, designed for control of DC-DC converters, and usb respectively, and p was nominally a single digit pincount code, but sometimes had an extra digit - either before or after it, no pattern - t841 and 861 had the 1 after signifying an upgraded version while 828 would have been an upgraded version of the t88 if they had finished the design process and shipped a processor that wasn't seriously fucked up) and yyy is 0 or more letters to differentiate the original from the slightly changed upgraded version (A), improved power management (P) a significantly changed but still compatible upgraded version (B) on-chip RF stuff (RFR then RFR2), some manner of high voltage support for battery charging applications (HVA, HVB, HVA2). The stuff with the wacky letters on the end isn't seen in Arduino-land and I looked at the datasheets, and like, chapters are missing, and presumably you need to sign an nda to see them. So nobody in arduino land would touch them with a ten foot pole except to nudge it into a storm drain. (there was also a line of ATAnnnn parts where n is a seemingly random digit - those were the AT Automotive parts, again, apparently nda needed for the real datasheet, hence absent from Arduinoland).