On Fri, Jun 22, 2001 at 08:36:55AM -0400, Olin Lathrop wrote:
> > a) _is_ there some recommended time to wait after changing
> >    the TRIS (in this case, PORTA on a 16F870, none of the pins
> >    defined as analog).
>
> As far as I know, the new TRIS setting takes effect at the end of the cycle.
> I bet the chip switches this internally very fast.  It might take the
> external circuit a little time to react, especially when changing to high
> impedance.
>

   That's what I'm thinking might be happening. I've gotten
a few spurious results with a couple variations of the code (Totally
incorrect results, but I've received bytes other than 0xFF and 0x00
a few times.)

   What can be done to stablize the wire faster?


> > b) Would it be common for the wiring to require more than just
> >    running the serial line into the pic? AFAIK, it's a TTL-level
> >    serial port -- ie, adding an in-line resistor, 'T'-ing a
> >    largish resistor to ground?
>
> I would want some protection, especially since this is in a car.  Since this
> obviously isn't real RS-232, make sure everything else matches too.  Is
> there the usual start bit, 8 data bits, and at least one stop bit?  What is
> the polarity, which level is idle?
>

   Just sticking a multimeter on it, when it should be idle
I'm getting about 0.01V, probably safe to just call it 0. The
ECU takes a single byte and returns a single byte for each
transaction; ie, send it 0x0A, it'll return some value that
gets multiplied by a scaling factor (ie, RPM values get multiplied
by 3.33, for example, and you get a range of 0-8500) That being
the case, I don't think it matters if the PIC end of it watches
for stop bits. I'm not too concerned with catching errors at
this point, yet.


   I've seen schematics for ALDL for other cars (Tons of info
on GM makes, in particular), and most of them use a MAX-232
chip to run into a laptop serial port, so I'm assuming (yeah,
I know..) they're all reasonably standardized.



> > c) Would I better off just running it into the serial UART? With
> >    the 20Mhz Fosc, I can get 1917.178 bps, or 1929.012 bps, one of
> >    which should be "close enough", I think. What's the best way
> >    to keep the Tx line from shorting to the Rx, or is that not
> >    really an issue as long as receives are disabled?
>
> Either of those baud rates will be just fine, again assuming this is RS-232
> protocol even though the voltage levels are different.  Are you really sure
> this is 1920 baud and not the standard 19,200 baud?  I know nothing about
> automobile ECUs, but 1920 baud would be rather wierd in the RS-232 world.

  (I think automobile ECUs are thier own little world.. GM ECU's
have/had 160bps datastreams, and 8192bps -- neither of which I've
heard of being used anywhere else.)


> Is it possible that 1920 is the bytes/second rate?  That would come out to
> 19,200 bits/second.
>

   That was my thought, too, when I heard they ran at 1920, since
it's just _too_ coincidental. OTOH, these were made in 1989, quite
possibly earlier... I've got a few more versions of the code to
try out tonight, so I think I'm going to try a few variations
running at 19200 instead. From what I've read, the ECU can do between
50-75 updates per second, which seems a bit more in line with 1,920
figure than the 19,200, although the ECU is doing plenty of other
things at the same time, and as RPMs go up, the update rate will go
down.




--
Andrew S. Mehlos               |finger dweezil@execpc.com for PGP key

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics