What a heresy, on 8052.com... ;-)


Oh, sorry for the "tutorial" then...

The NXP user manuals describe two hardware methods of auto baud detecting.



a) is what I remember from the manuals etc.

But, you know what, I took out a modem (a Rockwell-chipset based one), and found out an interesting thing: it has two modes, after-A and after-CR.

In the after-CR mode, when one would expect it is in autobaud mode and waiting for 'a', it was able to autobaud on ANY reasonable character (' '-'z') and echo it properly (but of course, it performed nothing until I typed "at").

In the after-A mode, surprisingly it was able to detect SOME change in baudrate (say, from 115200 to 9600, but from 115200 to 4800 it echoed some garbage) and echoed properly, but again it did not do anything, so effectively it fell back to the after-CR mode after the first such out-of-baudrate character.

I can't quite see how this could be accomplished using an autobaud hardware you have. I could do some of it in software, but I expect that the modem chipsed did have a dedicated hardware helping out in this regard: these last-generation hardware modem chipsets were pretty sophisticated, with firmware occupying hundreds of kilobytes of ROM etc.

You might consider at least autobauding after a timeout (if it does not interfere with normal character reception), if you expect sudden changes in baudrate, as otherwise after a baudrate change happening amidst a command the interface might get stuck. A good idea might be also to autobaud after unexpected characters (say, outside ' '-'z' and CR/LF (and perhaps XON/XOFF if you plan software handshake)), after frame errors (also indicating possible baudrate change); and maybe employ an external edge-triggered interrupt (for detecting upwards baudrate change, when the "normal" UART stops receiving completely, rejecting the short bits as noise).

€0.02 ;-)

JW