My reading of it was that he was trying to create something like top-halfs/bottom-halfs in Linux or ISR/HISR in Nucleus. That is split the ISR work into the core, interrupt protected handler that then triggers and interruptible second level handler. Just usin a static inline block it would still be within the interrupt disabled context of the original, core handler.
But just like re-enabling interrupts in the core handler itself if you have a core that hands off to a soft handler that is then interrupted by another instance of the core handler then where does that leave you exactly - you are re-entering the soft handler before the last instance had completed.
The whole thing seems like a can of worms to me. I'd just have the core handler set a flag to say that "high level service is required" then have that actioned off the flag in the main() loop as soon as it can.
You can easily run out of ram with nested interrupts. You have been warned! The general solution is to use a RTOS.
First thing in the slow ISR you disable the slow interrupt (INT0 for example) and then enable interrupts (SEI). When done, disable interrupts (CLI), enable back the slow ISR (INT0) and RET will enable them back. This way the slow interrupt can't call itself.
For an already tight application, the last thing I would think of is adding a RTOS.
For the case cndgavruser described, I would split that slow screen IO function in two, three or as much as needed and in between poll a bit that the fast IRS sets when a full frame is in the receiving buffer. I would make sure the buffer is large enough to hold few frames. While in this case it may work, I think that there are cases where a software interrupt would be appropriate.
In the days of DOS and 80386 software I once wrote an application that was very slow on screen update, especially when zooming or panning over all the graphical data.
There was a logical place in the screen update procedure which my code visided a few hundred times for a complete screen refhesh.
At that place I inserted a little check, to simply return from the whole screen update procedure, if a mouse button was clicked, and that would result in a nother screen refhesh.
The result was excellent.
I had only partial refreshes during zooming and scrolling, but it was fast and responsive.
As soon as the mouse stopped giving input, the screen refresh completed a full redraw.
No need for a RTOS or other complicated solution, just a well placed check and a return in the right place.
Posted by trherrmann: Wed. Nov 13, 2019 - 02:27 AM
1
2
3
4
5
Total votes: 0
My use for a software interrupt is as follows. I am using a light sensor to raise/lower a window blind. INT0 is set to interrupt upon a state change from a 555 configured as a Schmidt trigger watching the output of a photoresistor/resistor voltage divider. The interrupt routine checks to see whether the state is light or dark, since a change to either will trigger the interrupt. BUT upon power-up, the window blind just stays where it is, since there is no state change on the INT0 pin. So I need a one-time software interrupt, triggered upon power-up, so put the blind in its proper position. Tom
Posted by avrcandies: Wed. Nov 13, 2019 - 05:01 AM
1
2
3
4
5
Total votes: 0
Gotta be kidding? Why would anyone need an interrupt to detect a window blind?....that is about the slowest moving object. We could probably poll it about a 50 million times as it creeps along. The AVR could check it every 20ms & never miss anything. Interrupts are usually used for something that is needing an extremely fast, microseconds, reaction. Are you concerned the blinds may be lowered for an extra 6 microseconds?
Also why would a 555 be needed? The AVR can almost certainly handle the task--use an ADC input to monitor the light detector.
When in the dark remember-the future looks brighter than ever. I look forward to being able to predict the future!
So I need a one-time software interrupt, triggered upon power-up, so put the blind in its proper position.
Surely you just take the contents of the ISR(), put it in a function. Call the function from the ISR but also call the function once at first time power on initialisation.
To be honest I have yet to see any reason why an AVR needs "software interrupts". You might as well just CALL the code at the point where you would be triggering the software interrupt?!?
All a "software interrupt" will get you is to bypass the caller-side overhead.
It will get you the ISR overhead.
Some registers will be saved and restored by both ISRs.
Replacing the software interrupt's ISR with an ordinary
static inline function might get you the best of all worlds.
If said function is called more than once, code-bloat is likely.
Note that an ordinary call from an ISR to another ISR
could result in the same register being saved and restored three times:
once each by the ISR epilogues and prologues,
and again by the function call mechanism.
To make the call, I'd use a line or two of inline assembly.
Iluvatar is the better part of Valar.
- Log in or register to post comments
TopMy reading of it was that he was trying to create something like top-halfs/bottom-halfs in Linux or ISR/HISR in Nucleus. That is split the ISR work into the core, interrupt protected handler that then triggers and interruptible second level handler. Just usin a static inline block it would still be within the interrupt disabled context of the original, core handler.
But just like re-enabling interrupts in the core handler itself if you have a core that hands off to a soft handler that is then interrupted by another instance of the core handler then where does that leave you exactly - you are re-entering the soft handler before the last instance had completed.
The whole thing seems like a can of worms to me. I'd just have the core handler set a flag to say that "high level service is required" then have that actioned off the flag in the main() loop as soon as it can.
- Log in or register to post comments
TopFirst thing in the slow ISR you disable the slow interrupt (INT0 for example) and then enable interrupts (SEI). When done, disable interrupts (CLI), enable back the slow ISR (INT0) and RET will enable them back. This way the slow interrupt can't call itself.
For an already tight application, the last thing I would think of is adding a RTOS.
For the case cndgavruser described, I would split that slow screen IO function in two, three or as much as needed and in between poll a bit that the fast IRS sets when a full frame is in the receiving buffer. I would make sure the buffer is large enough to hold few frames. While in this case it may work, I think that there are cases where a software interrupt would be appropriate.
- Log in or register to post comments
TopIn the days of DOS and 80386 software I once wrote an application that was very slow on screen update, especially when zooming or panning over all the graphical data.
There was a logical place in the screen update procedure which my code visided a few hundred times for a complete screen refhesh.
At that place I inserted a little check, to simply return from the whole screen update procedure, if a mouse button was clicked, and that would result in a nother screen refhesh.
The result was excellent.
I had only partial refreshes during zooming and scrolling, but it was fast and responsive.
As soon as the mouse stopped giving input, the screen refresh completed a full redraw.
No need for a RTOS or other complicated solution, just a well placed check and a return in the right place.
Doing magic with a USD 7 Logic Analyser: https://www.avrfreaks.net/comment/2421756#comment-2421756
Bunch of old projects with AVR's: http://www.hoevendesign.com
- Log in or register to post comments
TopMy use for a software interrupt is as follows. I am using a light sensor to raise/lower a window blind. INT0 is set to interrupt upon a state change from a 555 configured as a Schmidt trigger watching the output of a photoresistor/resistor voltage divider. The interrupt routine checks to see whether the state is light or dark, since a change to either will trigger the interrupt. BUT upon power-up, the window blind just stays where it is, since there is no state change on the INT0 pin. So I need a one-time software interrupt, triggered upon power-up, so put the blind in its proper position. Tom
- Log in or register to post comments
TopGotta be kidding? Why would anyone need an interrupt to detect a window blind?....that is about the slowest moving object. We could probably poll it about a 50 million times as it creeps along. The AVR could check it every 20ms & never miss anything. Interrupts are usually used for something that is needing an extremely fast, microseconds, reaction. Are you concerned the blinds may be lowered for an extra 6 microseconds?
Also why would a 555 be needed? The AVR can almost certainly handle the task--use an ADC input to monitor the light detector.
When in the dark remember-the future looks brighter than ever. I look forward to being able to predict the future!
- Log in or register to post comments
TopTo be honest I have yet to see any reason why an AVR needs "software interrupts". You might as well just CALL the code at the point where you would be triggering the software interrupt?!?
- Log in or register to post comments
TopPages