One of the things I'm contemplating is how nested an Intel 806x microcontrollers (MCs) can be in Interrupt Service Routines (ISR). For example, if one ISR is currently executing, another at a higher priority can stop the currently processing ISR, and begin running the higher priority ISR. However is there a limit to how nested interrupts can get on 806x MCs

The eectch98 doc covers some of this for the 8061 listing 8 interrupts in the vector table. But instead of numbering their priority, they are given generic priority names like Highest, High, Low, and Lowest. Obviously lower priority ISRs can be interrupted by higher priority ISRs. But what about an ISR that is listed as high, can it be interrupted by another high? Do the address locations in the vector table ever change between the 8061 and 8065?

Also, how are ISR's associated with physical pins on the MC?

There's also an Interrupt Mask register and Status register. How are these used in code?

There also seems to be some inherent association between PIPs and Injector Pulses when in a mode called Limited Output Strategy (LOS). The eectch98 doc mentions this, but it doesn't go into great detail. It insinuates that when the watchdog isn't maintained, the EEC goes into this LOS state and the PIP fires injectors based on things called C18 and R52. But I have no clue what those are...capacitor and resistors on the circuit board???

What about under normal operation...does the EEC code keep up with which injector to fire or is the PIP association kept up with automatically in the HSO co-processor thus the only thing the EEC has to output is a start time and time-length, not which Injector to begin firing. If that's the case, then some HSO configuration is required so the HSO knows whether the engine is 4, 6 or 8 cylinder. It also needs to know a firing order for the injectors, hence why I just always assumed the code handled all this.

_________________
...Always Somethin'

89 Ranger Supercab, 331 w/GT40p heads, ported Explorer lower, Crane Powermax 2020 cam, 1.6RRs, FMS Explorer (GT40p) headers, Slot Style MAF, aftermarket T5 'Z-Spec', 8.8" rear w/3.27s, Powertrax Locker, Innovate LC-1, GUFB, Moates QuarterHorse tuned using BE&EA

Member V8-Ranger.com

I've never programmed any Intel 806x MCUs, but in my experience, interrupts cannot interrupt other interrupts. The priority scheme is very simple - basically interrupt prioritization. One way or another, the MCU will order all interrupts scheduled to occur on the same clock and process them back to back if necessary, but not interrupt each other. This is very unlike modern OSs which use separate threads to handle interrupts (device driver level stuff), which can run at slower or faster rates based on their priority.

_________________
'89 5.0L: 8.4:1 Dart 304, Crane 2031 cam, GT-40 lower, KB Blowzilla 2.2, LMAF, 90mm TB, 42# injectors, TwEECed A9L
'79 Bronco on 35s & 4" lift: 8.5:1 408M, Crane 523902 cam, GT-40 lower, Cobra upper, Cobra 70mm MAF, 65mm TB, 30# injectors, EDIS8, TwEECed A9L, single O2
'08 Buell XB12Ss: stock 10:1 1203, Drummer SS, '10 header, independent O2s, K&N filter, 3 bar MAP, DDFI3 tuned via TunerPro RT

Interesting. If that's true, then the processor disables all interrupts while executing an ISR and re-enables them, without the software having to command that behavior, once the ISR has returned to normal operation, thus letting any interrupts that happened while interrupts were disabled begin to execute. Highest priority pending wins until all interrupts are satisfied. Then the EEC falls back to processing the background loop.

I expect for a lot of this stuff, I'll just have to go digging through the 8096 documentation. But that does vastly simplify things if I don't have to worry about interrupts interrupting a currently processing ISR.

Since the 8096 also uses HSI/HSO, I'm hoping the details about how those are configured and operate will be similar enough to the 806x's version.

_________________
...Always Somethin'

89 Ranger Supercab, 331 w/GT40p heads, ported Explorer lower, Crane Powermax 2020 cam, 1.6RRs, FMS Explorer (GT40p) headers, Slot Style MAF, aftermarket T5 'Z-Spec', 8.8" rear w/3.27s, Powertrax Locker, Innovate LC-1, GUFB, Moates QuarterHorse tuned using BE&EA

