Bonsoir,
As previous mails may have indicated, I’ve recently been making it
easier to bring in third party driver SDKs to the OS. I’ve taken a
fair view across the Atmel, STM and Nordic drivers, although I’ve been
working primarily with Nordic’s code.
As such I’ve added a few new directives, here is the code to allow
Nordic’s SDK to compile within Mynewt’s system:
pkg.ign_files.NRF52:
- "nrf_drv_adc.c"
- "pstorage*"
- "sdk_mapped_flags.c"
pkg.ign_dirs:
- "deprecated"
pkg.src_dirs:
- "src/ext/sdk/drivers_nrf/"
- "src/ext/sdk/libraries/fifo/"
- "src/ext/sdk/libraries/util/"
pkg.cflags: -std=gnu99
pkg.type: sdk
Where ign_files allows you to ignore compilation of a set of regexp
files (so here, if the NRF52 feature is set, we ignore the ADC driver
which is NRF51 specific.) ign_dirs allows you to ignore specific
directory names, and src_dirs allows you to override the default which
is to recursively compile src, and instead provide a list of directories
to compile.
In addition to this, the pkg.type = SDK creates an include rule which
includes every sub-directory of <pkg-name>/src/ext/ in the current
directory’s include path, along with directly including the contents
of <bsp>/include/bsp/ in the include path. This provides a reasonable
set of compilation directives (thus far) that allows me to bring in the
NRF52 SDK unmolested.
Looking through the NRF SDK, the other major difference is where and how
interrupt vectors are located. On the NRF drivers, the assumption is
that interrupt vectors are located in .text, and compiled with weak
symbols (i.e. automatically resolved.) We’ve taken an alternative
approach, and located the interrupt vectors in RAM, and used
NVIC_SetVector() to manually register these vectors.
I’m OK with NVIC_SetVector(), and indeed, the driver that uses
Nordic’s function can call that in the driver init function —
however, I think it’s worth understanding why we want this located in
RAM. It seems reasonable to me to fix the interrupt vectors in .text
and avoid the NVIC_SetVector() call — it seems like we’re spending a
bunch of RAM on something that will never change dynamically.
Thoughts?
A Bientôt,
Sterling
PS: Kudos to Nordic for being respectful about interrupt priority in
driver initialization! I was very pleased to see that all drivers allow
for the user to specify interrupt priority.
