GM ALDL interface

[Terryk]

Hi Ludis,

No, I reprogrammed the time-of-day interrupt. That happens at a higher
priority than anything else (relatively speaking). I then just need to
service it at multiple intervals to keep the clock correct.

So no matter what happened, every 500us (I think that what I finally use to
assure I will sample and see the 0->1 transition), an interrupt occurs and
it jumps to read lpt port routine which reads the bit and stores it. I
could have a bunch of other programs running and it will still occur
(assuming the other programs don't take over the interrupt, or if they do,
they handle it correctly so mine interrupts still happen..

Of course, the foreground program can get bogged down my other stuff, but
this is real slow data rates. The floppy won't affect it and a network
interrupt shouldn't unless they don't take over the interrupt correctly.
But then, I don't have a network cable long enough for driving around!

It was actually pretty simple once I figured it out.

Terry Kelley

----------
> From: Ludis Langens <ludis at netcom.com>
> To: diy_efi at coulomb.eng.ohio-state.edu
> Subject: Re: GM ALDL interface
> Date: Sunday, December 07, 1997 6:07 AM
> 
> 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;}