Usage of callbacks and circular buffer UART reads using DMA

Question

Trying to understand the flow of the DMA transfer via uart:

- Configure uart
- Configure dma
- enable DMA stream to initiate the transfer
- IRQ handler gets fired 
- disable interrupts, and invoke `DMAXferCmplCallback()` in case of receiving data from the uart
-  write the received data to a FIFO in memory (circular buffer) while keeping track of the start/end index.
-  process the data / do any action based on what was received?

Is that a general idea? My questions:

• do we really need to have a callback? is the main reason for having it to mainly process the incoming data? is it better than something like:

    while(true) {
        usart_serial_read();
        parse_serial_read();
        execute_serial_data();
        //clear out the rx buffer for the next input ...
     }

• is circular buffer really required if I don't have to keep track of past inputs? One reason I know circular buffers are useful is how you can continue writing to it without having to worry about overflowing it like in case of a linear buffer since you can wrap things around in a FIFO. How I have it now is I receive the data, store it into a linear buffer, parse it before \r, and then clear it. This way I have the full buffer prior to each input reading.
• should the callback be a part of the uart or dma file?

Answer 1

In general, how to use DMA will depend on what data you transfer and how much.

At least I don't understand why would you disable interrupts, while on STM32 the DMA itself can implement a ring or ping-pong buffer. As soon as one half of the buffer is full, it triggers you with the interrupt (which calls the callback) and keeps receiving data into the second half of the buffer.

But if you are receiving say single keypresses from a terminal program, you most certainly don't want to wait until half-buffer worth of letters has arrived, you would poll the DMA controller if any bytes and how many bytes have been received so you can act on them.

Answer 2

Since human entered ASCII characters usually have termination characters, I just used the UART character match interrupt on the STM32F3 to flag to the main loop to parse with the half-transfer of transfer complete interrupts to detect invalidly long messages. Half-transfer interrupts setting flags (possibly combined with timer interrupts) to trigger the main loop to parse would be more suited to streaming data or data that has no termination characters.

But LAME. The STM32F4 USART does not have character interrupts. It's address matching on an address mark interrupt is also much less developed than the STM32F303 (the character match and address match share registers).

Half-transfer interrupts would be best for continuous data streams that will regularly fill the buffer and trigger the parsing to occur. Not so good for user inputs. What would happen is the only commands that would get processed immediately are those that exactly matched the half-buffer size and only if they were entered when the buffer was empty. Any other time, the command either doesn't get processed because it is too short, or it only gets processed when more commands are entered so that the buffer is filled past half (and no command that crossed that half-buffer point would get processed at that time either).

Timer interrupts to trigger parsing would work better for user inputs so commands are promptly executed (from the user's perspective anyways) regardless of length since it does not rely on a constant data stream to trigger parsing like the DMA half-transfer interrupt would.

You don't need circular buffers for UART data but they make the most efficient use of your buffer memory and let you have the longest messages lengths compared to ping-ping buffers or simple linear buffers: electronics.stackexchange.com/questions/498526/…