SlowSoftSerial library for slow baud rates

On the Teensy 3.x, standard serial baud rates below 1200 baud are not supported by the hardware UARTs, as documented here. Existing software serial libraries have other limitations, as documented here. So, I have created a new software serial library called SlowSoftSerial. It is available now at https://github.com/MustBeArt/SlowSoftSerial.

It can handle simultaneous receive and transmit, on any two digital pins of a Teensy 3.x, at any arbitrary baud rate from 1 baud up to, typically, 9600 baud or higher, at any word size (5-8 bits) and parity setting. It has minimal impact on interrupt latency (comparable to AltSoftSerial).

It uses two of the four Periodic Interrupt Timers, via the IntervalTimer library. It should be usable anywhere the IntervalTimer library works and pin change interrupts are available, but has only been tested on Teensy 3.5 so far. Currently only one SlowSoftSerial port at a time can be active, though you can have multiple ports defined and switch between them cleanly.

Like other software serial implementations, SlowSoftSerial can be sensitive to interrupt usage by other libraries. At any given baud rate, it is more sensitive than AltSoftSerial, but this is less of a problem at low baud rates.

In one typical use case, a SlowSoftSerial port can be defined to use the same transmit and receive pins as one of the hardware UARTs. If the requested baud rate is 1200 or higher, the application would use the hardware serial port. If the requested baud rate is lower than 1200, the application would use the SlowSoftSerial port instead. The switch can be completely transparent to the user and to the hardware design.

This is a newly written library, so it has not yet been battle-proven. Bug reports, comments, questions, and suggestions are welcome!

-Paul Williamson, paul@mustbeart.com
 
Paul - very nice bit of code. This will be VERY useful to those who do Model 28 or 30 TTY interfaces. The 110 baud they ran at was not easy to get without some tricky bit-banging. �� ��
 
For the fun of it, I was curious about how slow I can get the FlexIO Serial code I have to run on T4...

Not near slow enough...

Unless I am missing something I believe the slowest clock I can bring to FLEXIO is 396mhz.
The biggest dividers I can use are 8*8 or 64.
So the actual clock to FlexIO would be: 6187500
Now clock register counter mode for this only uses the lower Byte for counter so max 255 (counts+1) or 256 and multiplyed by 2:
so I think the slowest I can go would be 6187500/(512) = 12084..
 
@Paul Williamson
I noticed the "#define SSS_SERIAL_STOP_BIT_1_5 (0x20ul)" declaration in the header file, but it's not used anywhere.
Is this still under test/development?
I'm soon starting the restoration of a Lorenz Lo15 (German Lorenz build Teletype M15 on license) I'm not sure I need it. I think it could be 50 Baud 5bit no parity.
Will be fun finding out when I get to that stage
 
I didn't have any plans to implement the 1.5 stop bit mode, but I can look into doing so. It won't be a perfectly clean drop-in for the existing implementation, but it shouldn't be too hard to find a way to fit it in.

If you only need one direction at a time, you can probably get by with the existing SlowSoftSerial feature set. Just send 2 stop bits (thus incurring a small extra delay between characters) or receive with 1 stop bit (allowing the "extra" 0.5 stop bit to be discarded harmlessly as inter-character delay). You can switch between the two modes as illustrated in one of the examples. But you can't do both simultaneously, so this isn't a complete workaround.

Watch the SlowSoftSerial repo for news. Thanks for your interest!

-Paul
 
@henkk

SlowSoftSerial now supports modes with 1.5 stop bits. I hope you'll find it useful!

SlowSoftSerial also now comes with an automated test framework. Two Teensy boards are connected via SlowSoftSerial. One board acts as controller and the other board responds. The controller puts the target through its paces. By default, that's a comprehensive test of every serial port configuration supported by SlowSoftSerial (there are 60 such configurations) at every standard baud rate from 45.45 baud to 19200 baud. Offline analysis of a logic analyzer capture of the conversation is able to detect any deviation from normal behavior. All that testing didn't reveal any new bugs in SlowSoftSerial. This new level of testing gives me the confidence to promote SlowSoftSerial from "late Alpha" to "Beta" maturity.

Originally I planned to test the Teensy running SlowSoftSerial against another controller running a hardware UART, for independence, but in the end I couldn't find any available hardware configuration that was flexible enough to test all of SlowSoftSerial's configurations and baud rates. The repo contains test controller code for Raspberry Pi Pico and its hardware UART, which can handle the baud rates but can't handle all the configurations. Plus I ran into multiple deficiencies in the UART API in the provided SDK, the latest of which (548) prevents reliable configuration changes. That's a big problem for this test framework use case, even if most Pico users would never notice it.

-Paul
 
Hi Paul,
appologies for the late reply, very usefull and . . . . . awesome.
Finding a (normal priced) HW UART for any speed below 300bps is getting more and more difficult, let alone those odd speeds they used at the 1st half of the last century

For the PICO, I might, when time permits, experiment with the PIO blocks to create a UART, the TX part is relative easy, the RX is more difficult I guess.

Henk
 
The Raspberry Pi folks do provide example PIO implementations for transmit and receive async serial. They are rather minimal implementations and handle only a fixed configuration, but would be a good starting point for a more full-featured implementation. I think you'd end up with software that switches the PIO program on the fly to change configurations.

I'm sure there would be users in the Pico community who would welcome a good UART solution for the PIO hardware. I've considered working on that myself, but it's pretty far down the list right now. More likely (but no promises) would be a Pico SDK port of SlowSoftSerial. That should be "easy", and good enough for some purposes.

-Paul
 
Back
Top