| ??? 06/18/03 03:48 Read: times |
#48657 - RE: It\\\'s Manual-Reading Time! Responding to: ???'s previous message |
Hey guys:
I have to beg to differ on the flat recommendation that subroutines not be called from within an interrupt service routine. I do it all the time. Here is the list of considerations of the most importance for consideration. 1) Design software carefully. The critical part is that you not spend more time in the interrupt context than your software design can afford. You must consider the rate that the interrupt occurs, what other interrupts can happen at the same time and the amount of latency that any interrupt can afford in getting around to getting itself processed. 2) Use the very excellent 8051 two level priority interrupt structure to advantage in your design. It is possible to have interrupts of higher priority take over execution of a lower priority interrupt that is already in process. 3) In any system with two execution contexts, which I will call the mainline (normal thread) and the interrupt context (interrupt thread) it is important to always remember that the time spent in the interrupt thread plus the time in the mainline can never exceed 100% of the processor compute bandwidth. Sounds so obvious saying that here BUT I have encountered programmers that think somehow interrupts generate time and give you over 100% processor bandwidth. Those points said I can add that I have designed some pretty complex systems using microcontroller applications where the processor spent a significant percentage of its time in the interrupt context. There is even one whole group of medical products I have done for one client where the processor spends nearly 80% of its time in an interrupt context. When a timer interrupt occurs the processor does some work, disables all other interrupts, re-enables the timer interrupt and goes into a sleep wait for a second timer interrupt which has its stack context on top of the first interrupt. The processing on this second level interrupt is complex and uses as much as 40-50% bandwidth. And it executes these interrupt pairs as much as 1000 times per second! The scheme is one that permits the software to generate very fancy timing sequences on multiple port pins under software control without any jitter or frequency variation on any of the outputs relative to itself or any of the other timing controlled pins. So I just wanted to point out that when you are new to this stuff the recommendations about keeping interrupt routines short with no subroutine calls may be good advice. But by the time you get your feet wet and you are chest deep in the salt water, then that advice can be considered all hogwash provided you understand how to design and time budget a software execution flow. Michael Karas |
| Topic | Author | Date |
| Keil and recursive warning | 01/01/70 00:00 | |
| RE: Keil and recursive warning | 01/01/70 00:00 | |
| RE: Keil and recursive warning | 01/01/70 00:00 | |
| RE: Keil and recursive warning | 01/01/70 00:00 | |
| RE: Keil and recursive warning | 01/01/70 00:00 | |
| It\'s Manual-Reading Time! | 01/01/70 00:00 | |
| RE: It\\\'s Manual-Reading Time! | 01/01/70 00:00 | |
| RE: It\\\'s Manual-Reading Time! | 01/01/70 00:00 | |
| RE: It\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\'s Manual-Rea | 01/01/70 00:00 | |
| RE: It\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\'s Manual-Rea | 01/01/70 00:00 | |
RE: It\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ | 01/01/70 00:00 |



