Difference between revisions of "GTIMER"

From uGFX Wiki
Jump to: navigation, search
Line 3: Line 3:
 
The reason why µGFX has it's own timer abstraction is because virtual timers provided by the most RTOS are interrupt context only. While great for what they are designed for, they make coding of the input drivers much more complex. For non-performance critical drivers like these input drivers, it would also hog an in-ordinate amount of critical (interrupt locked) system time. This contrary to the goals of a real-time operating system. So a user-land (thread based) timer mechanism is also required.
 
The reason why µGFX has it's own timer abstraction is because virtual timers provided by the most RTOS are interrupt context only. While great for what they are designed for, they make coding of the input drivers much more complex. For non-performance critical drivers like these input drivers, it would also hog an in-ordinate amount of critical (interrupt locked) system time. This contrary to the goals of a real-time operating system. So a user-land (thread based) timer mechanism is also required.
  
Even if GTimer is originally meant for internal use only, you can still use it yourself. This might become handy in some applications. To use the GTimer module, you first have to tell your [[gfxconf.h]] that you'd like to use GTimer:
+
Even if GTimer is originally meant for internal use only, you can still use it yourself. This might become handy in some applications.
 
+
<pre>#define GFX_USE_GTIMER TRUE</pre>
+
  
 
== API reference ==
 
== API reference ==

Revision as of 01:19, 3 July 2014

µGFX comes with it's own timer abstraction module. The GTimer module provides high level, simple and hardware independenz timers. The timers are meant to be used in different µGFX modules and are not very accurate.

The reason why µGFX has it's own timer abstraction is because virtual timers provided by the most RTOS are interrupt context only. While great for what they are designed for, they make coding of the input drivers much more complex. For non-performance critical drivers like these input drivers, it would also hog an in-ordinate amount of critical (interrupt locked) system time. This contrary to the goals of a real-time operating system. So a user-land (thread based) timer mechanism is also required.

Even if GTimer is originally meant for internal use only, you can still use it yourself. This might become handy in some applications.

API reference

The API reference of the GTIMER module can be found here.

Precision

GTimers are software timers and therefore their precision is totally unpredictable. The precision depends on how many threads and with which priority are currently running on the system. You can modify the GTimer thread priority and stack size in your gfxconf.h:

#define GTIMER_THREAD_PRIORITY			HIGH_PRIORITY
#define GTIMER_THREAD_WORKAREA_SIZE		1024

Example

The API reference of GTimer should explain how to use it. But here's a simple, self explanatory example of how GTimer can be used:

#include "gfx.h"
 
GTimer GT1, GT2;
 
void callback1(void* arg) {
    (void)arg;
 
    palTogglePad(GPIOD, GPIOD_LED3);
}
 
void callback2(void* arg) {
    (void)arg;
 
    palSetPad(GPIOD, GPIOD_LED4);
}
 
int main(void) { 
    /* initialize µGFX and the underlying system */
    gfxInit();
 
    /* initialize the timers */
    gtimerInit(&GT1);
    gtimerInit(&GT2);
 
    /* continious mode - callback1() called without any argument every 250ms */
    gtimerStart(&GT1, callback1, NULL, TRUE, 250);
 
    /* single shot mode - callback2() called without any argument once after 1s */
    gtimerStart(&GT2, callback2, NULL, FALSE, 1000);
 
    while(TRUE) {
        gfxSleepMilliseconds(500);
    }   
}

Troubleshooting

ToDo