2012-11-11 05:43 PM
Hello,
i need help about designing a stm32 project. Thought is follows. (i must not use any RTOS)1. my stm32100 will handle uart interrupt randomly2. my RTC on stm32 will be updated each 1 second in the rtc interrupt handler3. my timer interrupt will handle each 1 second .(it can be alterable)When designing uart, rtc and timer part, there are overlap sections.For exampleA. When RTC interrupt comes, if UART interrupt comes, what will happen? RTC handler will not work properly?B. With same opinion, when Timer updates each 1 second and if uart interrupt comes, again Timer will update mistakenlyC. I want also to make some operations in UART interrupt routine like running other 2 timers on stm32 for protocol like modbus...Is there any opinion for solving this problem?...Thanks in advance Best Regards #stm32-timer-uart-rtc2012-11-11 07:04 PM
Ok, each has it's own interrupt vector, taking a few hundred micro-seconds to service, where is the complexity/race issue here?
2012-11-12 01:52 AM
2012-11-12 03:07 AM
if program lost some micro second each uart transaction, program rtc will shift some microsecond. True?
Not true, RTC will generate IRQ every second, it doesn't depend on CPU usage.Interrupt handler delay is not crucial in this case.
2012-11-12 04:38 AM
Well sounds like you need a timer base with a finer granularity than seconds.
I'm also not sure how you get accumulating bias when the timers, etc fire off a continuous source, they don't stop while servicing interrupts. You might observe some jitter and latency but the next interrupt won't move away as a result. Neither the RTC or SysTick should be impacted or skewed by the service routine unless those routines that too long, and you over-saturate the processor. They will have some marginal drift with respect to each other due to use of different sources, how bad this will depend on the nature of the sources chosen. If you want a hard time line you should have a free running counter or timer, ideally running at the system clock (a few nanoseconds granularity), and use that to compute assorted deltas. The core cycle counter in the trace unit is worth a look, or you could use a 16 or 32-bit timer as a fixed time base. Be conscious of how many ticks there will be in a second, or whatever measurement period you are working with.2012-11-12 05:23 AM
Of course I don't know your exact problem, but a couple thoughts:
1) You could run the UART with DMA to avoid taking a UART interrupt on every single character. Of course that also means that you don't get notified of a new character to look at every time.2) You might run less of your code in the interrupt service routine and more in a routine that can be interrupted. Of course that means more synchronization issues to worry about.2012-11-14 01:05 PM
Thank you for all suggestions.
But i wonder something about _enable_irq();_disable_irq(); i looked 1. Cortex™-M3 Technical Reference Manual 2. Cortex™-M3 Generic User Guide 3. ARM Cortex-M3 Processor Software Development for ARM7TDMI Processor Programmers (white paper) 2009The questions are as follows.A. First, (page11 @3) says that The Cortex-M3 processor does not disable interrupts when entering an interrupt or exception handler ? Q: if i want to protect some data in interrupt routine, what will i do for critical sections?B. if we think that we can change disable and enable situation in interrupt routine.In the interrupt routine, if we disable an interrupt(which we want to handle after current interrupt) , can i handle interrupt routine after current interrupt routine later? Simply, if i disable interrupts in interrupt routine and re-enable later, are there any pending bits for being waited still and can i still catch after making enable ? or will i lost ?Thanks in advanceBest Regards2012-11-14 01:25 PM
Well if you keep your interrupts at the same pre-emption level they will execute nicely one after the other, and not step on each other. Keep them short.
''CPSIE I'' and ''CPSID I'' should function as expected to lock critical structures in foreground tasks. Interrupts pend until you clear them, if you don't clear them they will re-enter. It will not however accumulate multiple interrupts from a single source, so you will need to service them before the second, or subsequent, one arrives so you don't lose it. ie for a 100 ms SysTick, you'd better not be taking 200+ ms. Interrupts from multiple sources will be dispatched based on arrival, NVIC settings, and vector# for those with the same settings.