enum: ashet.io.serial.ControlFlow

Items

none = 0

No explicit control flow is used.

rtr_cts = 1

This mode is usually called the *hardware control flow* and uses two signals that are connected cross-over between both communication partners.

- RTR is an active-low signal called *Ready To Receive* which signals the opposite part that we can actually receive data right now. If the signal is high, the opposite part may not send data. - CTS is an active-low signal called *Clear To Send* which receives the RTR signal from the opposite part. When this signal is low, our transmitter is allowed to send data. If the signal is high, the transmitter has to stop sending and a timeout may occur.

Lore:

This is usually called RTS/CTS control flow, but in that configuration the RTS (request to send) signal is repurposed into a RTR (ready to receive) signal which tells the communication partner that you are able to receive data. In Ashet OS, the technically correct term is used as we don't use the legacy half-duplex control flow where a request to send is performed.

xon_xoff = 2

This mode is usually called *software control flow* and uses two special bytes that can inhibit or allow transmitting bytes.

The two special words are called XON (Transmitter On) and XOFF (Transmitter Off).

When a receiver receives the XOFF word, it turns off the sender after the current byte has been processed. As soon as the XON word is received, the sender is allowed to continue sending data.

XON and XOFF can be both sent by software or hardware.

Note:

Using this control flow prevents sending *raw binary* data, as XON and XOFF are regular data words that can be contained in the sent data.

Thus, this control flow mode should only be used with textual data which does not conflict with the chosen control characters.