hello dear forum, I m doing a project with STM32F103 uC I have a critical code where I want this code not be interrupted by any interupt - and after this critical code is executed I want enable interupts again however I want that STM32 doesnot "oversee" any interrupt which is occured during this "disabled" time It should execute any pending ISR whenever I enable global interrupt again i.e this ISR should not be left unexecuted how can I do this in GCC ? thank you
I'd go for this one (should already be defined in the CMSIS header files):
1 | /*disable all interrupts*/
|
2 | static inline __attribute__((always_inline)) void __DISABLE_IRQ(void) |
3 | {__asm volatile("CPSID i");} |
4 | |
5 | /*enable all interrupts*/
|
6 | static inline __attribute__((always_inline)) void __ENABLE_IRQ(void) |
7 | {__asm volatile("CPSIE i");} |
See also the ARM documentation in CPSIE: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dai0321a/BIHBFEIB.html
Note that "CPSID i" is called "disable interrupts", and the SysTick is an exception, not an interrupt. However, "CPSID i" turns also off the SysTick exception. You can also use "CPSID f" instead of "CPSID i", to include fault handlers: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0497a/BABHBAAB.html
mehmet karakaya schrieb: > i.e this ISR should not be left unexecuted Interrupts are sticky, so disabling core interrupts just delays execution of a handler. It does not get lost unless interrupts are disabled long enough, to let a second interrupt of the same kind happen meanwhile.
Every interrupt source has it's pending flag. And whenever this flag was set by an event, the CPU execute the interrupt, after enabled. If you enable the interrupt after 10 years, the interrupt was still executed at this time.
mehmet karakaya schrieb: > I have a critical code where I want this code not be interrupted by any > interupt At first (very first!) try to avoid such kind of code. There is always a option to solve a problem in a different way. Then consider to use the Keil compiler, because the Keil is capable to use SVC's (supervisor calls) - but the GCC is not capable to do so. If you insist to use the GCC, then you need to write a wrapper for SVC's in assembler. The purpose of the SVC is, that the SVC can be done in Software and the called code runs not in user mode, but instead in supervisor mode. This may be priorized properly, so you have exactly what you want - without using such "disable_int" and so on. W.S.
W.S. schrieb: > If you insist to use the GCC, then you need to write a wrapper for > SVC's in assembler. It's surprising to see you recommending to avoid Assembly code ?
W.S. schrieb: > The purpose of the SVC is, that the SVC can be done in Software and the > called code runs not in user mode, but instead in supervisor mode. Which makes sense if you are using an RTOS. But if there is an RTOS anyway, it should provide easy means for code parts that must not be interrupted. However, when going bare metal, I think there is no user mode because all code runs as privileged. There are a number of occasions where disabling interrupts makes sense. When fumbling around with the core clock, for example. Or when writing to the flash. Ok, it is ill-advised for synchronising data between application and interrupts, that has a design smell. In general, GCC has some advantages over Keil. No code size limit, and GCC exists cross-platform so that you can develop, debug and test the code e.g. on a host PC. When developing free software, Keil is out of the game anyway because it would be self-defeating to require a non-free tool to build free software.
Nop schrieb: > However, when going bare metal, I think there is no user > mode because all code runs as privileged. This is rather not the case. But I think, we do not need to have arguments. Simply spoken the SVC rises the privilege to the programmed level and when all other interrupt levels are tuned accordingly, then our TO mehmet karakaya has the final solution. But he seems to be absent... W.S.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.