Support for NRF arm processors

[el-han]

Since I love the features of the Nordic NRF5 series processors I would love to be able to use them with modm. Some days ago I have started to implement a device tree generator similar to #19.

Nordic offers .svd files, linker scripts, startup code and CMSIS headers on their webpage:

https://www.nordicsemi.com/Software-and-tools/Development-Tools/nRF-MDK/Download

Although I'm quite busy these days and may need some time to answer I am happy about any comments and leads.

TODO

• check if license of the Nordic MDK is suitable
• extract memory size and location from linkerscripts
• extract device instances from *.svd
• Unlike the AVR and STM32 microcontrollers it seems every GPIO can be connected to an arbitrary peripheral. How can I implement this?
• extend the identifier, add pin, memory and package descriptor

[salkinium]

I love this! ALL THE DATA!!

Unlike the AVR and STM32 microcontrollers it seems every GPIO can be connected to an arbitrary peripheral. How can I implement this?

With a separate table that lists the possible peripherals. Like I did for STM32F1 remap tables. The user must then explicitly parse this information.

I'm trying to change this with #35, where the knowledge about the device file format is kept in this repo and only a Python API is exposed to the user. In this case the API would simply pretend that the table was there for every pin. (I'm just currently too busy to make significant progress).

modm-io/modm#194 is complete for the Cortex-M part, so the startup and interrupts and SysTick all work, it's "just" missing the actual HAL implementation (basic GPIO is already there). So you should be able to use it as a blueprint for NRF52.

[salkinium]

Very nice, looking forward to seeing more data! 😃

[el-han]

Unlike the AVR and STM32 microcontrollers it seems every GPIO can be connected to an arbitrary peripheral. How can I implement this?

With a separate table that lists the possible peripherals. Like I did for STM32F1 remap tables. The user must then explicitly parse this information.

As far as I understand the remap tables are a tool too keep different sets of signals together to use either the SPI pins from group 1 or from group 2 but not MISO from group 1 together with MOSI from group 2. The Nordic chips on the other hand seem to have a full featured crossbar switch and allow the user to connect an arbitrary signal to each GPIO.

Looks like remap tables won't help me here. Right now I just add the list of all signals to each GPIO pin which produces a huge .xml. But actually I would just need one list of all signals and one list of all GPIOs. Do you have any suggestions? Do you know any other microcontroller which lets the user connect signals to GPIOs without any bounds?

[salkinium]

I meant that you can simply add the signal list once to the gpio driver as a top-level list. The modm module then knows that it must use this table for all gpios. The reference to the remap table was just to show that there isn't a fixed format for GPIO signals.

[salkinium]

So you can add a signal list just like the vector table and the memory table are top-level inside the core module because the tag name is the list identifier.

[el-han]

Uh, so it's easier than I thought! Nice.

[el-han]

Okay, all TODOs are checked now. I think I'm ready for a review. I will continue tomorrow, maybe with the C++ part.

[salkinium]

I'm quite happy with this, you did everything right despite the lack of documentation ;-P
I cannot judge the data much since I'm not familiar with the NRF families.

I'd be happy to merge this now, and then later perhaps have a smaller PR that fixes/adds some things that you find during porting to modm. Is that ok?

[el-han]

Yes, that is great! I wrote myself a big reminder to absolutely provide at least some documentation before continuing the C++ part ;-)

[salkinium]

Thanks!