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?!?
Posted by F1Andy: Sun. May 24, 2020 - 05:14 PM(Reply to #36)
1
2
3
4
5
Total votes: 0
danni wrote:
If you want a software interrupt, simple enable the SPM_RDY interrupt. During program execution this interrupt fires instantly, as it was enabled. Peter
Thank you! Top tip!
On PICs you can just set the interrupt flag on any unused interrupt. I was scratching my head trying to do the same on AVR...
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.
PIC32 based Ethernet Shield Arduino Uno hardware compatible
PIC32 based Ethernet Shield with Network Switch Arduino Uno hardware compatible
- 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
TopThank you! Top tip!
On PICs you can just set the interrupt flag on any unused interrupt. I was scratching my head trying to do the same on AVR...
Andy
____________________
Never trust a smiling cat.
- Log in or register to post comments
TopPages