stm32 uart rtc timer

[irmakci]

Posted on November 12, 2012 at 02:43

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 randomly

2. my RTC on stm32 will be updated each 1 second in the rtc interrupt handler

3. my timer interrupt will handle each 1 second .(it can be alterable)

When designing uart, rtc and timer part, there are overlap sections.

For example

A. 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 mistakenly

C. 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-rtc

[Tesla DeLorean]

Posted on November 12, 2012 at 04:04

Ok, each has it's own interrupt vector, taking a few hundred micro-seconds to service, where is the complexity/race issue here?

[irmakci]

Posted on November 12, 2012 at 10:52

Thank you for answering

Problem is that uart and rtc, timer handler for exact times?(i do not want to lost some micro seconds when Uart data comes because each uart interrupt will lost some microsecond and for example for 100000 transactions(if 100usec is lost for each uart handler) ) 100000*100us = 10 Second lost?

.

1. When data comes from uart buffer for each character ,

A) i will process uart handler but when program is in uart interrupt, and at the same time if rtc interrupt comes( a RTC register), RTC will run and maybe i will not catch other uart interrupt if i make disable Uart interrupt in RTC handler routine? and

B) if i do not make disable interrupt, again i will lost some micro seconds?

if program lost some micro second each uart transaction, program rtc will shift some microsecond. True?

Is there  any algorithm for this?

Thanks in advance

Best Regards

[zzdz2]

Posted on November 12, 2012 at 12:07

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.

[Tesla DeLorean]

Posted on November 12, 2012 at 13:38

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.

[stmburns]

Posted on November 12, 2012 at 14:23

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.

[irmakci]

Posted on November 14, 2012 at 22:05

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) 2009

The 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 advance

Best Regards

[Tesla DeLorean]

Posted on November 14, 2012 at 22:25

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.