What's good or bad for the serial port (someone pointed out that it's more than just a UART)isn't germaine to the topic, is it? I don't think the baud rate, or the data format will be good or bad for the serial port(s).

It's certainly reasonable to discuss what's a clever or effective use of that resource, though.

An adjunct to the point I made in another thread, namely that the use of certain crystals in order to ensure the availability of the widest range of asynchronous baud rates was, in fact that making that choice was quite limiting.

The simple reason people don't use Mode-0 very often today is that it's been used little in the past. That was because it required too much of the CPU bandwidth to service the serial channel, but that's also no longer necessarily the case. Another reason, of course, is that they already used the UART for ASYNC communication for debugging. That's also not the only reason, but it's a contributing factor, as evidenced, even in this thread.

What's REALLY crippling, is that, in MCU's with two serial channels, the choice of one frequency has effect on the rates at which the either serial channel can operate, IF THAT FREQUENCY WAS CHOSEN FOR THE ASYNC BAUD RATES. Now, technically, I'm a cripple myself, being seen by some as an arachnid, due to the number of legs I have, so I know it's limiting, but not fatal, to be crippled. You CAN function, and quite effectively, when you're hobbled, in a sense, but it's much easier if you're not. Ruling out the use of Mode-0 is like ruling out the use of crystal frequencies other than 11.0592 MHz or its multiples. There are some times when it simply gets in the way. Yes, you can put in a 74HC595 and a 74HC597, with some other logic, drive it with whatever clock you like, and have access to the MODE-0 function. However, you can just as easily provide an external UART and use the Mode-0 capability already built into the MCU. It's just another choice.

RE