Cortex-M(4) NVIC should be considered as shared driver about ada_drivers_library HOT 9 CLOSED

HI,
Yes, that would make sense. Eventually, if/when we get a more broad scope... :-)
Thanks for the comment!

from ada_drivers_library.

By the way, I would definitely appreciate receiving any other comments and/or suggestions you may have!

from ada_drivers_library.

Hi @pat-rogers, another suggestion would be to rename 'ARM' root folder to 'cortex-m' or 'arm-cm' or similar, ARM being usually pointing on arm 32b instruction set, ie not Cortex.
To come back on Cortex-M peripherals, I would see bareboard/'ARM-CM'/common/drivers/[nvic|scb|itm|etc...]

from ada_drivers_library.

A quite good naming example is present here: https://github.com/RIOT-OS/RIOT/tree/master/cpu

from ada_drivers_library.

That does seem reasonable. (Thanks for the reference to the other repo.) As you can probably tell, I am somewhat new to the ARM family, so the possibilities are not immediately obvious. I appreciate the inputs here.

from ada_drivers_library.

@aethaniel please have look at the svd branch we are trying a different project architecture over there.

from ada_drivers_library.

I’d have thought that NVIC wouldn’t be used by user projects - the only reason (*) for using it is to set up interrupts, and the RTS does that when elaborating protected handlers.

(*) Actually, since my timings show it takes about 1000 cycles to get from the interrupt to the activated task, perhaps we do need a more immediate interrupt response mechanism for low-latency high-frequency demands.

from ada_drivers_library.

You would need to program the NVIC if you want to use interrupts with a ZFP runtime.
And even when using a (ravenscar) tasking runtime - as Simon pointed out - it could be desirable (for performance reasons) to have some interrupts not be handled by the runtime.
I'm not sure how to do this (have some interrupts handled by the runtime and some not) in a 'clean' way...
.

from ada_drivers_library.

The NVIC package is now part of the cortex_m layer in the new architecture of those drivers (as well as FPU or Cache handling). So I'm closing this issue. Thanks for the report!

Best regards,

• Jerome

from ada_drivers_library.