Hi Aaron
Consider the following:
1) A task that is configured with timer resources, an input queue and a start-up delay of 1s
2) As long as no other task sends a message to this task, or changes the task's state before its start-up delay has expired, it will run for the first time after 1s
extern void fnTask(TTASKTABLE *ptrTaskTable)
{
...
if (iState != STATE_READY) {
iState = STATE_READY;
uTaskerMonoTimer( OWN_TASK, (DELAY_LIMIT)(1*SEC), POLL_TERMINATE );
uTaskerStateChange( OWN_TASK, UTASKER_GO );
}
while ( fnRead( PortIDInternal, ucInputMessage, HEADER_LENGTH )) { // check input queue
switch ( ucInputMessage[ MSG_SOURCE_TASK ] ) {
case TIMER_EVENT:
break;
...
}
3) When the task is scheduled for the first time it sets itself to polling mode (changes its own task state from UTASKER_STOP - the state that it will enter with when scheduled due to a timer event - to UTASKER_GO). It also starts a monostable timer to inform it after 1s that the event POLL_TERMINATE has occurred.
During the next 1s (as long as no other task changes the state or posts a message to it) it will be continuously scheduled (polled).
After 1s the timer will fire and set the task state to UTASKER_STOP when the timer event POLL_TERMINATE is put to its input queue. This will cause the 1s of polling to automatically terminate.
If during the 1s delay a message is posted to the task it will also cause it to return to the UTASKER_STOP state.
This is a characteristic of the wake-up operation (as you noted, the transitional state used to ensure that a post by a timer, event or other message, is UTASKER_ACTIVATE, which is a state which causes the task to be unconditionally scheduled once).
This means that if the task should continue polling (or return to polling) the task must set itself back to this state when it receives a message (timer event, interrupt event, etc.).
In your particular case, if the task stops polling it is presumably due to the fact that it has received something in its input queue (possibly a timer event from your details). If you would like this task to continue polling you will need to set it to the polling state again.
There should however be no problems involved with combining start-up delays with a polling task.
Notes:
A) The task's own state can be read with ptrTaskTable->ucTaskState, however beware that this state can be changed by an interrupt routine posting an event to the task, which includes also a monostable timer firing (it may not be the same value after being read). The combination of a task used in polling mode which can receive such events should generally be avoided - if it is required the method to be used to switch it to polling mode would be:
uDisable_Interrupt(); // protect the change from interrupts
if (ptrTaskTable->ucTaskState == UTASKER_STOP) {// don't change unless stopped because the task will be re-scheduled
ptTaskTable->ucTaskState = UTASKER_GO;
}
uEnable_Interrupt();
B) It is not recommended to set a task to polling mode from another task due to the fact that this other task is not aware of the polling task's message handling. A simple task without timers and input queue can however be set to polling mode from another task (and stopped later if required) since it will never be disturbed.
C) There is presently a potential problem with the routine uTaskerStateChange(), making the technique in A) necessary to avoid a potential loss of event when setting a task to polling mode when the task is presently scheduled to be woken by an event (in the UTASKER_ACTIVATE state). This would cause the state to be changed to UTASKER_GO and the waiting timer event not to be posted to the task. I don't think that this is a big problem since I have never in fact encountered a project using a task in polling mode which is also handling interrupt based events, but I am considering making a change to the uTaskerStateChange() routine to automatically protect against this. In the meantime technique A) does the same thing (assuming being called from its own task) and is also more efficient since it doesn't have to first search for its own task.
Does this help solve your problem?
Regards
Mark
