On 2009-02-14, John Nagle <na...@animats.com> wrote: > Roy Smith wrote: >> In article <49970ce7$0$1665$742ec...@news.sonic.net>, >> John Nagle <na...@animats.com> wrote: >> >>> At the hardware level, there's a clock rate, a counter, and a >>> divisor, so arbitrary baud rates can be set. >> >> Is that really true of modern hardware? The last time I >> looked at serial port hardware, UARTs took a base clock rate >> and divided it sequentially with flip-flops to get all the >> possible rates (they usually had some ugly logic to generate >> 110). You were limited to the specific rates the hardware >> gave you. Is that no longer the case? > > It is, but the traditional serial clock rate is 115200 Hz, so > you can use any subdivision of that as a baud rate. The > divisor for 45.45 baud is something like 2535.
On Linux IFF you're using a 16x50 UART, you can set arbitrary divisors using the setserial utility. From Python, you can just invoke setserial (via os.system() or subprocess). It should be pretty trivial: execute setserial with the parameters "/dev/whatever spd_cust divisor 2535". Then use the normal calls to set the baud rate to 38400, and you should get 45.444 baud. [Disclaimer: I haven't tested the above, and I may be remembering it incorrectly.] If that's too easy and you want to get your hands dirty, you can look up the ioctl and parameter structure used by setserial and invoke the ioctl directly from Python. Neither method is portable to any other OS (or any other serial driver, AFAIK). > Some exotic serial port devices use a 16MHz clock; I've used > those for supporting SICK LMS laser rangerfinders at 500,000 > baud. :) Been there, done that -- along with that goofy checksum they call a CRC. They actually only do the CRC on one bit out of every byte, and then they just xor in the rest of the byte. It's very strange, rather slow, and not very good at detecting errors. A real, table-driven CRC would be both a lot faster and a lot more robust. My guess is that it was _supposed_ to be a CRC routine, but somebody botched it. They used the same botched routine on the host end when they did testing, so nobody noticed it was broken. By the time anybody realized that the CRC routine was broken, masked ROMs were in the field and it was too late to fix it -- so they just documented the "custom" algorithm in the manual and called it good. -- Grant -- http://mail.python.org/mailman/listinfo/python-list