Member V8-Ranger.com

I agree with shaker666.

I've programmed a few low level microprocessors, and there's no fixed rules across them all.

Looking at the actual EEC code though, notice that interrupt routines never call DI, but do sometimes call EI, but mostly RETEI when they complete. To me, this says "one int at a time" handling,and 'disable ints' bit is set when interrutp triggered.

Typically, the priority typically tends to be by bit position, 'cos that's easy to acheive.
So I guess that the priority will be bit 7 highest, down to bit 0 lowest. When an interrupt occurs, it gets stored in the INT_STATUS register (0x9), so that as soon as interrupts are enabled, i.e not in interrupt handler, the next bit set in the INT_STATUS register will trigger the relevant int handler.

I can't say for sure this is right, but it feels right....

_________________
TVR Tasmin 280, TVR Tuscan 2.8 Efi (EEC IV), various kit cars, IT code geek....
Crusty old Classic car freak.

now im curious, how many interrupts does the eec4s use? in my own endeavors i've only found it neccessary to utilize 5 interrupts, 4 devoted to cam position for DOHC w/ variable cam timing and crank position (tach/rpm)

seems like the eec4 would only need 2, as they only support a single cam sensor and crank trigger/pip

everything else is going on in the loop, plenty of processing power to cover it with a full execution loop occuring approx. 25x a second, unless someone see's something that i overlooked

_________________
http://www.efidynotuning.com/ford/

the EEC in my (very old) 1995 2.8i (European Granada, basic setup, no EGO, etc)

has only 4 interrupts, and one of those is for the plug in Calibration Console, so in reality it uses
only 3 for engine.

1. Timer overflow.
2. High speed in. (ignition etc)
3. High speed out.

1. Timer overflow - on mine, with a 7.5 Mhz crystal, this occurs every 0.3 secs. Used to stop the pump after 1 sec of no PIP.

2. HSI for PIP signal, and BAP (atmospheric pressure) if fitted.

3. HSO used for ISC idle speed and trip computer output (both are 'end pulse' events).

Pretty basic stuff ....

_________________
TVR Tasmin 280, TVR Tuscan 2.8 Efi (EEC IV), various kit cars, IT code geek....
Crusty old Classic car freak.

Timer overflow and HSI make sense as interrupts. But how/why does the HSO interrupt the processor? Just making a wild guess, I'll assume there's only certain time windows certain High Speed outputs can be set. So the HSO interrupts the processor when it is ready for the processor to tell it to command the output. That's just contrary to my normal handling of outputs, but I also live in an RTOS world, not a foreground/background loop setup like these EECs run. In an RTOS, I command outputs on my terms when I'm ready for them, not when they are ready for me to tell them what to go do with themselves.

_________________
...Always Somethin'

89 Ranger Supercab, 331 w/GT40p heads, ported Explorer lower, Crane Powermax 2020 cam, 1.6RRs, FMS Explorer (GT40p) headers, Slot Style MAF, aftermarket T5 'Z-Spec', 8.8" rear w/3.27s, Powertrax Locker, Innovate LC-1, GUFB, Moates QuarterHorse tuned using BE&EA

Member V8-Ranger.com

Actually the STO events can be set anytime in the future, within reason.
Both HSI and HSO have a 12 slot FIFO.

Good question, as to why, but I suspect it's ease of timing. The outputs on mine (ISC and TRIP) are set interrupt on the "OFF" event, triggering the code to restart the output processing, which sets both the next on and off events. Ths ISC is only 160Hz or so, and the trip computer can be a little as once a second (I think).

Ignition STO out does not set interrupts on the code in my box, as it's always calculated and set/triggered in the PIP interrupt handler.

(does that help ?)

_________________
TVR Tasmin 280, TVR Tuscan 2.8 Efi (EEC IV), various kit cars, IT code geek....
Crusty old Classic car freak.

