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.
"Demons after money.
Whatever happened to the still beating heart of a virgin?
No one has any standards anymore." -- Giles
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.
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
© 2019 Microchip Technology Inc.