When I am learning about DMA, I came to know that it can be implemented in UART peripheral operations too. Till now, I have used UART peripheral for simple communication operations. Sometimes I use it for Modbus protocol based projects. Put aside, simple projects, in Modbus protocol projects, I constantly process every byte received via UART receive interrupt to do further process quickly or with very minimal delay.

But DMA explains that it can trigger CPU interrupt after all of its buffer/half of buffers get filled only. Also, there is a situation that I don't know how much data comes via UART reception. If I receive only 4 bytes, then I need to process it. If I am supposed to receive 120 bytes to process, I need to wait for it. So here the length is not constant, at least in my requirements. But using DMA with UART needs constant byte count as far as I know. So, I dropped the idea to use DMA in Modbus based communication projects. Is it correct?

But using DMA free CPU burden more than a regular interrupt method. But in which applications can I use it? In which applications is UART + DMA concept more suitable than normal UART interrupt method? If there is any application link or examples available it will be helpful.

  • \$\begingroup\$ Check to see if your UART module has an IDLE LINE interrupt. That interrupt can be used to catch the edge case where there are fewer DMA transfers than the number required for a COMPLETE or HALF COMPLETE DMA interrupt. \$\endgroup\$
    – pgvoorhees
    Commented May 14, 2020 at 15:13
  • 3
    \$\begingroup\$ Packet-based protocols where you can receive the first few bytes using interrupts until you get a length that you can program into the DMA controller to get the rest. But saving CPU burden is only really useful if you need to use it for something else. \$\endgroup\$
    – Finbarr
    Commented May 14, 2020 at 15:14
  • \$\begingroup\$ @Finbarr Great "but" :) Complicating implementation just for the sake of it is usually the primary source of bugs and headache for debugging. \$\endgroup\$
    – Maple
    Commented May 14, 2020 at 16:35
  • \$\begingroup\$ @Finbarr, thanks for the comment. What you do mean by 'something else'? \$\endgroup\$
    – CNA
    Commented May 15, 2020 at 8:47
  • \$\begingroup\$ You tell me, you're the one that mentioned freeing CPU burden. It depends what else your system does. \$\endgroup\$
    – Finbarr
    Commented May 15, 2020 at 9:19

2 Answers 2


You did not specify the hardware, and you used "CPU" throughout the question. However since you also mentioned half/complete interrupts I am going to assume that you are actually talking about MCU.

using DMA with UART needs constant byte count

Not really. The combination of cyclic DMA mode + half/complete/idle interrupts allows you to process frames of any length. For the hardware that does not support idle interrupts there are alternative implementations, like using idle timer with Rx line wired to timer reset input.

This tutorial has great summary of various DMA methods. You may also find AN3109 by ST useful.

In which applications is UART + DMA concept more suitable than normal UART interrupt method?

Pretty much any packet-based communication (including Modbus) can benefit from DMA. The exceptions are:

  • If your communication consists of just a few bytes sent with long idle periods in-between then setting up and processing DMA will unnecessarily complicate the software;
  • In time-critical applications if reception of certain bytes (e.g. EOF) requires immediate reaction then using DMA may introduce unacceptable latency;
  • Finally, if your application has nothing else to do when there is no data to process AND the MCU is sufficiently fast to process continuous stream of bytes at maximum bandwidth one by one then again, using DMI will introduce unnecessary complexity.

Basically, when making decision whether or not use DMA, consider this - data processing will take exactly the same amount of cycles anyway. Using UART interrupts will add IRQ entry/exit overhead to that per each byte. Using DMA will add same overhead but only to half/complete/idle buffer interrupts. Therefore, any buffer longer than two bytes will theoretically save some cycles for you (in reality you'd need somewhat longer buffer to see the benefits).

  • \$\begingroup\$ Thanks for the answer. I am using pic controllers. Can you be more specific about packet-based communications in which the UART+DMA concept is being used? \$\endgroup\$
    – CNA
    Commented May 15, 2020 at 8:24
  • \$\begingroup\$ I don't know how more specific I can be. I listed exceptions when using DMA is not beneficial and I explained how buffer size affects communication overload. I also specifically mentioned MODBUS you seem to be using. \$\endgroup\$
    – Maple
    Commented May 15, 2020 at 14:27
  • \$\begingroup\$ The tutorial link is broken. It points back to this question. \$\endgroup\$
    – Harvey
    Commented Sep 2, 2022 at 14:11
  • \$\begingroup\$ @Harvey I fixed the link, thank you. \$\endgroup\$
    – Maple
    Commented Sep 15, 2022 at 15:33

If there are termination characters you can search for those since some MCUs have a character match interrupt.

Many protocols also have a byte that indicates the length of the message that is located at a predictable point relative to the beginning of the message. You can use that to know when a full message is completed and how many bytes to parse for that message before you run into the next message in the buffer.

Otherwise, I suppose you could have a timer that ocasionally scans the last n unchecked bytes received for something that signifies a complete message. Or start processing when no bytes are received for a certain length of time which could also imply the end of a transmission.

But if you really do have to inspect every single byte as it comes in then there is no point to a DMA.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.