That helps. But just to make sure I got it. The HSO gives an interrupt after completing an output's ON/OFF control cycle to inform the EEC that another commanded ON/OFF is needed to keep the output cycling (if necessary).

So what controls timing on and off? If the interrupt is on the OFF, then does that mean the EEC calculates an ON time and feeds that to the HSO along with which output to turn ON? Does the EEC also calculate the time to turn the output ON? If so, this is starting to make a LOT more sense. The only thing I'm missing at this point is how the EEC communicate which output the delay and ON times are for in the FIFO.

_________________
...Always Somethin'

89 Ranger Supercab, 331 w/GT40p heads, ported Explorer lower, Crane Powermax 2020 cam, 1.6RRs, FMS Explorer (GT40p) headers, Slot Style MAF, aftermarket T5 'Z-Spec', 8.8" rear w/3.27s, Powertrax Locker, Innovate LC-1, GUFB, Moates QuarterHorse tuned using BE&EA

Member V8-Ranger.com

It's actually simpler than that.... every HSO output request (i.e. state change request) carries with it - 1. event time 2. channel no 3. on or off (flag) 4 interrupt or not (flag).
Time is written into register '0xE' , state,chan no, int flag, are written into register '0xF'

So the code writes events into the (hardware) queue, which then get processed at the specified time. An immediate state change is done by writing current IO_TIMER value plus...er. 2 ? 4? for logic to work.

So the code can write one or more future events with or without interrupts as it chooses.

So as you say, code calculates pulswidths/frequency, and then uses that for event times.

_________________
TVR Tasmin 280, TVR Tuscan 2.8 Efi (EEC IV), various kit cars, IT code geek....
Crusty old Classic car freak.

Ahh, so the EEC can enter the ON time in the future and have that completion NOT create an interrupt, then it can create an OFF time for the same output at some further-out time in the future, but on completion of that, create an interrupt.

So the FIFO queue, what exactly makes it a FIFO? Do all entries into the FIFO have to be in sequence order of execution? Or is the FIFO just 12 placeholders for output control events. That doesn't seem very FIFOish as I could load up 11 events, and have the 12th one complete before any of the others. So would it be gotten to in time? Would it be missed?

BTW, all great info and exactly what I'm looking for.

_________________
...Always Somethin'

89 Ranger Supercab, 331 w/GT40p heads, ported Explorer lower, Crane Powermax 2020 cam, 1.6RRs, FMS Explorer (GT40p) headers, Slot Style MAF, aftermarket T5 'Z-Spec', 8.8" rear w/3.27s, Powertrax Locker, Innovate LC-1, GUFB, Moates QuarterHorse tuned using BE&EA

Member V8-Ranger.com

According to the doc, the fifo only applies to the HSI. The HSO uses what is called content addressable memory. It appears that the CAM ring is only addressable through the HSO port. In my experience, micros allow individual addressing of HSO ports. Why this was multplexed this way is unclear. What I want to know is, since the events have a resolution of 12 state times, are the are the event times compared as a ">="? If so, how do you schedule events that occur after the timer overflows?

Brian
EFI-Unlimited

For the HSOs, my guess is the max distance in time you can schedule is however far 16 bits gets you. So my next question is, are the time values in clock ticks, milliseconds, or are they in some finer measure that allows for sub-millisecond control? To get the best accuracy, I expect the values are some multiple of the crystal so microsecond control is possible. After all, we datalog things like the injectors in sub millisecond values.

And based on the way you are stating this, I'm also assuming the time values you enter should be relative to the clock, not "delay" values.

As for how you schedule time beyond where the clock rolls over, I expect that's done by the simple virtue that you cannot command a value in the past. As long as the EEC is working with unsigned values, it simply adds whatever time is required to the current time value. So if the EEC wants something to happen at 63000 and the clock is at 61000, the EEC adds 2000 to the time value of NOW. If the clock happens to be at 65000 (clock rolls over at 65535), then adding 2000 to that will result in a value of 1464 so that's what gets written for a trigger. The math in these cases works out conveniently the same so you don't have to give any special thought to roll-over scenarios.


