I spend last month a lot of time getting UART (for MIDI) to work with an STM (STM32F103C8T6) using interrupts, without very much success.
However, this evening using DMA it worked quite fast.
Since as far as I read DMA is faster and relieves the CPU, why not always use DMA in favor of interrupts? Especially since on the STM32 there seem to be quite some problems.
I'm using STM32CubeMx/HAL.
While DMA relieves the CPU and thus may reduce latency of other interrupt-driven applications running on the same core, there are costs associated with it:
There is only a limited amount of DMA channels and there are limitations on how those channels can interact with the different peripherals. Another peripheral on the same channel may be more suited for DMA use.
For example, if you have a bulk I2C transfer every 5ms, this seems like a better candidate for DMA than an occasional debug command arriving on UART2.
Setting up and maintaining DMA is a cost by itself. (Normally, setting up DMA is considered more complex than setting up normal per-character interrupt-driven transfer, due to memory management, more peripherals involved, DMA using interrupts itself and the possibility that you need to parse the first few characters outside of DMA anyways, see below.)
DMA may use additional power, since it is yet-another-domain of the core which needs to be clocked. On the other hand, you can suspend the CPU while the DMA transfer is in progress, if the core supports that.
DMA requires memory buffers to work with (unless you are doing peripheral-to-peripherial DMA), so there is some memory cost associated with it.
(The memory cost may also be there when using per-character interrupts, but it may also me much smaller or vanish at all if the messages are interpreted right away inside the interrupt.)
DMA produces a latency because the CPU only gets notified when the transfer is complete/half complete (see the other answers).
Except when streaming data into/from a ring buffer, you need to know in advance how much data you will be receiving/sending.
This may mean that it’s needed to process the first characters of a message using per-character interrupts: for example, when interfacing with an XBee, you’d first read packet type and size and then trigger a DMA transfer into an allocated buffer.
For other protocols, this may not be possible at all, if they only use end-of-message delimiters: for example, text-based protocols which use '\n' as delimiter. (Unless the DMA peripheral supports matching on a character.)
As you can see, there are a lot of trade-offs to consider here. Some are related to hardware limitations (number of channels, conflicts with other peripherals, matching on characters), some are based on the protocol used (delimiters, known length, memory buffers).
To add some anecdotal evidence, I have faced all of these trade-offs in a hobby project which used many different peripherals with very different protocols. There were some trade-offs to make, mostly based on the question "how much data am I transferring and how often am I going to do that?". This essentially gives you a rough estimate on the impact of simple interrupt-driven transfer on the CPU. I thus gave priority to the aforementioned I2C transfer every 5ms over the UART transfer every few seconds which used the same DMA channel. Another UART transfer happening more often and with more data on the other hand got priority over another I2C transfer which happens more rarely. It’s all trade-offs.
Of course, using DMA also has advantages, but that’s not what you asked for.
Using DMA usually means that you're no longer taking an interrupt on every character, but rather only after a "buffer full" of characters has been received (or transmitted). This increases the latency of processing those characters — the first character is not processed until after the last character in the buffer has been received.
This latency can be a bad thing, especially in a latency-sensitive application such as MIDI, where a few ms here and there can add up to serious playability issues for live performances.
DMA isn't a substitute for interrupts -- they're typically used together! If you're using DMA to send data over a UART, for instance, you still need an interrupt to tell you when the send is complete.
Using DMA introduces some interesting questions and challenges beyond all the other considerations of UART peripheral use. I'll give you a few examples: Assume that your uC is sitting on a RS485 (or whatever) bus with other devices. There are many messages on the bus, some are intended for your uC, some aren't. Additionally assume that these bus-neighbors all speak a different data protocol, which implies the message lengths are different.
Some questions that only come up when using DMA are:
Anyway, just food for thought.
On the receive side (as I recall) DMA terminates either on a character match or at the terminal count. Some protocols and many interactive applications don't fit easily into this model and you really need to handle things character by character. The DMA techniques can also be brittle if the communications link is unreliable, loosing a single character in the stream can easily mess up your DMA state machine.
I have used the STM32CubeMx/HAL on a couple of projects now and have found that the UART handling software that it generates has definite shortcomings on the receive side.
On transmit you will normally want to send a block of data or line of text. In this case you know up front how long the data transfer is and so using the DMA is an obvious solution. You get an interrupt once the transfer is complete and can use the UART TX complete callback function to indicate to your main code that the transmission is complete and you can send another block of data.
When it comes to data reception the functions provided by ST all assume that you know how many characters the sending device will be giving you before it starts to send. Normally this is not known. The interrupt functionality places the data received into a buffer and only indicates that there is data available when the pre-defined number of characters has been received. If you try to use the DMA or interrupt functionality to receive data by setting up sequential single character transfers then the setup time for each of these will mean that you will lose characters at anything other than the slowest data rates (the baud rate that you will start to lose data will depend upon your processor clock speed) and will load the processor excessively ,leaving no instruction cycles for any other processing
To get round this I have written my own interrupt handler function that stores the data in a small local circular buffer and sets a count that is read by the main code (an RTOS counting semaphore) to indicate that there is received data ready. The main code can then collect the data from this buffer at its leisure, it does not matter if there is some delay in collecting the data providing that the local buffer does not overflow before the data is collected.
