{"id":701,"date":"2012-09-10T01:00:00","date_gmt":"2012-09-09T23:00:00","guid":{"rendered":"https:\/\/www.fussylogic.co.uk\/blog\/?p=701"},"modified":"2012-10-08T17:53:01","modified_gmt":"2012-10-08T16:53:01","slug":"cpu-interrupted-timers-ii","status":"publish","type":"post","link":"https:\/\/www.fussylogic.co.uk\/blog\/?p=701","title":{"rendered":"CPU, Interrupted — Timers II"},"content":{"rendered":"

When last we spoke on this subject<\/a> I had left you with a time-accurate but impractical timer interrupt handler.<\/p>\n

#define F_CPU 16000000<\/span>\n\nuint8_t<\/span> Timer_ms = 0<\/span>;\n\nstatic<\/span> void<\/span> initTIMER1( void<\/span> )\n{\n    \/\/ CTC mode (WGM1[3:0] = 0x04)<\/span>\n    TCCR1A = 0<\/span>;\n    TCCR1B = _BV(WGM12);\n    \/\/ CLK\/8 prescaler (see datasheet for table)<\/span>\n    TCCR1B |= _BV(CS11);\n\n    \/\/ Automatic comparison register (16Mhz\/8) is a 2 MHz tick, i.e. two<\/span>\n    \/\/ million ticks per second, or two thousand ticks per millisecond.<\/span>\n    \/\/ Note that on AVR we get one more tick than the value we put in<\/span>\n    \/\/ this register<\/span>\n    OCR1A = (F_CPU\/8<\/span>)\/1000<\/span> - 1<\/span>;\n\n    \/\/ Enable timer1 match-A interrupt<\/span>\n    TIMSK = _BV(OCIE1A);\n}\n\n\/\/ Note the change of vector here from "overflow" to "match"<\/span>\nISR(TIMER1_COMPA_vect)\n{\n    \/\/ 1 ms has passed<\/span>\n    Timer_ms++;\n\n    \/\/ TIFR.OCF1A is automatically cleared when the ISR is called, so we<\/span>\n    \/\/ needn't worry about the ISR being incorrectly retriggered<\/span>\n}<\/code><\/pre>\n
Why is this impractical though? Well let\u00e2\u20ac\u2122s look a little wider, what might we want to do with a timer in a main loop? Let\u00e2\u20ac\u2122s say something simple: flash an LED every quarter of a second. We want to know when the timer has changed, but we\u00e2\u20ac\u2122re only updating a counter in the ISR. We also have to be aware that Timer_ms<\/code> is altered by an interrupt context, so to prevent races we shouldn\u00e2\u20ac\u2122t carelessly access it in the main loop context.<\/p>\n
Let\u00e2\u20ac\u2122s look at the solution.<\/p>\n
static<\/span> uint8_t<\/span> interruptTicks = 0<\/span>;\n\nISR(TIMER1_COMPA_vect)\n{\n    interruptTicks++; \n}\n\nint<\/span> main( void<\/span> )\n{\n    uint8_t<\/span> localTicks = 0<\/span>;\n    unit16_t Timer_ms = 0<\/span>;\n    uint16_t<\/span> Timer_1s = 0<\/span>;\n    uint8_t<\/span> Alarm_ms = 0<\/span>;\n\n    initTimer1();\n\n    while<\/span>(1<\/span>) {\n        \/\/ Disable interrupts as a poor-man's atomic operation<\/span>\n        cli();\n        localTicks += interruptTicks;\n        interruptTicks = 0<\/span>;\n        \/\/ Disabling interrupts still leaves them pending<\/span>\n        sei();\n\n        \/\/ We could put the processor to low-power sleep here and wait<\/span>\n        \/\/ to be woken by the timer interrupt rather than busy-waiting<\/span>\n\n        \/\/ ----- Timer interrupt bottom half<\/span>\n\n        \/\/ We've now got a tick count we can use without worrying about<\/span>\n        \/\/ race conditions, localTicks is never accessed outside this<\/span>\n        \/\/ context<\/span>\n\n        if<\/span>( localTicks == 0<\/span> )\n            continue<\/span>;\n\n        \/\/ --- Timers tick upwards<\/span>\n        Timer_ms += localTicks;\n        if<\/span>( Timer_ms > 1000<\/span> ) {\n            Timer_ms -= 1000<\/span>;\n            if<\/span>( Timer_1s < 0xffff<\/span> )\n                Timer_1s++;\n        }\n\n        \/\/ --- Alarms tick downward<\/span>\n        if<\/span>( Alarm_ms < localTicks ) {\n            Alarm_ms = 0<\/span>;\n            \/\/ Call whatever alarm handler you want here<\/span>\n        } else<\/span> {\n            Alarm_ms -= localTicks;\n        }\n\n        \/\/ Everyone who needed to count ticks has counted them<\/span>\n        localTicks = 0<\/span>;\n    }\n\n    return<\/span>;\n}<\/code><\/pre>\n
You can see that you could add any number of timers, any number of alarms, and any cascade conditions you want between them. None of this is done in the ISR and can take up to 255 ms (an age in microcontroller land), without ever missing a single tick or creating a race condition. By using interrupts for our timer we\u00e2\u20ac\u2122ve also gained the ability to go to sleep and thus use much less power than we would if we were simply polling for an overflow.<\/p>\n
I haven\u00e2\u20ac\u2122t done it here as it would only obfuscate matters, but there is nothing to stop you writing a generic alarm structure that contains both the alarm time and a pointer to the function to call on timeout. Oh what the heck\u00e2\u20ac\u00a6<\/p>\n
struct<\/span> sAlarmStructure\n{\n    uint16_t<\/span> AlarmTime_ms;\n    void<\/span> (*timeoutCallback)(uint8_t<\/span>);\n    void<\/span> *opaque:\n} AlarmList[MAX_ALARMS];\n\nuint8_t<\/span> registerTimer( uint16_t<\/span> timeout, void<\/span> (*callback)(uint8_t<\/span>), void<\/span> *opaque )\n{\n    uint8_t<\/span> i;\n    for<\/span>( i = 0<\/span>; i < MAX_ALARMS; i++ ) {\n        \/\/ Timers <\/span>\n        if<\/span>( AlarmList[i].AlarmTime_ms == 0<\/span> ) {\n            AlarmList[i].AlarmTime_ms = timeout;\n            AlarmList[i].timeoutCallback = callback;\n            AlarmList[i].opaque = opaque;\n            return<\/span> i;\n        }\n    }\n    \/\/ No spare timer slots left<\/span>\n    return<\/span> -1<\/span>;\n}\n\nint<\/span> main( void<\/span> )\n{\n    uint8_t<\/span> localTicks = 0<\/span>;\n    uint8_t<\/span> i;\n\n    initTimer1();\n\n    while<\/span>(1<\/span>) {\n        \/\/ Disable interrupts as a poor-man's atomic operation<\/span>\n        cli();\n        localTicks += interruptTicks;\n        interruptTicks = 0<\/span>;\n        \/\/ Disabling interrupts still leaves them pending<\/span>\n        sei();\n\n        for<\/span>( i = 0<\/span>; i < MAX_ALARMS]; i++ ) {\n            if<\/span>( AlarmList[i].AlarmTime_ms > localTicks ) {\n                AlarmList[i].AlarmTime_ms -= localTicks;\n            } else<\/span> {\n                AlarmList[i].AlarmTime_ms = 0<\/span>;\n                \/\/ The callback function can restart itself if it wants<\/span>\n                \/\/ because we're handing it its own AlarmList index<\/span>\n                AlarmList[i].timeoutCallback(i);\n            }\n        }\n\n        \/\/ Rest of main loop can call registerTimer() when it needs to<\/span>\n        \/\/ defer a task<\/span>\n    }\n\n    return<\/span>;\n}<\/code><\/pre>\n
So we\u00e2\u20ac\u2122ve gone from not being able to rely on the exact number of counts between events to a generic, run-time configurable alarm system. We\u00e2\u20ac\u2122ve got a fast ISR and no race condition.<\/p>\n","protected":false},"excerpt":{"rendered":"
When last we spoke on this subject I had left you with a time-accurate but impractical timer interrupt handler. #define F_CPU 16000000 uint8_t Timer_ms = 0; static void initTIMER1( void ) { \/\/ CTC mode (WGM1[3:0] = 0x04) TCCR1A = 0; TCCR1B = _BV(WGM12); \/\/ CLK\/8 prescaler (see datasheet for table) TCCR1B |= _BV(CS11); \/\/\u2026 Read More »<\/a><\/span><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[1],"tags":[39,37,41,38,42,6,40],"_links":{"self":[{"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=\/wp\/v2\/posts\/701"}],"collection":[{"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=701"}],"version-history":[{"count":8,"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=\/wp\/v2\/posts\/701\/revisions"}],"predecessor-version":[{"id":813,"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=\/wp\/v2\/posts\/701\/revisions\/813"}],"wp:attachment":[{"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=701"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=701"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=701"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}