Moving on to HSIs...the FIFO makes far more sense in the case of inputs allowing it to buffer up to 12 samples before loosing data. When the EEC is ready, it reads each sample out of the buffer in FIFO order. Similar to how the EEC writes HSO commands, I'm assuming each FIFO entry has a value word and descriptor word to tell the EEC what the input value is and what input the value associates to. What are all the bit meanings of the bits in the descriptor word? I'm assuming this is defined somewhere in the 8096 somewhere? If so just say so and I'll go look that up if I ever need to mask-out the bits. At this point, I'm less concerned with bit positions than I am with what info is available to the EEC.

But this does bring up a question about how the HSI works. Is reading of the inputs a round-robin thing or does the EEC command the HSI to read certain inputs at intervals? In other words is the EEC telling the HSI what to read or is the HSI just reading inputs and methodically putting them in the buffer? Is there some configuration of the HSI so it isn't reading inputs that the EEC doesn't care about? For instance, I could envision the EEC might want to get interrupted on some values, but just want the HSI to quietly fill the buffer for others. Or perhaps the HSI always interrupts when putting something in the queue...thus it's up to the EEC to "clear the buffer" before leaving the ISR that reads out the buffer in order to clear the ISR flag so the next sample will trigger another interrupt. Thoughts?

_________________
...Always Somethin'

89 Ranger Supercab, 331 w/GT40p heads, ported Explorer lower, Crane Powermax 2020 cam, 1.6RRs, FMS Explorer (GT40p) headers, Slot Style MAF, aftermarket T5 'Z-Spec', 8.8" rear w/3.27s, Powertrax Locker, Innovate LC-1, GUFB, Moates QuarterHorse tuned using BE&EA

Member V8-Ranger.com

All HSI and HSO time values are in clock ticks. Moreover, they both use the same clock, so HSO events can be very accurately timed relative to HSI events.

As for the HSO scheduling, your logic would be fine for typical HSO operation. The issue here is the cam ring. Imagine the clock is at 100, and you write a HSO command to happen at 105. The 105 command enters the cam round robin. The CAM can be 12 commands deep, and only one is evaluated once per clock tick. This means that the 105 command we wrote may not be processed untl the clock reaches 112. At this point, dos the comparator apply a >= logic and execute the 105 command, or will it apply = logic and pass it over as if it were intended to occur 65529 in the future?

So, in writing this, I just realized. The above is how typical HSO's work (except for the CAM ring). If the eec HSO were to use time offset, as opposed to absolute clock ticks it could work. It could decrement every target cam value by 12, and execute the command when it reaches zero. Unusual, but could work. We need more doc's to learn its actual behaviour.

The HSI can be programmed to generate and interrupt on every trigger, or, when the fifo is full.

Brian
EFI-Unlimited

Interesting. I would assume for simplicity that in your Cam timing example, the code in the EEC should be written to never command an event that is to happen within say 12 clock ticks of NOW. So if time was 100, the EEC code should know better than to time something for 105. Minimum earliest time to execute should be 100 + X to best guarantee the event gets handled without a roll-over. And since execution also eats clock ticks, the clock value at the moment the clock was read and the clock value at the moment the command is written to the HSO would also need to be determinate and included in this "minimum" time. So lets say there's 15 clock ticks of code execution between when the code reads the clock value and when it writes to the HSO. In this case the EEC code should have a minimum earliest time to command something of NOW + 15 + 12 so what the HSO should receive would be 100 + 15 + 12 or 127 to ensure the clock doesn't run past the commanded time value before the HSO can process the command. Since clock ticks are sub microseconds in length, delaying the command won't hurt a thing. Adding 50 clock ticks to NOW is only adding about 3 microseconds on a 15MHz processor...negligible to any mechanical device that runs the engine. However for all we know, the HSO applies a fixed subtractor to the time value to ensure events don't get passed over thus sticking around for a clock roll-over. I'm sure it's far easier for the HSO to do this in hardware than it is for code to handle it. Adding all this, even if done all the time just adds more clock cycles to the delay between reading the clock and commanding the HSO.

