Search code examples
cinterruptuartdma

Checking a char buffer from UART - what is the best practice?

Which of the following is better practice (or please suggest better alternatives) when using a global buffer with DMA with UART on an STM32 embedded application (no RTOS):

Option 1: When entering the ISR after a DMA to Idle event on the UART I have a global buffer that has been filled with characters. I set a flag in the ISR and exit quickly. In main loop I check the flag and process the contents of the global array. I then reset the flag at the end of processing.

Possible Advantages

  • Keeps the ISR short and moves processing to main loop.
  • Implements "zero-copy" i.e. not copying data round unnecessarily.

Possible Disadvantages

  • As processing is done in the main loop on the global array - incoming UART characters could change the array contents as I'm processing it?

Option 2: When entering the ISR after a DMA to Idle event on the UART I have a global buffer that has been filled with characters. I process the characters within the ISR and then set a flag according to what output is necessary.

Possible Advantages

  • Data will not change whilst I'm processing it as the interrupt will not be active.

Possible Disadvantages

  • Makes the ISR long.
  • Other interrupts can't interrupt that interrupt.

Or, does anyone have any other alternatives, e.g. setting a flag and then copying the buffer immediately in the main loop to a local variable, and then processing that local variable itself?

Grateful for any advice and comments.

Solution

  • I process the characters within the ISR

    #2 is a weak choice. ISRs are not meant for long execution time. Get in, get out.

    incoming UART characters could change the array contents as I'm processing it?

    Avoid a race condition of data arriving while processing the buffer in option #1.

    Option 3: use 2 buffers. Let the DMA fill the one that is not being processed. The ISR, after filling one buffer, simple swaps which buffer to use. Now the processing is done in the foreground with the proviso that it must be done before the alternate buffer is filled, else the ISR should whine with setting a buffer overflow error flag.

    Could use more than 2 buffers is processing is sluggish/jerky, yet fast enough over a long period. Yet I suspect 2 will work fine for OP.