I basically have running what I described in my feature set.  I use an AVR MCU to suck in the ASCII at 9600 from the USB to Serial bridge chip, and then interrupt drive a process to bit bang out the 5 unit Baudo code on a pin port.  That all works great.   My problem is that there's something whacky that I don't understand about the USB drivers (W10 and Linux) for USB to serial bridge chips like the CP210x and CH340x.  In some cases the system will respect XonXoff flow control but not RTS/CTS and in others it is RTS/CTS but not XonXoff and in a third case it will respect neither.  I can see by using RealTerm that XonXoff are being sent and received to/from the AVR MCU, and that Realterm responds correctly to CTS from the MCU.  And yet, when using some W10/Linux application to send data to the USB port the computer will not respect flow control commands from the AVR MCU, causing FIFO overflows on the MCU.  Since I can't figure out what's wrong with the flow control mechanisms in the drivers or OS, my solution has been to move to the AVR128DB32, which provides for 16 Kbytes of RAM.  With 16Kbytes of RAM in the MCU, I can hold a lot of TTY pages of print in RAM before things go bad.

Paul, ad7i