GM ALDL interface

[Ludis Langens]

steve ravet <steve at imes.com> wrote:
>There are at
>least 2 flavors of ALDL, one is aobut 160 baud and the other is 8192
>baud.  The second is a TTL level rs-232 signal, the first one is strange
>and will not connect to a serial port.

Not necessarily so, read on.

>A neat project would be to use a
>PIC microcontroller to read the 160 baud stream, convert the data, and
>send it out over a regular serial port.

I've breadboarded a fully optoisolated ALDL interface for a Mac.  The serial
data is routed to the RxD input of a serial port.  The 8192 baud mode can
(of course) be received using the standard serial driver software.  For the
160 baud mode, I've written a device driver to receive the 160 baud data.
The Zilog SCC used in Macs can do magic!  Anyway, the technique I used has
given me an idea of how receive the 160 baud ALDL data using a standard
async-only UART.  This technique could be used with the ALDL interface
schematic found in this list's archives.

First some background info:  Bits in the 160 baud stream are encoded as
different length pulses.  A "zero" is sent as a low pulse with a duration
of around 24/65517.1875 seconds (~366 uS).  A "one" is sent as a pulse of
around 288/65517.1875 seconds (~4.4 mS).  The interval from the start of
one pulse to the start of the next pulse is 412/65517.1875 seconds (~6.3 mS).
In other words, the actual data rate is really around 159.02 baud.  (This
timing data applies to _some_ of the 160 baud ECMs, it might not apply to
_all_ of them.)

My basic idea is to set the UART to a baud rate that receives a full byte
(or more) per every ALDL bit.  The start of each ALDL pulse acts as an async
start bit.  The low interval of the pulse is received as a variable number
of async zero bits.  The baud rate could be set such that:

 a) A long ("one") pulse is received as a start bit and 8 zero bits - i.e.,
    a NUL byte.  A short pulse should then be received as just a (slightly
    short) start bit - i.e., a 0xff.

 b) A short ("zero") pulse is received as a NUL byte.  A long pulse would
    then be detected as an async BREAK.

 c) Some other baud rate in this same range.

Some real world testing is needed to choose an actual baud rate.  Hardware
and software factors need to be considered.  With a good baud rate choice,
it should be possible to use a standard serial driver - possibly even with
DMA!  Application software would be responsible for converting the 160
bytes/second into the 160 bits/second data stream - and then further into
ALDL data packets.

In summary, no PIC microcontroller in needed.  All you need is a TTL to
RS-232C level shifter and some software.  Further, that software shouldn't
need to access anything at the hardware level!  (I'm not familiar enough
with the Wintel software architecture to be certain.)

PS, I'll be real pissed if somone patents (or has patented) this idea.

PPS, The ALDL<->Mac interface isn't ready to be "published" yet, so don't
ask for a schematic.  It works "in the lab" - using a short TinyBASIC like
program running in a spare ECM and animating the ALDL output, and a simple
raw hex dumping shell around the 160 baud device driver.  I need to etch a
circuit board, improve the Mac end's software, and actually test it in the
field.

                   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;}