Thoughts about reducing use of macros in megaTinyCore?

[innermatrix]

I have been working on a library that might be a potentially useful adjunct to megaTinyCore, and I am running into an issue that I can't address on my own without support from megaTinyCore

The motivation here is: I am writing low-level code and getting annoyed that when porting my code from one MCU to another — or even the same MCU but in a different package — I have to potentially adjust a lot of repetitive information to account to differences in pin functionality between packages/MCUs. For example, if I move a TCB PWM signal from one pin to another depending on the package, I potentially have to make several adjustments between TCBx and TCBy, then also between CMPxBUF and CMPyBUF, etc.

The problem that I am running into is that from an API design standpoint it makes sense for my library to use some identifiers (like PORTA or ADC0) that are defined as macros in megaTinyCore — but because they are macros so I can't use them at all (not even as the name of an enum or a class member).

I believe that this could be entirely addressed in megaTinyCore without any backwards compatibility issues, or any impact on performance of other code, if these macros were replaced with static const expressions. For example, instead of

#define PORTA *(PORT_t)(0x0400)

use

static PORT_t& PORTA = *(PORT_t*)(0x0400)

In my experience, this change

• Has no impact on memory footprint because the global variable, being a reference, is immutable and therefore optimized away
• Has no impact on memory performance, for the same reason
• Is syntactically almost completely backwards compatible (see below for details)

but it would allow PORTA and similar identifiers to be used to name (non-global) objects in other code.

The other category of identifiers I'd love to see get similar treatment are pin names (like PIN_PA0), which could just be static const uint8_t declarations; as with the above, this would have no performance or size impact and minimal compatibility impact.

As far as compatibility is concerned, all sensible code would be completely unaffected, but there is one edge case that would break: if someone wrote code that specifically depends on these being macros, that would break; I can only think of two circumstances where that would be the case:

• #ifdef PORTA being used (perhaps to do a compile-time check for whether a GPIO port is available on a particular device)
• #foo and foo ## bar preprocessor string manipulation where foo is a macro like PORTA.

I suspect that both of these are extreme edge cases and I'd be surprised to find them in active use.

Thoughts? If this idea is welcome in principle, I'd be happy to contribute a PR to implement it.

[MX682X]

the defines are part of the avr/io.h files that are distributed with the Device packages by Microchip, they are not part of the Core.
However, why don't you just add the following somewhere in your headers?

#if defined(ATTINYxxxx)
  #define TCB_PWM TCBx
  #define CMP_PWM CMPxBUF
#elif defined (ATTINYyyyy)
  #define TCB_PWM TCBy
  #define CMP_PWM CMPyBUF
#else
  #error "Unknown Package"
#endif

TCB_PWM.CMP_PWM = z;

As far as compatibility is concerned, all sensible code would be completely unaffected, but there is one edge case that would break: if someone wrote code that specifically depends on these being macros, that would break; I can only think of two circumstances where that would be the case:

#ifdef PORTA being used (perhaps to do a compile-time check for whether a GPIO port is available on a particular device)

The Core is full of define checks, as the code base is kept as similar as possible to the DxCore, here is an example:
https://github.com/SpenceKonde/megaTinyCore/blob/master/megaavr/cores/megatinycore/wiring.c

[innermatrix]

Thanks! I could do that, but I find it inelegant. I'll pursue a direction that doesn't lead to name collisions with the vendor defines.