DMA on Cortex M4 for continuous UART transfer

Flow control requires the cooperation of both ends. RTS means Request To Send and CTS is Clear To Send. Typically the RTS of one side is connected to the CTS of the other. So when a device has data to send to the other device, it waits until CTS is asserted before it begins transmitting. The device that is receiving would assert RTS when it's not busy with other tasks and when there is buffer space available (if it's a buffered implementation, which is common).

Note that in the typical case of a full duplex link, both sides can transmit at the same time, so each end would have both CTS and RTS lines.

So, in your particular case, Device 2 does not support hardware flow control, so you won't ever get flow control signals from that device. This means that for Device 1 to communicate with Device 2, it should either have hardware flow control turned off (check your UART data sheet) or should have the input signals (RTS in this case) hardwired to always allow sending.

Alternatively, if Device 2 is part of a microprocessor, you may be able to do your own hardware flow control using spare GPIO lines to serve the function of CTS and RTS.

CTS bar (commonly indicated as \$\overline{\text{CTS}}\$ or #CTS) would simply be an inverted version of CTS. Adding the bar or the # are two common ways of indicating the inverse of the usual logic sense, hence a \$\text{RESET}\$ line, which is often active low, is often shown as \$\overline{\text{RESET}}\$.

The device driver itself works by ultimately by just writing to the UART FIFO and control registers.

The main reason why you typically would want to use the driver rather than writing to the UART directly is because the driver gives you a layer of abstraction. It lets you treat that UART like other UARTs, and even sometimes like any other file. You do not need to know which bit is the Data Ready Bit and what the divisor registers are for the UART you happened to be using since the driver makes all UARTs look pretty much the same. Additionally, the driver typically gives you a nice big managed buffer on top of the FIFOs and handles all the interrupts, which requires writing some specialized code under Linux.

That said, there are times when writing directly to the UART can give you control that is not available though the driver. Here is a project where I skip the Linux device driver on a Raspberry PI and go directly to the UART to be able to generate signals for a WS2812B...

http://wp.josh.com/2014/09/03/inside-neouart-tricking-a-serial-port-into-being-a-signal-generator/

This would not be possible to do via the driver because it depends on some quirks of the specific UART, along with some state transitions that there is no way to reliably get the driver to do in the right order.

In cases where you do decide to write directly to the UART, it is probably a good idea to disable the driver to avoid conflicts. For example, if you are trying to read bytes out of the FIFO via your userspace program, it is likely that the driver will also be reading bytes and will likely win because it gets gets triggered off of interrupts. Similarly, you might change some register directly while the driver assumes that register will stay set to whatever it initialized it to (or vice versa).