Quote: The priority encoding saves a whole bunch of code in the top-level ISR. It just has to read INTSTATUS, rotate it left once and extract the particular device's handler from a table. The value 0 means something has gone wrong (it should never happen because the IRQ line should be high in this case.)
Make sure you shift, not rotate, so the resulting low bit won't be a surprise. Anyway, the scheme will most efficiently be for 7 interrupts, not 8, since the 8th bit will be shifted or rotated out.
The following is not particularly related to programmable logic, but I'll reply to these quotes in case it gives someone any ideas.
Aslak3 wrote: I probably should have put some additional context: the software is a multitasking OS, which complicates things somewhat. I'm assuming you either have multiple ROM images for different tasks, or some kind of self-modifying code solution? I don't really have that choice. From the point the ISR runs, any of the sources could be in use. Hence looking at hardware solutions.
The routines that install and delete ISRs are (or can be) in ROM. The ISRs I use all the time are also in ROM on the workbench computer, but other ones get compiled and put in RAM on an as-needed basis. If I were to need multiple ones of the very highest-priority ISRs, especially without your multiple IRQ\ inputs, then yes, some kind of self-modifying code solution might be in order. See further down though.
I don't have any experience with preemptive multitasking OSs; but for several products, I've used a cyclic executive to do OS-less cooperative multitasking with extremely low overhead, in systems that lacked the resources to run a multitasking OS, or where hard realtime requirements would rule one out anyway. I wrote it up in my article on simple methods for multitasking without a multitasking OS. In the last major job, I used a PIC16 microcontroller switching tasks at approximately 10,000-16,000 times per second while running timer-generated interrupts at 39.0625kHz which is the 20MHz clock speed divided by 512, or one interrupt per 128 instruction cycles, with a jitter of only one instruction cycle in spite of the task switches which were neither related to, nor synchronous with, the interrupts. Since the tasks relinquish control only when they're at a good stopping point, the task-switch overhead was nothing more than a subroutine return and call, which can be interrupted. As mentioned in the article, if the task list needs to change from time to time, it would have to be in RAM, and the task called at the top of the list should probably be the one that adjusts the list, adding new tasks or deleting ones that are no longer needed. After deleting one, it can either move the following ones up to fill in the spot, or replace it with NOPs.
Quote: Quote: The ISR examples I see in books are usually way more complicated and inefficient than they need to be. Indeed. Another reason, though, for making ISRs with "redundant" code in them is it can sometimes simplify debugging. I have a check against a unitialised handler pointer in my main ISR just because I know if I don't put it in (it should never trip, of course) I'll get bitten by some subtle and annoying bug later down the road.
What I have in my '816 Forth is that the ISR installer maintains a pair of lists of handler pointers (both for IRQ, no such list for NMI): one for assembly-language ISRs, and one for Forth-language ISRs. The assembly-language list gets higher priority (since, if they didn't need the highest performance, they'd be in Forth); but within each list, the pointers are in order of priority, given by the priority which is one of the input parameters for the ISR installer. The lists are initialized with a length of zero upon boot-up, and each subsequently-installed ISR increases the length. The ISR deleter disables the interrupt associated with the referenced ISR, and removes the entry from the list, scooting the following ones up to fill in the gap. The ISRs themselves are very simple, leaving little to debug.
On the '02, I only do the Forth-language ISRs this way. The '02 was too inefficient to do the assembly-language ones this way. It added a lot of overhead, whereas the '816 was able to do it while adding very little overhead. The way I install and delete assembly-language ISRs on the '02 is less automatic and requires care in making sure that each one takes the responsibility of correctly chaining to the next if it finds that its interrupt source was not the one that caused the interrupt.
All of this might sound awfully complicated, especially since I said he ISR examples I see in books are usually way more complicated and inefficient than they need to be; but the complication is in the ISR installer and deleter (and you can also list the ISRs). The ISRs themselves are very simple, and I've never had to spend much time at all debugging them.
I know this doesn't have much to do with having lots of IRQ inputs, but it might give someone ideas for their system.
|
Fast - obviously it needs to be more efficient then simply polling each peripheral IC.
