3
\$\begingroup\$

I have doubt that micro controller will support multiple interrupt routines for a single timer.

For example, single timer which interrupts at 5ms, 10ms, 1s etc. In my design I am using 3 timers: one timer interrupts every 1ms for some status check, other two at 50ms and 1s.

I am curious to know about why can't I have controller which has more than one ISR and also, instead of interrupts at timer overflow, why can't it interrupt at its period match.

\$\endgroup\$
  • 4
    \$\begingroup\$ Please explain what it is you are trying to do, what you have tried and what your questions are. Right now I'm voting to close as this two sentence question demonstrates none of these things and shows a basic lack of respect for the people trying to help you. \$\endgroup\$ – akohlsmith Aug 12 '13 at 23:17
  • \$\begingroup\$ In my desgin i am using 3 timers in which one timer interrupts for every 1ms for some status check,other two at 50ms and 1s.I am curious to know about why cant i have controller which has more than ISR and also ,instead of interrupts at timer overflow,why cant it interrupt at its period match. \$\endgroup\$ – tamil_innov Aug 13 '13 at 10:10
  • \$\begingroup\$ Thank you for editing the question and filling in some more details. I have voted to reopen now and can provide an answer once it has been reopened. \$\endgroup\$ – akohlsmith Aug 13 '13 at 14:57
4
\$\begingroup\$

There may be some that have this capability, but most don't. You will need to maintain a count of cycles elapsed and delegate to the appropriate routine from there.

\$\endgroup\$
  • \$\begingroup\$ if possible could you name a few controller,so that i will check to its datasheet \$\endgroup\$ – tamil_innov Aug 12 '13 at 7:38
  • \$\begingroup\$ I have never come across any with this capability. \$\endgroup\$ – Ignacio Vazquez-Abrams Aug 12 '13 at 20:47
  • \$\begingroup\$ The Coldfire we use has a General Purpose Timer which has one "master" timer register that has multiple hardware compare/count interrupts hanging off it, which is sort-of the functionality you are looking for. However, I would just add a one-line mathematical check or static counter to your timer interrupt, allowing you to do some things every time the counter is a modulus of a given number. \$\endgroup\$ – John U Aug 13 '13 at 11:29
  • 1
    \$\begingroup\$ At least some MSP430 devices support multiple capture/compare registers within a single Timer block. For example, see the MSP430 Series 5 User Guide. Capture/compare register 0 generates one interrupt and the other capture/compare registers generate another interrupt. Within this other interrupt you can determine which capture/compare register initiated the interrupt and behave appropriately. With a single MSP430 Timer block you can generate multiple (up to seven) periodic interrupts with different frequencies. \$\endgroup\$ – kkrambo Oct 21 '13 at 12:41
  • 1
    \$\begingroup\$ @kkrambo: Different timings perhaps, but they all share the same frequency since the timer is for the most part free-running. \$\endgroup\$ – Ignacio Vazquez-Abrams Oct 21 '13 at 12:52
1
\$\begingroup\$

No, but there are plenty of microcontrollers with multiple timers, each run of which can throw interrupts at different intervals.

Of course, each timer will need its own interrupt routine. It doesn't seem like you would want to treat your 5ms interrupt the same as a 1s interrupt, but if you were dead set on that type of architecture, all the interrupt routines can have the same code in them. That, of course, would use up some extra program memory, even if you just have all the interrupts call the same subroutine.

\$\endgroup\$
1
\$\begingroup\$

I can only speak for AVR's but I know the one's I used only had 2-3 timers. But I don't see a need for using multiple timers. You can just use one where the timer's prescaler and compare value are configured where a compare match ISR is thrown at some known time interval (every 1ms for example). You can then keep track of the time and have a switch statement to control what action you want done.

\$\endgroup\$
  • \$\begingroup\$ What if you have a slow loop and a fast loop? What if you need to keep track of a timeout? What about using a timer for a software debounce? Those multiple timers haven't been put into the package because there was space left over. \$\endgroup\$ – Scott Seidman Aug 12 '13 at 22:52
  • 1
    \$\begingroup\$ I never said one timer was all that was needed for all the problems you have stated. Its seams that all the op is looking for is a way to have different procedures preformed based on time and this can be done with one timer. \$\endgroup\$ – Wallace Aug 12 '13 at 23:12
0
\$\begingroup\$

Timer ISR with variable period is fairly easy to achieve.

Variant 1. Timers usually have a countdown register, which can be updated by the code. The countdown initial value can be updated inside the ISR itself on a case by case basis. A state machine can be used to decide which initial value to assign to the counter.

Variant 2. Another option is to set up the timer for the shortest duration then count interrupts if you need longer duration. For example, you need to do 3 different things every 5ms, 10ms, 1s. Set the timer for 5ms, within the ISR increment a counter** every time ISR is called. In the main() loop, compare the counter to thresholds. For 10ms duration the threshold would be 2, for 1s the threshold would be 200. Once the counter is equal to the threshold, the main() does what needs to be done at that interval. A good thing about this approach is that you can have one timer and one ISR, but multiple thresholds (multiple counters too, if needed). The variable timing would be implemented in the code, rather than in the hardware timer.
Note that, this approach requires a main() loop, which always loops faster than the shortest interval. Accuracy of the timing should also be considered. If that becomes a problem, there are variations of this pattern, which can work with a slower main() loop.

** counter and flags are global variables visible to both ISR and main()

\$\endgroup\$
  • \$\begingroup\$ Unfortunately, many timers are very restricted as to the circumstances (if any) where their countdown registers may be written without adding considerable uncertainty to the resulting timings. A nicer design, if hardware supports it, is to use a counter which simply runs continuously and is never written to, along with a "compare" register. One may have to check after writing the compare register to ensure that the counter hasn't passed the desired value while one was writing (trigger the interrupt ASAP if that happens), but such an allows cleaner timing than countdown timers. \$\endgroup\$ – supercat Oct 18 '13 at 16:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.