I'm trying to port some code from a regular nano to a nano 33 BLE. Unfortunately I'm using some direct port manipulation/reading on PIND and PORTB which are not defined for the newer hardware.
This should not be a surprise since it's a completely different CPU, but I can't find documentation to tell me what the equivalents are for the fancier processor. Any clues?
have a look nRF52840_PS_v1.1.pdf more precisely at section "6.9 GPIO — General purpose input/output" (it's a bit richer than the straightforward PORT registers of an ATmega328P)
having a look at the source code for digitalRead or digitalWrite could help (or get you confused)
void digitalWrite( uint32_t ulPin, uint32_t ulVal )
{
if (ulPin >= PINS_COUNT) {
return;
}
ulPin = g_ADigitalPinMap[ulPin];
NRF_GPIO_Type * port = nrf_gpio_pin_port_decode(&ulPin);
switch ( ulVal )
{
case LOW:
port->OUTCLR = (1UL << ulPin);
break ;
default:
port->OUTSET = (1UL << ulPin);
break ;
}
}
int digitalRead( uint32_t ulPin )
{
if (ulPin >= PINS_COUNT) {
return 0;
}
ulPin = g_ADigitalPinMap[ulPin];
NRF_GPIO_Type * port = nrf_gpio_pin_port_decode(&ulPin);
uint32_t const bm = (1UL << ulPin);
// Return bit in OUT or IN depending on configured direction
return (bm & ((port->DIR & bm) ? port->OUT : port->IN)) ? 1 : 0;
}
Thanks. That latter post looks like I can dig what I need out of it. Probably 
J-M-L:
having a look at the source code for digitalRead or digitalWrite could help (or get you confused)
That looks similar to how it's done with SAMD chips.
gfvalvo:
That looks similar to how it's done with SAMD chips.
There is a very good reason for that. 8)
Hutkikz:
There is a very good reason for that. 8)
Yes!
The nano 33 BLE is based on the nRF 52840 microcontroller which is a Cortex-M4F (so a Cortex-M4 with FPU - known as FPv4-SP extension), clocked @ 64 MHz
Atmel's SAMD21 processor (used on the Arduino/Genuino Zero, MKR1000 and MKRZero boards) is an Cortex-M0+ Architecture
These ARM Cortex-M are in a group of 32-bit RISC ARM processor cores licensed by Arm Holdings (Cortex-M0, Cortex-M0+, Cortex-M1, Cortex-M3, Cortex-M4, Cortex-M7, Cortex-M23, Cortex-M33, Cortex-M35P.).
The Cortex-M4 (and a few others) cores have an FPU silicon option, and when included in the silicon these cores are labeled as "Cortex-Mx with FPU" or "Cortex-MxF" and those have become popular replacements for 8-bit chips especially in applications that benefit from 32-bit math operations (the F versions) and thus in modern “arduinos”
The Cortex-M0+ implements the ARMv6-M architecture spec and the Cortex-M4 is based on the ARMv7E-M architecture but The architectures are binary instruction upward compatible from ARMv6-M to ARMv7E-M.
=> it means Binary instructions available for the Cortex-M0+ can execute without modification on the Cortex-M4F
J-M-L:
Yes!The nano 33 BLE is based on the nRF 52840 microcontroller which is a Cortex-M4F (so a Cortex-M4 with FPU - known as FPv4-SP extension), clocked @ 64 MHz
Atmel's SAMD21 processor (used on the Arduino/Genuino Zero, MKR1000 and MKRZero boards) is an Cortex-M0+ Architecture
These ARM Cortex-M are in a group of 32-bit RISC ARM processor cores licensed by Arm Holdings (Cortex-M0, Cortex-M0+, Cortex-M1, Cortex-M3, Cortex-M4, Cortex-M7, Cortex-M23, Cortex-M33, Cortex-M35P.).
The Cortex-M4 (and a few others) cores have an FPU silicon option, and when included in the silicon these cores are labeled as "Cortex-Mx with FPU" or "Cortex-MxF" and those have become popular replacements for 8-bit chips especially in applications that benefit from 32-bit math operations (the F versions) and thus in modern “arduinos”
The Cortex-M0+ implements the ARMv6-M architecture spec and the Cortex-M4 is based on the ARMv7E-M architecture but The architectures are binary instruction upward compatible from ARMv6-M to ARMv7E-M.
=> it means Binary instructions available for the Cortex-M0+ can execute without modification on the Cortex-M4F
but the registers of peripherals of the MCU can be very differnet
Indeed my point was more on the fact that the two processors had similarities.
Juraj:
but the registers of peripherals of the MCU can be very differnet
Right! The peripherals and the methods for accessing them are largely independent from the ARM core. Port pins are peripherals. Compare the digitalRead() / digitalWrite() source code for SAMD (Microchip) processors to that for the MK20, MK64, and MK66 (NXP) processors used on the Teensy 3.x boards.
For this kind of port, I would just change all the port manipulation back to regular digitalWrite(). Get it to compile and upload, even if it isn't going to work right.
The port manipulation was probably done for speed. The new chip is likely faster, so it doesn't need the non-portable code. Your job is done.
If it truly did need port manipulation (the only valid reason would be some kind of parallel bus write) then dig into the datasheet and fix the code.
MorganS:
For this kind of port, I would just change all the port manipulation back to regular digitalWrite(). Get it to compile and upload, even if it isn't going to work right.
I did exactly that 
The port manipulation was probably done for speed. The new chip is likely faster, so it doesn't need the non-portable code. Your job is done.
Probably will be ok.
If it truly did need port manipulation (the only valid reason would be some kind of parallel bus write) then dig into the datasheet and fix the code.
One section does indeed need parallel write (probably). I did find the pin numbers based on what j-m-l gave me so I've some code that may do the job. It's academic for now though because I can't even get "Hello world" to work on the device.