But just so I know my thinking is correct, I'm calculating that the 16-bit clock of a 15MHz machine rolls over every 4.369 milliseconds. I got that by dividing 1 second by 15MHz, then multiplying by 65536. Thus the furthest out an HSO command can be set to trigger is about 4.369 milliseconds into the future. Any further out and it will get executed earlier than expected. Is that correct?

_________________
...Always Somethin'

89 Ranger Supercab, 331 w/GT40p heads, ported Explorer lower, Crane Powermax 2020 cam, 1.6RRs, FMS Explorer (GT40p) headers, Slot Style MAF, aftermarket T5 'Z-Spec', 8.8" rear w/3.27s, Powertrax Locker, Innovate LC-1, GUFB, Moates QuarterHorse tuned using BE&EA

Member V8-Ranger.com

OOPs, as EFI-unlimited says, the output queue is NOT a FIFO, every slot is scanned in a loop.
Sorry bout that.

For output timing, the code in my box (at 7.5Mhz) checks that there is always at least 42 clock ticks to go before output event. If there isn't, it ADDS 42 clock ticks (~200us). I assume that the 42 clock ticks is to ensure there is a chance for the CPU to cycle & check all the way around its output queue. I suspect the later boxes will add (at least) 42 also, but it represents less time.

I do know that the A9L, the box which drives the 302 V8 (and possible others) has a separate output queue in its RAM, because there can be too many events to store. As it has sequential injection and al the other goodies too, there's a lot to control...

_________________
TVR Tasmin 280, TVR Tuscan 2.8 Efi (EEC IV), various kit cars, IT code geek....
Crusty old Classic car freak.

The HSO and HSI are synchronised with the master I/O timer that is clocked every 12 state times. Since it takes 12 state times to rotate the CAM no events are missed. When writing a time to the HSO at least 3 state times are added to the existing I/O time to ensure it doesn't get 'missed' (15 Mhz ecu). The earlier, slower, processors probably need a longer delay period adding.

Are yu saying that 1 tick of the HSI/HSO timer units is 12 state times? If so, that would explain everything.

EDIT: I just re-read the doc, and that is exactly what it describes. For those that want to know, I tick of the HSI/HSO is .0000024 seconds. This is derived by 15MHz / 3(clock scaler) = 0.0000002 seconds per state time. 0.0000002 x 12(state times per tick) = 0.0000024.

Brian
EFI-Unlimited

There's a question from that info.....

Assuming the actual logic of the 8061s are all the same, it shouldn't matter WHAT speed the xtal is running, as everything HSI/HSO is sync'd to the I/O timer. That is, code should always add the same amount (in IO ticks) for the HSO to cycle, as that should be constant.

Given that even simple instructions take 3 clock cycles or more, I can't believe that the HSO is scanned every single clock cycle, but could accept 3 or 4 clock ticks per slot, (i.e. 36 or 48 clock ticks around, = 3 or 4 I/O ticks), but it would be more if an actual output is required, I guess?

I see that A9L adds 3 I/O ticks at one point, which I suspect is for 'NOW' implying that it does indeed take 3 I/O ticks to do a full cycle of the HSO.

I wonder why my early box adds 42 I/O ticks then? It seems far too much....hmm..a mystery.
My box only subtracts a 2 for incoming HSI, same as A9l...

_________________
TVR Tasmin 280, TVR Tuscan 2.8 Efi (EEC IV), various kit cars, IT code geek....
Crusty old Classic car freak.

Ok, now I'm not clear on something. There are 2, unrelated clocks? If I'm hearing you right, there's a processor clock and an IO clock and they are clocked independently of each other? In addition, there's some scalar in the tune that has something to do with how the two interact? Fill me in...

_________________
...Always Somethin'

89 Ranger Supercab, 331 w/GT40p heads, ported Explorer lower, Crane Powermax 2020 cam, 1.6RRs, FMS Explorer (GT40p) headers, Slot Style MAF, aftermarket T5 'Z-Spec', 8.8" rear w/3.27s, Powertrax Locker, Innovate LC-1, GUFB, Moates QuarterHorse tuned using BE&EA

