You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Sometimes it's useful to transmit continuously, without any gaps between characters, effectively turning asynchronous serial into a synchronous mode. There are good reasons to do this on radioteletype, for instance, as explained by Brian Beezley, K6STI. I suspect the practice goes back to mechanical teleprinters that worked better if not called upon to stop and start between characters. It certainly belongs to the era of two- and three-digit baud rates, so it's natural for SlowSoftSerial to support it.
In order to transmit continuously without fail, we have to insert extra fill characters whenever the supply of actual outgoing characters runs dry. To do this reliably without inserting unnecessary fill characters, it generally has to happen at the serializer -- in SlowSoftSerial in our case.
For a stateless code like ASCII, this is simple. We simply pick a character that both ends agree will never mean anything, and insert that character when we don't have anything meaningful to send. In ASCII, we can use NUL (0x00), SYNC (0x16), or historically DEL (0x7F) for this purpose. In a case-switching code like ITA2 (Baudot), we probably want to use the Shift to Letters code (0x1F), but we have to be careful to use Shift to Figures (0x1B) instead when the data stream is in figures case, to preserve meaning. Thus, we need a flexible API for this.
enableLtrsFigsFill() sets the fill character immediately to default_fill_character, and begins monitoring the transmit data stream for instances of either default_fill_character or alternate_fill_character. When either is transmitted, that sets the current fill character to match the last one sent.
The functions take effect immediately and are not synchronized with the transmit buffer. If one of the enable functions is called while the transmitter is idle, the transmitter immediately begins to send fill characters.
Behavior when transmit handshaking is also enabled is UNDEFINED.
If the receiving side is expected to use the "unshift on space" (USOS) heuristic, then the higher layer transmit software has to put a FIGS character immediately before each sequence of digits, but it is still normal practice to send a LTRS character before returning to letters, rather than relying on the receiver's USOS. In this case, enableLtrsFigsFill() does the right thing.
The text was updated successfully, but these errors were encountered:
Sometimes it's useful to transmit continuously, without any gaps between characters, effectively turning asynchronous serial into a synchronous mode. There are good reasons to do this on radioteletype, for instance, as explained by Brian Beezley, K6STI. I suspect the practice goes back to mechanical teleprinters that worked better if not called upon to stop and start between characters. It certainly belongs to the era of two- and three-digit baud rates, so it's natural for SlowSoftSerial to support it.
In order to transmit continuously without fail, we have to insert extra fill characters whenever the supply of actual outgoing characters runs dry. To do this reliably without inserting unnecessary fill characters, it generally has to happen at the serializer -- in SlowSoftSerial in our case.
For a stateless code like ASCII, this is simple. We simply pick a character that both ends agree will never mean anything, and insert that character when we don't have anything meaningful to send. In ASCII, we can use NUL (0x00), SYNC (0x16), or historically DEL (0x7F) for this purpose. In a case-switching code like ITA2 (Baudot), we probably want to use the Shift to Letters code (0x1F), but we have to be careful to use Shift to Figures (0x1B) instead when the data stream is in figures case, to preserve meaning. Thus, we need a flexible API for this.
enableLtrsFigsFill() sets the fill character immediately to default_fill_character, and begins monitoring the transmit data stream for instances of either default_fill_character or alternate_fill_character. When either is transmitted, that sets the current fill character to match the last one sent.
The functions take effect immediately and are not synchronized with the transmit buffer. If one of the enable functions is called while the transmitter is idle, the transmitter immediately begins to send fill characters.
Behavior when transmit handshaking is also enabled is UNDEFINED.
If the receiving side is expected to use the "unshift on space" (USOS) heuristic, then the higher layer transmit software has to put a FIGS character immediately before each sequence of digits, but it is still normal practice to send a LTRS character before returning to letters, rather than relying on the receiver's USOS. In this case, enableLtrsFigsFill() does the right thing.
The text was updated successfully, but these errors were encountered: