Show Posts
1
µTasker general / Re: the timers created at task creation time do not send messages upon fire
« on: May 26, 2011, 10:54:44 PM »
Thanks for the confirmation!
Re: documentation,
In the file "uTaskerV1.3.pdf", on page 9, it says:
"
Each task in the system can have one mono-stable timer. This mono-stable timer is automatically allocated when the task is defined to start delayed, or to run periodically, since the ?Tasker uses this mono-stable timer to achieve this task. Should the task code want to make use of a mono-stable timer during normal operation it needs to ensure that the task receives the timer resources by defining a start delay or else by setting the delay value NO_DELAY_RESERVE_MONO (maximum possible value), which will cause the resource to be allocated without actually performing a delay.
The timer can then be used as a mono-stable timer, which is practical for most applications and especially for monitoring protocol timeouts. The timer can be started and restarted (retriggered) and stopped. Should it time out, it will cause the task to be woken with a timer event message to recognise the cause.
"
Since it does not explicitly say that no event message is sent when a "start delay" or "periodic" timer goes off, I felt that it implied there would always be a message.
The main reason to receive a message from a timer, is to allow a task to distinguish why it was allowed to run, IF there are multiple reasons. I agree that for many simple "periodic" tasks, there may be no need.
As it works now, you can still implement a periodic task that also receives messages. If your message queue was empty, you could assume that your periodic timer had fired. So, I don't see any big need to change the design.
Just for fun, I added the following lines into the uTaskerStart() function, to set an event code to associate with the timer:
#ifdef INITIAL_TIMERS_GENERATE_EVENT_MESSAGE // Rick's custom config option
tTimerList->ucEvent = -1;
#endif
This does cause a message to be sent. But, a problem with this idea is that the event code is normally a user-specified code, when a timer is explicitly created. A '-1' is not likely to be expected by any task... but you never know!
Thx!
-Rick
Re: documentation,
In the file "uTaskerV1.3.pdf", on page 9, it says:
"
Each task in the system can have one mono-stable timer. This mono-stable timer is automatically allocated when the task is defined to start delayed, or to run periodically, since the ?Tasker uses this mono-stable timer to achieve this task. Should the task code want to make use of a mono-stable timer during normal operation it needs to ensure that the task receives the timer resources by defining a start delay or else by setting the delay value NO_DELAY_RESERVE_MONO (maximum possible value), which will cause the resource to be allocated without actually performing a delay.
The timer can then be used as a mono-stable timer, which is practical for most applications and especially for monitoring protocol timeouts. The timer can be started and restarted (retriggered) and stopped. Should it time out, it will cause the task to be woken with a timer event message to recognise the cause.
"
Since it does not explicitly say that no event message is sent when a "start delay" or "periodic" timer goes off, I felt that it implied there would always be a message.
The main reason to receive a message from a timer, is to allow a task to distinguish why it was allowed to run, IF there are multiple reasons. I agree that for many simple "periodic" tasks, there may be no need.
As it works now, you can still implement a periodic task that also receives messages. If your message queue was empty, you could assume that your periodic timer had fired. So, I don't see any big need to change the design.
Just for fun, I added the following lines into the uTaskerStart() function, to set an event code to associate with the timer:
#ifdef INITIAL_TIMERS_GENERATE_EVENT_MESSAGE // Rick's custom config option
tTimerList->ucEvent = -1;
#endif
This does cause a message to be sent. But, a problem with this idea is that the event code is normally a user-specified code, when a timer is explicitly created. A '-1' is not likely to be expected by any task... but you never know!
Thx!
-Rick