This layer consists of memory-mapped register, interrupt, and peripheral
mappings, and also possibly of DSO (Drone Serial Output) implementations. In
this section we will overview
drone-nrf91-dso crates as
examples of the vendor-specific layer.
drone-nrf-map collection of crates is purely declarative. We try to
automatically generate as much code as possible from vendor-provided CMSIS-SVD
files. Generation of memory-mapped register bindings is highly
parallelizable. Therefore it's splitted into 12 crates, which are named from
drone-nrf-map-pieces-12 and compiled by cargo in
drone-nrf-map-pieces-* crates are all re-exported by single
drone-nrf-map-pieces crate, which can be further used by peripheral bindings.
Not all bindings can be auto-generated. We also manually declare peripheral
mappings. For the sake of compile-time parallelization, each
peripheral type is declared in its own crate
drone-nrf-map-periph-uarte.) Periheral crates are opt-in, they are
enabled by activating corresponding cargo features for
drone-nrf-map-periph-* crates are all
If the target doesn't implement usual hardware logging, as in case with nRF9160, we provide a software logging implementation. It uses special Drone Serial Output protocol to provide features similar to hardware SWO. Namely splitting the output into different ports and forming atomic packets.
drone-nrf91-dso implementation is based on software output FIFO, and utilizes
one of generic built-in UART peripheral.