GM ALDL interface

[Ludis Langens]

Terry Kelley <terryk at foothill.net> wrote:
> I samples at 2-3X the 160 baud rate and dumped the serial stream it into a
>large buffer (9x max bytes +1). 
>[...]
>Considering how slow 160 baud is, there is plenty of time to do all of
>this, convert, display the results and start again.

Your's is certainly a valid approach.  However, what happens when your CPU
"goes out to lunch" (perhaps servicing a floppy disk or network device) for
more than 5 mS?

steve ravet <steve at imes.com> wrote:
>The maximum byte length would be 5.75 msec.  At 8
>data bits, one stop bit, you would need a baud rate of 1739.

I compute something different:  The length of the start bit and 8 data bits
is 288/65517.1875 seconds (~4.4 mS).  So the baud rate for 8-N-1 should be
9 * 65517.1875 / 288 = 2047 baud.  (This assumes the timing used by my ECM.)

>...and a "zero" bit would
>result in a bit [byte] with at least some ones in it (non zero).

The byte would be all ones.  The "zero" pulse is (exactly) 1/12 the "one"
pulse.  This might actually cause problems with some UARTs because the pulse
is slightly too short to be a start bit.  At 8-N-1, the start bit should be
1/9 of the long pulse.  Going to 8-E-1 would change the expected ratio to 1/10.

>The meaning of each byte in the frame is unknown, and probably differs per ECM.

A frame format has been posted here before.  It turned out to be a 95% match
for my case.  I've figured out the format for mine and another ECM.  One is a
subset of the other, except for differences in some of the flag bits.

>Thanks for the idea,  Ludis!  I plan on trying that out.

I'd like to hear how it works out.

                   unsigned long BinToBCD(unsigned long i) {unsigned long t;
Ludis Langens         return i ? (t = BinToBCD(i >> 1), (t << 1) + (i & 1) + 
ludis at netcom.com                 (t + 858993459 >> 2 & 572662306) * 3) : 0;}