Timer
Re:Timer
I have not done this yet, but have put a little thought into it. Basically my sceduler will handle it, and have a list of timers event it must fire. The sceduler resets the counter incremented by the isr (and thus knows how many clock ticks since it last checked the event list) and with a few more variables it can maintain enough state to service all timers.
_mark()
_mark()
- Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:Timer
it basically depend on how fast you require the timer interrupt to go ... At 1KHz, (1000 interrupts / second), you're still able to handle about 4 000 000 seconds with a unsigned int (provided that you're in 32 bits mode -- this is still something like 42 days... pretty large for a timer don't you think ?
If longer distance are required, its unlikely that you'll need the same precision ... but if you really do, you still may make your timer an unsinged long long, which is 64 bits.
If you're in assembler, you can easily handle this with ADC instruction.
Now, what is more likely to be useful is to keep 32bits counters, but to have several of them like the "ticks count" which really count the amount of IRQ0 fired since the system is up, and which may loop pretty often depending of the precision required. Then, you can divide this count to have -say - the amount of milliseconds ellapsed. This is an interresting measurement for schedulers, operation timeouts, etc.
Once again, every 1000 milliseconds you can also increment your "uptime_in_seconds" and the "time_of_day" counters.
External programs that will access those dates are unlikely to require the realtime in microseconds. If necessary, you can build up a "time" structure using time_of_day for day .. seconds and fill the "sub-second" fields with milliseconds%1000 ...
Hope this helps ...
If longer distance are required, its unlikely that you'll need the same precision ... but if you really do, you still may make your timer an unsinged long long, which is 64 bits.
If you're in assembler, you can easily handle this with ADC instruction.
Now, what is more likely to be useful is to keep 32bits counters, but to have several of them like the "ticks count" which really count the amount of IRQ0 fired since the system is up, and which may loop pretty often depending of the precision required. Then, you can divide this count to have -say - the amount of milliseconds ellapsed. This is an interresting measurement for schedulers, operation timeouts, etc.
Once again, every 1000 milliseconds you can also increment your "uptime_in_seconds" and the "time_of_day" counters.
External programs that will access those dates are unlikely to require the realtime in microseconds. If necessary, you can build up a "time" structure using time_of_day for day .. seconds and fill the "sub-second" fields with milliseconds%1000 ...
Hope this helps ...