Re: NutExitCritical() behaviour on ARM Cortex-M
bon-1JbLm1bU5j5ZIx36JBfelj3+ndqKAYMe9FMPySWZwLkb1SvskN2V4Q@public.gmane.org Thu, 5 Dec 2019 18:50:23 +0100
| Newsgroups | gmane.comp.hardware.microcontrollers.ethernut |
|---|---|
| Message-ID | <[email protected]> |
Du=B9an 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/zep= hyr > 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 > =A0=A0=A0 New priority is stored into basepri register, > =A0=A0=A0 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 conf= use timing and so all interrupts are blocked, but this should probably get NutXxxxCriticalIrq() when the API exists. Cheers -- = Uwe Bonnes bon-1JbLm1bU5j5ZIx36JBfelj3+ndqKAYMe9FMPySWZwLkb1SvskN2V4Q@public.gmane.org Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 1623569 ------- Fax. 06151 1623305 --------- _______________________________________________ http://lists.egnite.de/mailman/listinfo/en-nut-discussion