3 ms·

This has to be supported by the UART hardware in order for it to work reliably. The idea is in essence that the receiver measures the length of start bit, this

by dfox 9y ago

This has to be supported by the UART hardware in order for it to work reliably. The idea is in essence that the receiver measures the length of start bit, this requires the expected character to have first transmitted bit (LSB usually) set to 1. For example this is done by almost all Hayes compatible modems and is the reason why commands start with 'AT' (or in fact, the 'A' itself). IIRC there is also somewhat reliable and simple (ie. not involving sampling the whole waveform and analysing it after the fact) for doing autodetection for random unknown data, but I cannot find the reference where I've seen it described at the moment (it was in some TI appnote or something similar)

dfox 9y ago
I didn't find the appnote I mentioned, but found another that describes exactly the case of detecting baud rate from one or two CR characters (SLAA215, ie. http://www.ti.com/lit/an/slaa215/slaa215.pdf http://www.ti.com/lit/an/slaa215/slaa215.pdf) As it happens, when you set UART to 115200 then it will receive the CR character transmitted at any baud rate <115200 (with the obvious caveat that you may get additional garbage characters after that) and for standard baud rates between 9600 and 115k2 you will get unique received bit pattern. If you get zero or framing error then the baudrate is 9k6 or lower, so you change speed to 9k6 and retry the same idea (and if you care about less than 1200 you can do this for the third time, but that starts to be somewhat pointless as the really slow tty baud rates will not generate unique and repeatable bit patterns because they are too close together and are not 115k2 divided by some integer). [Edit: there is not that much special about using CR for that. You want character with LSB set and the lower hamming weight the better, CR is convinient, 0x01 would work better. Obviously the table garbage=>speed depends on what character you choose, but with some clever masking it can probably be made universal at least for every character with LSB set] It seems that I misremembered what I read about the more general auto detection. It in fact is not more general, but derived from LIN protocol and involves intentionally sending more complex synchronization pattern, consisting of break, some idle time and then 0x55. On the other the MSP430 hardware is capable of locking onto essentially any received baud rate (not only the standard ones) with sufficient precision by doing this.

by dfox 9y ago

dfox 9y ago

I didn't find the appnote I mentioned, but found another that describes exactly the case of detecting baud rate from one or two CR characters (SLAA215, ie. http://www.ti.com/lit/an/slaa215/slaa215.pdf http://www.ti.com/lit/an/slaa215/slaa215.pdf) As it happens, when you set UART to 115200 then it will receive the CR character transmitted at any baud rate <115200 (with the obvious caveat that you may get additional garbage characters after that) and for standard baud rates between 9600 and 115k2 you will get unique received bit pattern. If you get zero or framing error then the baudrate is 9k6 or lower, so you change speed to 9k6 and retry the same idea (and if you care about less than 1200 you can do this for the third time, but that starts to be somewhat pointless as the really slow tty baud rates will not generate unique and repeatable bit patterns because they are too close together and are not 115k2 divided by some integer). [Edit: there is not that much special about using CR for that. You want character with LSB set and the lower hamming weight the better, CR is convinient, 0x01 would work better. Obviously the table garbage=>speed depends on what character you choose, but with some clever masking it can probably be made universal at least for every character with LSB set] It seems that I misremembered what I read about the more general auto detection. It in fact is not more general, but derived from LIN protocol and involves intentionally sending more complex synchronization pattern, consisting of break, some idle time and then 0x55. On the other the MSP430 hardware is capable of locking onto essentially any received baud rate (not only the standard ones) with sufficient precision by doing this.