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 handling in the SD.
But one or two clear examples of how to register your interrupt handler should probably be clearly documented with the current approach then since it differs from what most customers are used to(?) with CMSIS and most vendor supplied example code. I don't have strong feelings either way myself though and the bootloader argument is valid if you want to handle systick interrupts in both chunks of code for example or radio and SPI events in an advanced bootloader. K. Le mercredi 27 juillet 2016, will sanfilippo <[email protected]> a écrit : > 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 > you might as well just register the interrupt vector. > > > > On Jul 26, 2016, at 7:45 PM, Kevin Townsend <[email protected] > <javascript:;>> wrote: > > > > > >> Bonsoir, > > Bilingual, impressive! :P > >> 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? > > Personally, I can't remember the last time I had the interrupt vectors > anywhere except fixed in .text. I suspect 99% of the people working with > ARM Cortex devices are also familiar with and probably are sort of > expecting the typical 'weak' approach pushed by most CMSIS based vendor > startup code. That said ... I certainly don't feel strongly about this > either way, but you probably are losing a small chunk of SRAM for something > 0.1% of users might actually make meaningful use of. > > > > Kevin > >