Member V8-Ranger.com

Chris,

There are 2 related clocks. They are the CPU clock, and the Master I/O timer. The CPU clock is the generated by dividing the crystal oscillator by 3. The Master I/O timer is derived by dividing the CPU clock by 12.

Brian
EFI-Unlimited

OK, I rescanned Tom Cloud's document..... His words from the doc are -

"The clock signal period, called one state time, equals three oscillator periods".

"The CAM file rotates one position per state time, so it takes 12 state events for the holding
buffer to access all 12 registers. Therefore the time resolution of the HSO unit is 12 state times or
2.4 microseconds if a 15 MHz crystal is used."

"Operation of both HSI & HSO are synchronized with an internal master I/O timer which is clocked every 2.4 microseconds (15 MHz crystal)."

THEREFORE.

With a 15Mhz clock, the IOTIMER gets incremented every 36 clock cycles, 12 state times, or 2.4 uS (microsecs) The HSO CAM gets 'cycled' every 3 clock cycles, or 1 state time, so for 12 entries, it amounts to the same 2.4uS.

So that all makes sense.......and fits together neatly from one master crystal.

This means that theoretically the CPU can schedule outputs down to 2.4uS accuracy.

What I do see in the code I have looked at is typically the boxes SUBTRACT 2 IO ticks (4.8 uS) for HSI interrupts, which implies there is a 4.8uS delay before the interrupt actually gets processed,
and the A9L seems to add 3 for outputs when it means "NOW".

This is probably a safety feature to make sure 'slow' components work across mass manufactured
ECUs ???

So I haven't a clue why my old box adds a relatively massive 42 IOticks to it's concept of "NOW", unless it's internal timing is slightly different, or I've misunderstood what it's doing..

_________________
TVR Tasmin 280, TVR Tuscan 2.8 Efi (EEC IV), various kit cars, IT code geek....
Crusty old Classic car freak.

There is no processing latency to account for. The Master I/O timer is latched at the time of the input, and then the interrupt is generated. The CPU can service it at it leisure, and read the exact count of the timer it occurred. Then it can schedule an event on the HSO, to occur automatically at any count of the timer. This is what make the HSI/HSO so accurate and powerful.

The addition and subtraction of ticks may be calibrated latency in the input or output circuitry.

Brian
EFI-Unlimited

For the HSO, I'd imagine that the addition of at least one state time is necessary to allow for the possibility of the master I/O timer being incremented between the time is was read and the CAM being written to.

Now I'm getting confused with the terminology, clocks, ticks, state times, IO state times, etc. So I need some definitions and consistency in usage from people contributing so we can all be on the same page.

On a 15MHz machine, you have a 15MHz crystal producing a 15MHz clock. However according to what I'm hearing here, the processor's tick is 1/3rd the crystal making it only a 5MHz processor? Is this true or is there some caveat I'm missing here?

Now the IO clock is 1/12th the 15MHz clock or the 5MHz processor tick?


I do recall the 2.4us time period for the IO times. So the furthest into the future an event can be scheduled is 157.28ms? However I'm hearing that some HSOs tack on additional time if the time value is too close to NOW. What if the value is past NOW? Is there anything we can nail down about how the HSO works or at least detail out the known variants and what processor families they are most likely to be found in?


Related to this 2.4us time period, I recall discussing with somebody years ago that the HSI can only be read at 2.4us intervals. However if the HSI is based on a FIFO, I would expect that as soon as a value has been read from the FIFO, the value in the HSI registers increment to the next value in the FIFO...at least by the next clock/tick/something. Can someone clarify this?

