Can Python serial support run at 45.45 baud?

[Grant Edwards]

On 2009-02-14, John Nagle <nagle at animats.com> wrote:
> Roy Smith wrote:
>> In article <49970ce7$0$1665$742ec2ed at news.sonic.net>,
>>  John Nagle <nagle at 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