ALDL Updates was DIY-WB Output Voltage Scaling

[Malcolm Robb, LC 0112G]

Of course the main job is to run the engine, but very little of the 'real 
time' control is handled by the cpu itself - most of it is handled by other 
CPU like peripheral chips which I believe are called TPU's. The CPU updates 
registers within these TPU's every so often. The CPU is basically timer 
interupt driven.

A timer generates an interrupt every 6.25 uS in my CPU code (it's a $B0 
mask which is unique, but I have no reason to believe that any other mask 
is very different). Lets call a 6.25uS period a 'tick' . Some tasks are 
performed every tick, some every other tick, some every 4th tick etc. At 
the beginning of every tick a flag is set. Once the CPU has finished 
executing all the code required within that particular 'ticks' timeslice, 
the flag is cleared. Now BEFORE the flag is set, the CPU checks the state 
of the flag. If it is already set, then the CPU says 'ahh - hang on a mo - 
something has gone wrong' and throws a trouble code (TC51 I think, can't 
remember) This is because the next timer tick must have occurred before the 
previous timer tick's code had finished. Therefore the CPU would know if it 
were being 'overworked'

Anyway, (again from memory - it's not often I can add to a discussion on 
this list and I haven't got the code here!) the ALDL code is called every 
16th 'tick'. The first thing it does is check to see if the ALDL transmit 
register is empty. If it isn't, it just exits, and carries on with whatever 
other tasks are scheduled for that timeslice, hence taking up very little 
CPU time. If the register is empty, it picks up the next byte to be 
transmitted, writes it to the transmit register, and then exits, and 
carries on with whatever other tasks are scheduled for that timeslice. This 
takes up a little more CPU time, but not a great deal. One byte takes 
roughly 1.2mS to transmit, so the register won't be empty again for another 
195 ticks (the time it takes to transmit 10 bits at 8192 baud).

So as you can see, the extra processor workload imposed by continuous ALDL 
activity is minimal. And it should also be noted than hardly any sensors 
are sampled every tick anyway.

This is MY understanding of MY ECU code. I haven't fully commented it yet, 
and can't pretend to understand it all. I expect someone else ( Ludis ?) 
can add to this, and particularly comment on what happens in other program 
masks.

Cheers,
Malcolm Robb, LC 0112G


-----Original Message-----
From:	Vim Fuego [SMTP:vimfuego at unite.com.au]
Sent:	Monday, September 03, 2001 2:04 PM
To:	gmecm at diy-efi.org
Subject:	Re: ALDL Updates was DIY-WB Output Voltage Scaling

> The only thing that's fixed is the baud rate (8192 baud) which means you
> will never achieve more than 800 or so bytes per second. The mode 1
request
> string is 5 bytes long, so 10 requests a second accounts for 50 bytes, or
> 6% of the bus bandwidth.

O.K, but the 'main' job of the ECM is to run the engine right!, so any
serial data routines must be lower on the priority scale?, so if the motor
is running at say 3,000RPM, how long does the ECM have to service the 
serial
data routine without having to ignore it and get back to it's primary
function?. Surely that (as well as number of bytes transmitted) dictates 
the
update rates?.

Vim


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