usart interrupts vs freertos polling

[jhanc.11]

My application has a low priority usart receive function - meaning that if characters are delayed it's no big deal. I've been using interrupts with a callback receiving one character at at time with a read always outstanding. I process flags and buffer within my code. I'm thinking of switching to freertos for the charting and interface functions. I tried the code with interrupts and callback and then figured out that the callback is on the interrupt vector level (can't be assigned to a task). So if I wanted to lower the priority of the usart read, would I be better off polling in a low priority freertos task? That way if one of the higher priority interrupts came in the mcu wouldn't be in an interrupt routine.

Thanks for all your help.

Jerry

[S.Ma]

WCET is the critical latency between interrupts and interrupt disabled code segments. This will let you know if there is a probabililty that interrupt overrun occurs (do you check this status flag in your ISR?)

Beyonf this, if uart reactivity and ram are flexible, use uart wity dma cycling a ram buffer, which bigger its size, slower its polling period. RTOS is an extra SW layer that brings some level of convenience at energy and memory footprint cost.

[jhanc.11]

I looked at using DMA with a circular buffer and it's just another learning curve.

What I do today is put up a read of one byte. When that comes in thru the interrupt, I increment the buffer pointer, set a flag and put up another read. When mainline code (not within the interrupt vector) uses the received data, it resets the flag (if it processed the entire buffer) and the sets buffer pointer to zero or appropriately if it didn't process it all. The mainline code processes incoming commands by looking at the first character and then depending on where the \n (new line 0x0a) is for the command, it checks that location. If the 0x0a isn't where expected, it sets it all to zero, effectively clearing the buffer. This is working for me. The mainline code is going to be moved to the default RTOS thread. But I was wondering if by not using interrupts and just blocking on its own thread it would work the same way except I don;t have to worry about the interrupt vector blocking the RTOS dispatcher.

Thanks for the input. Maybe I'll review the DMA method again.

Jerry

[S.Ma]

Byte by byte incoming buffer, double it so that you can still receive if not yet done with previous one. Going further, the road will end with cyclic dma. Test data overrun in your interrupt code.