[En-Nut-Discussion] NutExitCritical() behaviour on ARM Cortex-M

[bon at elektron.ikp.physik.tu-darmstadt.de]

Dušan writes:
...
> I realized later, when the Nut community rejected this approach, that if 
> you run a normal code,
> you should be at zero priority level. So there is no need to store int 
> priority, except in drivers.

Probably the patch as such got not "rejected". Few people with commit
rights are still active, mostly I do commits. Perhaps I did not fully
understand the code or the need for that feature or it got lost with
other work. Most probably I feared collateral damage.

And as you tell
" that if you run a normal code, you should be at zero priority level.
  So there is no need to store int,except in drivers."

So make that a new API, like NutXxxxCriticalIrq(). That way we do not
mess up with NutEnterCritical() as used in the base ethernut code. That
code would only be arch specific with much less chance for collateral
damage. Philipp, get inspired by the other OSes. Aggree on an API with
Dusan and send patches!

> priority, except in drivers.

> For drivers I found following 2 examples:
> 
> You can check e.g. Zephyr RTOS: https://github.com/zephyrproject-rtos/zephyr
> irq_disable ~ arch/arm/core/irq_manage.c:arch_irq_disable ->
> -> ext/hal/cmsis/Core/Include/core_cm4.h:NVIC_DisableIRQ(), which uses 
> NVIC->ICER instructions to disable ints.
> I think no cpsid instruction.
> 
> Similar with FreeRTOS - https://github.com/jameswalmsley/FreeRTOS
> Source/portable/GCC/ARM_CM4F/port.c:vPortEnterCritical() -> 
> portDISABLE_INTERRUPTS
> vPortRaiseBASEPRI - I think this is called from normal context
>      New priority is stored into basepri register,
>      isb, dsb are used to enable immediate execution of pending ints
> 
> ulPortRaiseBASEPRI - here priority is first saved into a register (for 
> further restoral)
> 
> ---------
> Current Nut/OS cm3 port does not use isb instruction.
> Can anyone say if it is needed?

SNV Head uses __DSB() in stm32f2_4_flash.c.

ISB would probably be needed in the CM3 NutXxxxCriticalIrq() implementation.

In the arch/cm3/ directory, I only find stm32_owitim.c using 
a critical section in a interrupt routine. Here any interruption would confuse
timing and so  all interrupts are blocked, but this should probably
get NutXxxxCriticalIrq() when the API exists.

Cheers


-- 
Uwe Bonnes                bon at elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 1623569 ------- Fax. 06151 1623305 ---------