Hello,
Can anybody explain me what is Interrupt Sharing and how is it used in emebbed system?
Printable View
Hello,
Can anybody explain me what is Interrupt Sharing and how is it used in emebbed system?
Try this link
1st page on a google search...What it discusses concerns embedded devices as well.
Check out interrupts relating to the target OS or the target processor as well.
Interrupt sharing is just when two or more peripherals share the same interrupt pin. For instance, on the embedded board I am currently working on, there are 9 general purpose interrupts that can be used. Since I need more than 9 interrupts, I have multiple devices sharing the same interrupts.
When you have peripherals using the same interrupt, it is up to the programmer to figure out which device sent the interrupt since they all share the same ISR. This is usually done via memory mapped registers that you can check to see if a particular device fired an interrupt.
Bithub,
That is really good answer. Now I would like to take this further.
1. What happens, when these two devices fire interrupt at same time?
2. If there is no proirity settting done by hardwar, How would programmer need to proritize one device over other?
3. When ISR is entered, other interrupts are masked. Meaning even if some device fires interrupt, it will not be reconized. Say for sake of simplicity controller does not have capability to keep it pending. In that case, I will miss that inteerupt. To avoid this, can we stop disabling interrupt other interrupts in ISR? Again, if we do not disable te interrupt and newinterrutpt of higer priority comes while you are in ISR and you need to handle the new interupt how would you handle such scenario?
4. Then, I will argue that you should/must disable the interrupt while you are in ISR? If that is the case won't you miss some interrupts? Or other device will starve? Then your system won't be real time.
5. Then I will say, I will come out of the ISR immediately by queing up the actual task, which will be done later? So that other oteher device will not starve.
6. With # 5, we just increased chance of not dropping the interrupt, but what if interrupt comes right after ISR is entered. How soon can you re-enable the interrupt?
I am talking both the scenario on myself. It is kind of debate.
Please share your thoughts...
#3. I don't think its possible for the controller to not be able to keep the int pending. It should use a register or shared memory containing the int flags. The interrupt handler reads the location with the interrupt flag(s) and can then reset it. Any new interrupts that are generated will be written by the controller. If this isn't the case then how exactly is the sw interrupt handler able to discover the actual interrupt that was generated? And this leads to my answer for #5 & 6 about handling an interrupt generated while in the ISR.
#5 & #6
One method I have seen is to re-check the interrupt in the ISR. Essentially a loop that keeps queuing tasks if the interrupt is being set while in the ISR.
And queueing a task in the ISR is the optimal way to handle it. Your ISR should do as little work as possible. By doing so and having interrupts disabled for the shortest possible time, your system will be as reactive as possible. And typically, the interrupts won't be disabled unless there is a good reason.
As for the first few questions, I don't have enough experience with that so I'm curious about Bithubs answers.
1. What happens, when these two devices fire interrupt at same time?
Since these two devices are sharing the same interrupt (I am assuming they are sharing since your initial question was based on that), you would check the status registers of these peripherals to see which one fired the interrupt in your ISR. Since the devices fired at the same time, the status registers would indicate that both devices are ready to be serviced, and thus you would handle this accordingly in your ISR.
2. If there is no proirity settting done by hardwar, How would programmer need to proritize one device over other?
I've never seen a situation where you could prioritize one device over another. You can prioritize one interrupt over another though. If you had two devices sharing the same interrupt and you wanted one to have priority, then you could designate this by only serving one of the devices in your ISR (or serving the one with priority first).
3. When ISR is entered, other interrupts are masked. Meaning even if some device fires interrupt, it will not be reconized. Say for sake of simplicity controller does not have capability to keep it pending. In that case, I will miss that inteerupt. To avoid this, can we stop disabling interrupt other interrupts in ISR? Again, if we do not disable te interrupt and newinterrutpt of higer priority comes while you are in ISR and you need to handle the new interupt how would you handle such scenario?
In the case you mentioned above, yes you would miss the interrupt. Keep in mind that most controllers do not work this way though. If you are in an ISR, and another interrupt of higher priority fires, then there is nothing that you as a programmer needs to do. The controller will automatically switch execution to the higher priority ISR. When the high priority one is finished, then execution will continue in your original ISR.
4. Then, I will argue that you should/must disable the interrupt while you are in ISR? If that is the case won't you miss some interrupts? Or other device will starve? Then your system won't be real time.
This depends on what sort of functionality you want. I'll illustrate this with an example. Let's say you have a set of buttons which all are tied to the same interrupt. Now when you press a button, some sort of processing occurs which takes 3 seconds. Let's say the user pressed a button, and then 1 second later presses another button. Here you have two choices. One choice is to ignore the second button press (nested interrupts disabled). The second choice is to stop processing the first button press, and start processing the second button press (nested interrupts are enabled). There are cases where either of those situations would be desirable which is why the interrupt controller allows you to enable or disable nested interrupts.
5. Then I will say, I will come out of the ISR immediately by queing up the actual task, which will be done later? So that other oteher device will not starve.
That's one way of doing it. Keep in mind that there are times where you would like a device to starve though. This just depends on what the device is, and what sort of functionality that you (the programmer) wants.
6. With # 5, we just increased chance of not dropping the interrupt, but what if interrupt comes right after ISR is entered. How soon can you re-enable the interrupt?
That depends on the board itself. On my board it would take 3 instructions to re-enable the interrupt. The actual time would depend on quite a few things though.
Thanks for your comments. I hardly find such kind of information in books. Do you know, which books talk about this?
I also want to talk about DMA and image downloading by opening next thread. But any books or pointers that talks about this is appreciated.
3. When ISR is entered, other interrupts are masked. Meaning even if some device fires interrupt, it will not be reconized. Say for sake of
simplicity controller does not have capability to keep it pending. In that case, I will miss that inteerupt. To avoid this, can we stop disabling interrupt other interrupts in ISR? Again, if we do not disable te interrupt and newinterrutpt of higer priority comes while you are in ISR and you need to handle the new interupt how would you handle such scenario?
In the case you mentioned above, yes you would miss the interrupt. Keep in mind that most controllers do not work this way though. If you are in an ISR, and another interrupt of higher priority fires, then there is nothing that you as a programmer needs to do. The controller will automatically switch execution to the higher priority ISR. When the high priority one is finished, then execution will continue in your original ISR.
I heard some RTOS does not provide stack to the ISR as they are overhead to the system. All the register are pushed before triggering ISR. In that case, how the nesting of ISRs is handled?
5. Then I will say, I will come out of the ISR immediately by queing up the actual task, which will be done later? So that other oteher device will not starve.
That's one way of doing it. Keep in mind that there are times where you would like a device to starve though. This just depends on what the device is, and what sort of functionality that you (the programmer) wants.
6. With # 5, we just increased chance of not dropping the interrupt, but what if interrupt comes right after ISR is entered. How soon can you re-enable the interrupt?
That depends on the board itself. On my board it would take 3 instructions to re-enable the interrupt. The actual time would depend on quite a few things though.
Thanks for giving example, I want ask new question by explaing following example. Say we have physical layer driver, the PHY will grab the packet from outside world, and keep it in its buffer and fire the interrupt. The driver needs to copy to another chunk of memory as such memory may be expensive and chance of getting overwritten by another packet. Now, ISR will queue up the process of copying up the data. So the ISRs job is to queue up the process, that's it. Now let us start with origin of the this thread, 'interrupt sharing', this interrupt is shared by devices, what are these instruction that are must in order to re-enable the interrupts? ( I do not expect to share your code but concept what you tried to do?) And also, How do I stop physical layer by overwriting this memory until driver(queued task) reads this memory.
Sorry for asking series of question in same response. But also want to know as some are related to this, how this works, as some OS maps the buffer in its memory map? How this helps design?
PLease let me know....
Not specifically. I've gotten most of my knowledge on the subject from hardware reference manuals. That's not to say a good google search wont turn up something promising though.Quote:
Do you know, which books talk about this?
That's interesting. I've never worked on a system that didn't give a stack to the ISR (or at least allow the ISR to request stack space). I would guess that in this sort of situation, nesting interrupts would be tricky if not impossible.Quote:
I heard some RTOS does not provide stack to the ISR as they are overhead to the system. All the register are pushed before triggering ISR. In that case, how the nesting of ISRs is handled?
Once again this depends on hardware implementation. For the most part though, this just involves clearing (or setting) a memory mapped register to indicate that that the particular interrupt has been serviced.Quote:
what are these instruction that are must in order to re-enable the interrupts?
The tricky side to working with embedded systems is that there is no standard as there is with programming on an operating system like unix or windows. The first thing I always do when working with a new microprocessor or board, is to read the hardware reference manual cover to cover. This is where you learn the capabilites of the interrupts, built in peripherals, processor, and memory. One thing that I've found helpful in the past is to try and find a forum specific to the particular hardware you are working on. For instance, I've found a forum for the ADSP-533 processor that I am currently working on, and I've found it to be quite helpful.
Say If I invoke malloc in ISR, then it has to be synchronized as many tasks call this function. Now, you invoked malloc in ISR and some other task has already acquired malloc. Now, ISR has to wait till it get signalled.PHP Code:That's interesting. I've never worked on a system that didn't give a stack to the ISR (or at least allow the ISR to request stack space).
Now we have to think, how waiting is implemented. Each task will have context. Waiting for event to be signalled is implement as queue of context. Whenever malloc is released it picks up next context task from its queue and starts allocating memory for that task.
If context switch happens, entire context is saved on stack and new task's stack is activated.
Since ISRs does not have stack it does not have place to store context and so to queue up the waiting object.
Also ISRs are scheduled asynchronously and nothing is passed and returned, it does not need stack.
That's the reason, why many OS will not provide stack to ISRs.