Answer
Ezurio strongly recommends that developers utilize RTS/CTS for flow control in their applications.
When referring to CTS/RTS
- Module UART CTS is an input.
- Module UART RTS is an output.
- Asserted = 0 V (low).
- Deasserted = 3.3 V (high).
Module UART CTS is an input and is connected to the host’s RTS, which consequently is an output. The host can tell the module it is available to accept data over the UART by controlling its RTS output, which signals to the module via the module CTS input. The module will not send data unless CTS is asserted. In short, an asserted RTS output tells the peer that it is safe for the peer to send data.
The host can stop the module sending it data by taking its RTS high, which in turn takes the module’s CTS high. Likewise, the module can stop the host sending data by taking its RTS high, which takes the host’s CTS high.
Disabling Flow Control
If the application’s on-air throughput is lower than the throughput of the UART (baud rate, parity, and stop bits), or the developer accepts the risk of potential data loss or module reset, then the CTS input line can be pulled to 0 V/GND and the RTS output line allowed to float (see Figure 2).
Before Foregoing the Correct Use of CTS/RTS, Please Consider the Following
Issue #1: Module not responding to commands
Module UART CTS is an input and it’s not good practice to leave it floating. If it inadvertently sits at 3.3 V due to the circuit design, the module will assume the host is not ready to receive data. The host sends a command such as at but gets no response back, as the module senses it can’t send because the host is not ready to receive data. This is a common problem for developers who skip using a dev kit and wire directly to a module using just UART TX, RX, and GND.
Solutions
- Make proper use of flow control (highly recommended), see Figure 1.
- Tie module UART CTS to 0 V so that the module will always assume the host is ready to receive data (not recommended), see Figure 2.
Issue #2: Module overflow causing data loss
Unlike a wired connection, a radio connection is more readily subject to degradation caused by increasing range and interference. At some point the over-the-air throughput may fall below the UART throughput (note: maximum throughput when there is no parity and one stop bit is configured is ~80% of the baud rate), at which point the module will signal “stop sending data so I can catch up” by taking its RTS (output) high. The host sees its CTS (input) follow suit and stops sending data.
If CTS/RTS is not used correctly and module UART CTS is tied to GND/0 V, the module is overwhelmed with data from the host and asserts RTS, but since module UART RTS does not go anywhere, the host keeps sending, oblivious to the module’s plight. At some point an overflow may occur, which may result in data loss or possibly even a module crash.
Solutions
- Use proper CTS/RTS flow control (highly recommended), see Figure 1.
- Accept that you might lose data.
Issue #3: But what about the host?
If the host is also expecting proper use of CTS/RTS, it too might have issues when sending data to the module, as it may not be told that the module is ready to accept data. You might also have to take the host CTS to 0 V before it will communicate. However, by taking host CTS to 0 V—or tying host CTS to RTS—you introduce the same potential issues described above.
Solutions
- Tie the host CTS to 0 V.
- Make proper use of CTS/RTS flow control (highly recommended), see Figure 1.
Additional UART Lines
The additional UART lines of DSR and DTR are optional, and RI and DCD are not necessary. Developers can create equivalent functionality using any spare GPIO that is available, along with smartBASIC / AT commands to provide behavior as necessary. Please refer to the relevant module documentation for further information.