+1! This will make things MUCH easier when it comes to enabling SPI, I2C, etc. across boards.
dg > On Jul 26, 2016, at 10:35 PM, Sterling Hughes <[email protected]> wrote: > > 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. -- David G. Simmons (919) 534-5099 Web • Blog • Linkedin • Twitter • GitHub /** Message digitally signed for security and authenticity. * If you cannot read the PGP.sig attachment, please go to * http://www.gnupg.com/ Secure your email!!! * Public key available at keyserver.pgp.com **/ ♺ This email uses 100% recycled electrons. Don't blow it by printing! There are only 2 hard things in computer science: Cache invalidation, naming things, and off-by-one errors.
signature.asc
Description: Message signed with OpenPGP using GPGMail