Likewise they were saying you can't write into the HSO any faster than 2.4us. And if the 12 placeholders in the HSO cannot be directly addressed, this would almost make sense. But can anybody clarify for sure that the HSO can't be written to any faster than 2.4us? For example, if the EEC calculates an injector ON and OFF event. Can both be written into the HSO at the same time? Or would the EEC calculate the ON time, write that, then calculate the OFF time, then write that...and in the time it took to calculate the OFF, more than 2.4us has passed thus its never an issue? The reason I bring this up is if it is possible for a much faster clocked J3-connected processor to tell the on-board EEC the ON and OFF events back-to-back with the only delay between writing them being how fast the EEC can load the instruction to write the value to the HSO.

_________________
...Always Somethin'

89 Ranger Supercab, 331 w/GT40p heads, ported Explorer lower, Crane Powermax 2020 cam, 1.6RRs, FMS Explorer (GT40p) headers, Slot Style MAF, aftermarket T5 'Z-Spec', 8.8" rear w/3.27s, Powertrax Locker, Innovate LC-1, GUFB, Moates QuarterHorse tuned using BE&EA

Member V8-Ranger.com

Typically, the times written to the HSO are relative to times read from the HSI. Rarely is the master I/O timer read directly. Consequently, most HSO events are scheduled immediately following a HSI input which gives the most lead time possible. There is usually some minimum allowed time delta between the two to ensure the commanded times stay ahead of the clock, and don't get missed.

Chris,

Yes, its a 5MHz cpu, as I understand it. The master I/O timer is 1/12 of 5MHz.

Brian
EFI-Unlimited

The 'state time' is equal to 3 oscillator periods, so for a 15 Mhz cpu a state time takes 0.2 uSecs.

The HSI/HSO master I/O timer is clocked every 12 state times, e.g. every 2.4 uSecs.

I think you can write to the HSO faster than 2.4 uSecs, you just need to ensure the HSO holding register isn't full. The maximum time in the future you can program the HSO event for is 157.284 mSecs. The code usually runs a 24 bit timer (sometimes 32 bit) in ram to handle longer periods.

The master I/O timer at 0x0006 gets read pretty often when determining the time to write to the HSO, e.g. the send HSO command service routine.

Unless you're bit banging outputs, I can't think of a situation you would want to read the I/O timer directly. Maybe if you want to check that the event is far enough ahead of the current clock would be the only reason, but if you service the HSO, during the HSI ISR, you don't really need to.



Chris, I'm sure Derek is is correct. You can read and write the HSI/HSO as fast as you want, provided the buffers have room. The resolution of the timer is all that is limited.

Brian
EFI-Unlimited

Sorry Brian, that's what I meant, but I wasn't very clear. Latency in the processing circuitry (and perhaps in the pickups themselves ? Magnetic devices have delays after all.....) not in the CPU processing itself.

For output, sailorbob's point is a good one too, we know it's always a good idea to add a small safety margin just in case ....

For the later comments - remember there are status flags for 'HSO_full' and 'HSI_ready' both are in IO_STATUS register (0xA) .

I thought we were reasonably consistent on the terminology ?

Crystal clock = 15 Mhz = 0.066 uS (microsecs), = 66 nS (nanosecs)
State time = 3 clocks = 5 Mhz = 0.2us = 200 nS
IO clock = 36 clocks = 12 state times = 416Khz = 2.4uS

ALL of these are derived from the main crystal. As my old box has a 7.5mHz crystal, all these times are therefore doubled for my box.

_________________
TVR Tasmin 280, TVR Tuscan 2.8 Efi (EEC IV), various kit cars, IT code geek....
Crusty old Classic car freak.

Actually I would argue with that because all of the pulse width outputs (Idle valve, injectors) DO keep their last output time so that the pulse width can be accurately tracked. If there is a delay in output (say the queue is full) then the code remembers the ACTUAL output IO time, not the requested one. The main output routine in all the different code bases I've seen do this by reading IO_Timer and remembering what they write to HSO ...

For HSI inputs, it gets converted to a 'on-time' or 'off-time' (in IO-Timer ticks) almost immediately....

_________________
TVR Tasmin 280, TVR Tuscan 2.8 Efi (EEC IV), various kit cars, IT code geek....
Crusty old Classic car freak.