>That all assumes you have turned interrupts off for some reason. Common >reasons could be that you are in another interrupt service routine or that >you are executing interrupt related code. > >Bob
What I saw in their interrupt routine was a "full boat" implementation, pretty typical for C code, saving registers without regard for what happens in the ISR, but nothing about the interrupts being turned off. If you mean not having re-enabled ints during the ISR, then yes, and that is how I would urge anyone to write an ISR. The reason that you would re-enable ints during an ISR is that your ISR takes too long. Making the ISR take even longer isn't really a solution. Write faster ISRs. The key is to do absolutely as little housekeeping as needed, and have the ISR do as little as possible. I have had cases where I didn't even preserve SREG because what I was doing in the ISR didn't alter SREG. Don't blame the hardware for poor implementation of software. There really is no actual minimum code in an ISR. In one case, I had a useful ISR that had actually no code in it!. A very special case, but they happen. What I showed is my typical intro and outro code for probably 90% of what I write. I avoid pushing and popping because it wastes time. Copying SREG into a dedicated register is faster. Using dedicated ISR registers is faster than pushing and popping to free up registers. All this pushing and popping causes deep stack usage, which isn't even an option on some processors. When your stack collides with your data, you're toast. It is to your significant advantage to minimize stack usage. I will typically put a stack guard below where I expect the stack to live, and monitor that in the "sanity check" routine for any changes. The sanity check routine looks at this and other things that I know should never change, and if they are not the correct values, then the watchdog won't be reset. The sanity check routine is also the only place that the watchdog gets reset. WDRs scattered through the code are symptomatic of poorly written code. _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
