Re: 3rd party SDKs, and Interrupt vectors on NRF52

One thing I didnt mention earlier was that some cortex-M processors do have a VTOR register which can be used to relocate the vector table. The register has some “odd” alignment restrictions but those are not all that tough to deal with. This would be one way to deal with the bootloader issue

Re: 3rd party SDKs, and Interrupt vectors on NRF52

Hi Will, That's a good point. I've usually worked with very simple boot loaders in the past. One of my biggest problems with the SD architecture (and motivation for moving to mynewt and nimble) was the lack of strict timing and direct interrupt control at the app level due to the interrupt

Re: 3rd party SDKs, and Interrupt vectors on NRF52

+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 wrote: > > Bonsoir, > > As previous mails may have indicated, I’ve recently been making it easier to > bring in third party

Re: 3rd party SDKs, and Interrupt vectors on NRF52

So how does a bootloader that uses interrupts and an application that uses the same interrupt work? If you have interrupt vectors in .text, only one “application” can own that interrupt vector. Of course, the interrupt vector in . text can look up a function pointer to call, but in that case

3rd party SDKs, and Interrupt vectors on NRF52

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