BigDumbDinosaur wrote:
as much as is practical should be done to minimize the impact of interrupt handlers on the foreground
Dr Jefyll wrote:
Certainly for some projects this mantra is valid
My bad. I should've made clear that Cecil's project is among those -- the majority -- for which the "protect the foreground" principle does apply. But exceptions exist. I recall one project where the only context that mattered at all was the ISR, and I allowed it to be lengthy. And why not! Everything else, including the foreground task, could take a rain cheque. Regarding "protect the foreground" and other points mentioned, what I'm stressing is that
goals and circumstances vary widely from one project to the next. The shrewdest approach is one that's always appraising the
tradeoffs -- perhaps unexpected -- which prevailing conditions allow.
BigDumbDinosaur wrote:
a priority encoder should be fairly straight-forward to implement in programmable logic
Yes, and even just an (E)EPROM will suffice if it contains an appropriate table. The various interrupt sources would be synchronized by a register if necessary then fed to the (E)EPROM address inputs. And (E)EPROM outputs are a full 8 bits and can tri-state, unlike those of the 'HC148.
By the way, you don't need a priority encoder to pull off the snappy little dispatch snippet I posted. Even an unencoded status byte will work.
Code:
LDX Status_Byte ;7 unencoded bits, padded with zero in the LS position.
JMP (VectorTable,X)
Notice I went down to only 7 bits, and the size of the Vector Table is 256 bytes (128 16-bit enrries). To reduce that, it may be desirable to use even fewer bits, as follows.
In the following example I'll assume we have many interrupt sources, but only two that are critical. ("Critical" could mean high volume and/or sensitive to latency.)
Code:
LDX Status_Byte ;all bits zero, except Bit2 is CriticalSource_B, Bit1 is CriticalSource_A
JMP (VectorTable,X)
Now the vector table has only four 16-bit entries. It will tell you where to immediately go if CriticalSource_A is active, if CriticalSource_B is active, or both A and B are active. For the fourth case -- ie, neither A nor B -- the Vector Table sends us to an unexciting routine that polls the remaining sources. So it's a hybrid approach.
We're spending some memory to support this, and the amount doubles for every additional input to the lookup. A priority encoder doesn't need the lookup at all. But with a priority encoder it's the input wiring which determines the various priorities. If you move that decision to a lookup table in RAM you can shuffle the priorities at will, even on the fly -- a powerful advantage in some scenarios.
-- Jeff
_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html
Login
Register
FAQ
Search
I'm just scoping out the available tradeoffs. (Even fancier would be to use the CPU's VPB output to gate the '148 -> '540 onto the bus. That's simplifying slightly. But it would eliminate even the two instructions just listed. 
)
