Page 1 of 3
High-Resolution Timer proposal
Posted: Fri Sep 14, 2012 6:13 am
by skute
Greetings,
I would like to present for review a high-resolution timer implementation; based on a modified gpt driver (though with this driver, the gpt driver is somewhat superfluous). The driver is fairly naive in that it simply keeps a list of timers that are running and configures the hardware to interrupt at the next shortest time. The timer interval currently has micro-second resolution (though about 5us of overhead has been measured). The code has been tested and seems to be in a state that I feel appropriate to release this as a beta. Please discuss.
Example of configuration/use:
// Toggle the led every 500 ms
Code: Select all
void
testTimerCallback (volatile hrtimer_t *pTimer,
volatile void *data)
{
static int cnt = 0;
if (cnt & 0x01) {
palSetPad(GPIOF, GPIOF_LED1);
}
else {
palClearPad(GPIOF, GPIOF_LED1);
}
cnt += 1;
}
main() {
...
volatile hrtimer_t testTimer;
hrTimerInit(&testTimer, HRT_TYPE_PERIODIC, 500000, testTimerCallback, NULL);
hrTimerStart(&testTimer);
...
}
This will sleep a thread and blink the led every second
Code: Select all
thread() {
int cnt = 0;
while(1) {
hrTimerSleep(1000000);
if (cnt & 0x01) {
palSetPad(GPIOF, GPIOF_LED2);
}
else {
palClearPad(GPIOF, GPIOF_LED2);
}
cnt += 1;
}
}
A bunch of files were modified and the current target is the STM32. Most files are added where you would expect them, and the list.h file I added to /os/various. I believe I have all the required files attached, please let me know if I don't, or it doesn't build correctly.
https://www.dropbox.com/s/wvhscpahiqqrlrb/hrt.zip
Re: High-Resolution Timer proposal
Posted: Fri Sep 14, 2012 6:14 am
by skute
found the upload attachment location!
Re: High-Resolution Timer proposal
Posted: Fri Sep 14, 2012 7:03 am
by mabl
Hello Skute,
nice project - I kept thinking of doing something equivalent - now you have done it for me
Some notes (don't take them to seriously):
- I'm not sure you will need the volatile keyword everywhere.
- It's a nice idea to add a list helper. But maybe we should not directly copy code from the Linux Kernel? Is there any other code not written by you inside of it?
- I'm not sure how well it scales. Maybe it could be avoided to traverse all registered timers in adjustTimeRemainingI?
- Context. adjustTimeRemainingI is called from different locations in the code. So callbacks to hrtimers will also originate not only from the interrupt context, won't they?
Re: High-Resolution Timer proposal
Posted: Fri Sep 14, 2012 7:45 am
by skute
Hi Mabl,
To answer some of your questions:
1) The use of volatile in the API was to ensure that the hrtimer_t structures were typed volatile to ensure they were instantiated as volatile. This caused me to either add volatile to all the other functions or cast everywhere to avoid the warning. Another solution would be for the typedef for hrtimer_t to include the volatile. But essentially you are correct, it is not needed everywhere as it is protected with the lock/unlock.
2) I used the list helper from linux since it was familiar and simple (though I don't recall where this version came from, as it has been modified from the standard linux version). It could easily be ported to bsd sys/queue.h (
http://freebsd.active-venture.com/FreeB ... eue.h.html) or even
http://uthash.sourceforge.net/utlist.html. All other code is my own.
3) You will always have to traverse all the timers at some point (either inserting into a sorted list or when completing). I made an assumption that in an embedded system, there would likely be fewer than 10 concurrent timers actually running so the overhead is probably not that significant.
4) The places where adustTimeRemainingI is called from other than the interrupt context won't ever have any timers expiring. In these instances, it is simply being used to choose the 'next to expire'. So, all callbacks will be in an interrupt context.
Re: High-Resolution Timer proposal
Posted: Fri Sep 14, 2012 11:05 am
by Giovanni
The point raised by Mabl is important.
Copying code from a GPL project, no matter how much it is modified, prevents re-licensing and even the simple addition of the "exception" would be impossible. Code derived from GPL code can only be licensed under GPL unless all the copyright owners agree to change license.
Giovanni
Re: High-Resolution Timer proposal
Posted: Fri Sep 14, 2012 2:29 pm
by skute
Hi Giovanni,
I agree 100%. I will change the list manipulation routines to one of the BSD/MIT licensed versions.
Re: High-Resolution Timer proposal
Posted: Sat Sep 15, 2012 8:37 pm
by skute
Hello,
I have updated the driver to use the BSD queue.h instead of the linux list.h. I hope this resolves any licensing issues; if not, please let me know which licensing scheme is compatible with chibios.
Re: High-Resolution Timer proposal
Posted: Sun Sep 16, 2012 10:31 am
by Giovanni
Hi,
I will go through the code next week, I have some suggestions to do.
Giovanni
Re: High-Resolution Timer proposal
Posted: Sun Sep 16, 2012 6:37 pm
by skute
Excellent. I hope this will be of some use for people. I'm more than happy to change/re-architect the driver with a better solution; so feel free to share your idea's and thoughts.
I have attached another version of the driver which fixes the abuse of volatile.
Re: High-Resolution Timer proposal
Posted: Sun Sep 16, 2012 7:37 pm
by Giovanni
Most likely I'll have style-related complaints
The thing that I already don't like is to have to modify the GPT, that would impact a lot of platforms. Probably it would be better to make the driver have its own low level layer. Encapsulating everything in two files would be good too.
Giovanni