Where do I start with creating a new map?

[FrozenDroid]

Hi,

I would like to create a nRF9160 map.
One thing that's unclear to me is what the 12 different pieces are for.
Could you explain that?

[alfredch]

I think he did it for performance reasons or to overcome some file-size limits. In Drone, the mapping is generated based on the vendor's SVD files, and there are several steps involved. I quote valff's answer to a similar question I had in a private conversation:

1. drone-stm32-map runs build.rs build script, which is a Cargo feature.
2. The script generates a rust source file with help of drone-stm32-map/svd subcrate.
3. The resulting source file contains calls to procedural macros defined in drone-core and included with include! core builtin macro.
4. The procedural macros generate code on the fly, this is a core language feature.

[valff]

The reason of so many subcrates here is that bindings generation parallelizes very good, and we gain almost 12x compile time reduction on a 12 core processor. The downside is that it is inconvenient to maintain many redundant Cargo.toml and lib.rs files. I'm editing them using Emacs macros.

periph-* crates just group registers by peripherals. For example this allows us to write code generic over UART1, UART2, ..., LPUART1. The problem is that often these peripherals have small differences, so they should be addressed by these crates.

I recommend to skip periph-* crates for the initial support, and add only register and interrupt mappings. For this you will need:

1. Add an SVD file to svd_files/.
2. Edit svd/src/lib.rs to recognize the SVD file.
3. Add a new feature to Cargo.toml, src/pieces/Cargo.toml, and src/pieces/*/Cargo.toml.

Also we need to modify https://github.com/drone-os/drone to be able to generate a new project for the new device family. There is a related pull request: drone-os/drone#1

[FrozenDroid]

Are you saying to add the nrf9160 to this crate? Wouldn't it make more sense to create it as a different crate?

[valff]

I missed that this is not an stm32, sorry. For these chips we should create drone-nrf-map. I'm not familiar how deeply it differs from nRF5? Because nRF5 is fairly unusable without the SoftDevice. Is it the same for nRF9160?

[FrozenDroid]

I'm mostly unfamiliar with nRF products, so I'm not sure about what SoftDevice is. I've played with the nRF9160 a little bit in Rust already and so far it looks very usable! Unfortunately, it does require FFI with a binary (https://github.com/thejpster/nrfxlib-sys) but it seems very usable.

[valff]

We use nRF52 chip in our project. SoftDevice is a binary blob that should be flashed to the chip. And your firmware is supposed to be placed at a fixed location right after the SoftDevice blob. SoftDevice transparently proxies all interrupts to your vector table as if your firmware it written at the beginning of the flash memory. This works fine with Drone. But to access the SoftDevice ABI one should use the nRF5 SDK, which is a C library. I created an experimental Rust wrapper for the SDK, but the problem is that the SDK is very macros-heavy. And the bindgen crate can't wrap C macros yet.

[FrozenDroid]

Oh, I see. No, apart from the "Secure Partition Manager" that you have to flash (I think this is just in the bootloader section of flash).
The crate I linked works quite well. It's a wrapper around a library binary. Maybe I'll reverse engineer it one day to get everything all native Rust.

[valff]

When using the SDK there is no need for the register mappings. Because the SDK accesses registers directly and provides more high-level functions. But I'm thinking of another approach. Maybe it would be better to reimplement only the SoftDevice interface in Rust and provide register bindings from SVD file as in STM32.

[valff]

That nrfxlib-sys crate looks very similar to my nRF5 SDK wrapper. So I think you don't need a crate like drone-stm32-map with it. Try with drone-core and drone-cortex-m only.

[FrozenDroid]

Well, to do networking things only, that should indeed be enough. I also want to use peripherals such as GPIO and UART though.
The nrfxlib-sys crate only does networking related things.

[valff]

Yes, then a new drone-nrf-map crate is needed.

[valff]

https://github.com/drone-os/drone-nrf-map was implemented.