ALDL Updates was DIY-WB Output Voltage Scaling

[Malcolm Robb, LC 0112G]

Caution, treat all the below with suspicion. I meant to say that I can't 
verify any of it because I can't get a spare Memcal for my car to reprogram 
it. It's all derived from what I think happens based on a disassembly of my 
EPROM code.

Also, my use of 'Major loop' may be what BobR calls 'Minor Loop'.

Just 'trying' to be informative
Cheers,
Malcolm

-----Original Message-----
From:	Malcolm Robb, LC 0112G [SMTP:Webmaster at lotus-carlton.fsnet.co.uk]
Sent:	Tuesday, September 04, 2001 10:47 AM
To:	gmecm at diy-efi.org
Subject:	RE: ALDL Updates was DIY-WB Output Voltage Scaling

Ludis is right, and I should have waited till I had the code in-front of me 
before posting. Sorry if I mislead anyone. What happens is...

The receive part of the UART generates an interrupt when a byte is received 
(from the scan tool). This interrupt routine collects received bytes until
the complete command string is received - i.e. $F4,$57,$01,$00,$B4 . The
receive code checks the format of the command, verifies that the checksum
is correct (the $B4 in this example) and the message length (the $57). If
everything is OK, it then sets up some pointers to the data table to be
used in transmission depending on the mode byte (the $01), and writes the
first byte to the transmiter in the UART (which will normally be $F4). The
Transmit part of the UART then takes over.

The transmit part of the UART is double buffered. For those that don't
know, this means that it contains a transmit register, and a holding
register. The data actually being transmitted is sent from the transmit
register. The user (CPU) can't directly access the transmit register. What
happens is the CPU writes data to a holding register, and when the transmit 
register becomes empty, the data is then transferred automatically from the 
holding into the transmit register. This transfer generates an interrupt,
which tells the CPU that it is safe to write another byte to the holding
register. In this way, a continuous stream of transmitted data can be
achieved, because the holding register always contains the next byte to be
transmitted. In reality the CPU has ages to respond to the transmit
interrupt and write the next byte to the holding register, because as long
as it does this before the previous byte is transmitted, the stream will be 
continuous. Remember a transmitted byte is 10 bits long (8 data bits + 1
start bit + 1 stop bit), and at 8192 baud, this takes 1.22mS to transmit.

What I did get right was the stuff about the heartbeat/ idle chatter (I
think). BobR mentioned the kernel scheduler & the minor and major loops.
I'll let him try and explain that coz it's a bit complicated to put into
words, but basically there are 16 major loops, executed in order at a rate
of one each 12.5mS. In each major loop, the ECU code checks to see if it
should start to transmit a heartbeat frame. If it should, then it sets up
the pointers to the ALDL transmit table to be used, and writes the first
byte to be transmitted to the holding register. After that, the transmit
interrupt code explained above causes the rest of the heartbeat frame to be 
transmitted automagically - as Ludis states. TurboP4.PDF in incomming
explains this pretty well - section 5.6.1 onwards.

The fact that the major loops execute every 12.5mS means that you have to
be careful how many bytes you put in the heartbeat frames. 12.5mS is only
enough time to transmit 10 bytes. This includes the 3 header bytes and the
checksum, so in reality, you've only got space for 6 meaningful data bytes. 
I haven't checked what happens if you specify more bytes than that, but it
wouldn't surprise me if it all went to pot. Note also that 12.5mS is 80
frames a second, which is more than you'll get just about any other way.


----------------------------------------------------------------------------
To unsubscribe from gmecm, send "unsubscribe gmecm" (without the quotes)
in the body of a message (not the subject) to majordomo at lists.diy-efi.org