Nano Every Port Manipulation

I recently switched from the Nano to the Nano Every due to the performance improvements. I know there are some incompabilities between these boards thus the registers of the Every must be emulated (while compiling for instance). But it seems like the code is not completely compatible as well. For the use of infrared components (Reading an infrared code) it is advised to do port manipulation to skip some clock cyles of the digitalRead() method and read the raw value. That means one uses the PIND macro to read the digital values from the pins faster as usual. That worked fine for the old Nano. The Every does not have this macro (yet?) and I did not found any alternatives to read the desired values. The Arduino IDE will not let me compile the code.

So the main questions are:

  1. Is that a mistake of the IDE (Should PIND be available on the Every)?
  2. Are there any other ways to read the pin values without PIND?

Although the ATmega4809 microcontroller of the Nano Every is of the same AVR architecture as the classic Nano's ATmega328P, it has some really significant differences. As you discovered, one of these is the register names. This is why you found that PIND was not defined for the Nano Every.

Here is an example code for the Nano Every that prints the state of Arduino pin 2 to the Serial Monitor:

void setup() {
  Serial.begin(9600);
}

void loop() {
  Serial.println(bitRead(PORTA.IN, 0)); // print the state of pin 2 (PORTA, bit 0)
  delay(500);
}

You'll find all the information you need about this stuff in the "megaAVR 0-series Family Data Sheet" that's available for download from the "Documents" tab of this page:
https://www.microchip.com/wwwproducts/en/ATMEGA4809
Check section 15 of that datasheet. There is a nice overview in section 15.3.2.1.

Vincentklw:

  1. Is that a mistake of the IDE (Should PIND be available on the Every)?

I'm not sure. There is some attempt to provide a compatibility layer that emulates the ATmega328P registers (which you can disable via Tools > Registers emulation, but clearly this is far from a complete emulation. I don't know whether this is a matter of they haven't gotten around to doing it all yet, or if the current level of emulation is as much as is technically possible to accomplish. The emulation system used on the Nano Every was put in place for the Uno WiFi Rev2, which has been out for well over a year now so it's current state could be considered fairly mature.

I know there are some incompabilities between these boards thus the registers of the Every must be emulated

This is an incorrect statement.
The Every uses the ATmega4809, which is best described a “VERY incompatible” with the ATmega328p used in the Uno.
However, this does NOT require emulation of the registers. “Some” emulation of the 328p registers is provided by the new core, but ideally, you should use DIFFERENT registers…
(Every uses the same processor as the “Uno WiFi2”, so you may want to check out some of the discussions that have already taken place in that part of the Forum.)

That means one uses the PIND macro to read

PIND is not a macro.
PIND is a register name of ATMEGA328p

PIND is not a macro.
PIND is a register name of ATMEGA328p

Angels dancing on the head of a pin.
PIND is a macro that implements a register name on the ATmega328p:

// (from include/avr/iom328p.h)
#define PORTB _SFR_IO8(0x05)

As it happens, there is a nearly exact equivalent of PORTB at the CHIP level: VPORTB.OUT
It does the single-instruction constant bitset/bitclear, etc (unlike the new PORTB->OUT, alas.)

However, the "emulation" provided by the megaavr code goes beyond that, using C++ features to override assignment operators to the old Uno port names, and "re-map" the pins. So on Uno WiFi (for example) digital pins 0-7 are scattered across ports A, B, C, and F instead of being a nice in-order breakout of PORTD, but the emulation package will let you say "PORTD = 0", and have the pins that were PORTD on the original Uno get set to 0. (much more slowly, alas, and interfering with the "new" style access to the ports. It's ... something I probably would have done differently (or not at all), if it had been my decision.)