nRF52 support: nRF52840 feather of adafruit

[fixus971]

I checked many libraries and like your DirectIO.
It would be great to get support for these chips please.
I am tried to add support for nRF52 serie but fall in tilt looking your technical code.
I have a nRF52830 and nRF52840 to test.

I found:
`
const uint32_t g_ADigitalPinMap[] =
{
// D0 .. D13
25, // D0 is P0.25 (UART TX)
24, // D1 is P0.24 (UART RX
10, // D2 is P0.10 (NFC2)
47, // D3 is P1.15 (LED1)
42, // D4 is P1.10 (LED2)
40, // D5 is P1.08
7, // D6 is P0.07
34, // D7 is P1.02 (Button)
16, // D8 is P0.16 (NeoPixel)
26, // D9 is P0.26
27, // D10 is P0.27
6, // D11 is P0.06
8, // D12 is P0.08
41, // D13 is P1.09

// D14 .. D21 (aka A0 .. A7)
4, // D14 is P0.04 (A0)
5, // D15 is P0.05 (A1)
30, // D16 is P0.30 (A2)
28, // D17 is P0.28 (A3)
2, // D18 is P0.02 (A4)
3, // D19 is P0.03 (A5)
29, // D20 is P0.29 (A6, Battery)
31, // D21 is P0.31 (A7, ARef)

// D22 .. D23 (aka I2C pins)
12, // D22 is P0.12 (SDA)
11, // D23 is P0.11 (SCL)

// D24 .. D26 (aka SPI pins)
15, // D24 is P0.15 (SPI MISO)
13, // D25 is P0.13 (SPI MOSI)
14, // D26 is P0.14 (SPI SCK )

// QSPI pins (not exposed via any header / test point)
19, // D27 is P0.19 (QSPI CLK)
20, // D28 is P0.20 (QSPI CS)
17, // D29 is P0.17 (QSPI Data 0)
22, // D30 is P0.22 (QSPI Data 1)
23, // D31 is P0.23 (QSPI Data 2)
21, // D32 is P0.21 (QSPI Data 3)

// The remaining NFC pin
9, // D33 is P0.09 (NFC1, exposed only via test point on bottom of board)
`
...

and

`
/**

• @brief Function for extracting port and the relative pin number from the absolute pin number.
• @PARAM[in,out] p_pin Pointer to the absolute pin number overriden by the pin number that is relative to the port.
• @return Pointer to port register set.
  */
  __STATIC_INLINE NRF_GPIO_Type * nrf_gpio_pin_port_decode(uint32_t * p_pin)
  {
  NRFX_ASSERT(*p_pin < NUMBER_OF_PINS);
  #if (GPIO_COUNT == 1)
  return NRF_P0;
  #else
  if (*p_pin < P0_PIN_NUM)
  {
  return NRF_P0;
  }
  else
  {
  *p_pin = *p_pin & (P0_PIN_NUM - 1);
  return NRF_P1;
  }
  #endif
  }
  `

Kind regards.

[mmarchetti]

Hi @fixus971, thank you for opening this issue.

Since that board type is not supported yet, you should be able to use DirectIO in fallback mode. That will give you the ability to write your code using Pin objects instead of calling digitalRead and digitalWrite directly, but without a speed boost.

I'm open to a PR adding support for this board (with speedup), and can help you with it, but I won't have time to do it myself soon.

This would be a new board family parallel to the AVR, SAM, and SAMD types currently supported by DirectIO. SAM is the simplest so you could look at that as an example. The main parts of the implementation would be:

• update include/ports.h to detect and support the new NRF family based on whatever build flags are available to detect this. If compiling for NRF, include ports_nrf.h.
• create include/ports_nrf.h. In that file, detect the specific board you have using build flags (e.g. NRF52840_FEATHER) and create the define_port and define_pin macros. The content of those macros is specific to the board family - they would use the functions defined in nrf_gpio.h. The existing ports_sam.h shows how this is done for SAM boards. This code would be generic to all NRF boards.
• create a new include/boards/nrf directory and in that, create a file specific to the board you have. This file contains only the pin number mapping, using define_pin like the other board definition files.

[fixus971]

Hi. Thanks for answer and good instructions to implement new board family.
I have many things to do as you but I want to try to implement this.
Thanks