Jake 24 Posted December 24, 2015 Author Share Posted December 24, 2015 On the interrupts I have been told the same thing to keep them short, but instead of constantly polling I figured the interrupt would be better. Also this timing function is the most important function in the scheme of things, I want it to drop what ever else it was doing and go to this function. Everything else is able to wait while this evolution is taking place. Now I'll see if I can get my other pieces of the puzzle done!! Sent from my XT1254 using Tapatalk Quote Link to post Share on other sites
igor 163 Posted December 24, 2015 Share Posted December 24, 2015 Thanks for the clear example. I have a general question - we are often admonished to make interrupts as short as possible. myTimerISR above is somewhat long but obviously works. Do you have any rules of thumb about how long is too long? The main thing to be kept short in an ISR is execution time. Even the longest execution path in this ISR isn't long. 3-4 compares, a similar number of assignments, maybe a computed jump. Doesn't even have any procedure calls or loops. greeeg and Fmilburn 2 Quote Link to post Share on other sites
greeeg 460 Posted December 26, 2015 Share Posted December 26, 2015 @@Fmilburn Yes ISR's should be kept short. But as @@igor has already pointed out it's to do with execution time, not necessarily number of lines. The main things to avoid are function calls, blocking functions (delay_ms()!!? (some people do do this....)), or potentially large or unbounded loops. The idea behind the state machine is that you can change the behavior of the timer interrupt, (waiting for the button to be held down, or waiting with the LED on.) and it really doesn't take that much execution time at all. Better yet, you can easily determine the worst and average execution time, which can be required in a more complex system. The best part is that it is simple, functional, and extendable. Do you have any rules of thumb about how long is too long? This really depends on the specific application. If you're system is dealing with an audio codec, and you are required to send it a block of data to decode, then missing that deadline will result in gaps or artifacts in the audio. But if you just need to blink a LED to a user, then they won't notice the difference if it's delayed by 5mS or so. Fmilburn 1 Quote Link to post Share on other sites
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.