Author Topic: waken up task  (Read 7694 times)

Offline neil

  • Sr. Member
  • ****
  • Posts: 438
    • View Profile
waken up task
« on: January 22, 2010, 11:12:11 AM »
Hi Mark,
  I wish to wake up a task in .25 second so I done the following:

   uTaskerMonoTimer( TASK_SAMPLE, (DELAY_LIMIT)(0.25*SEC), 0 );

This is the only way the task will be used, do I have to read in the message within the task as follows?

    QUEUE_HANDLE        PortIDInternal = ptrTaskTable->TaskID;           // queue ID for task input
    unsigned char       ucInputMessage[HEADER_LENGTH];                  // reserve space for receiving messages

     while ( fnRead( PortIDInternal, ucInputMessage, HEADER_LENGTH ))
    {   
        }

Regards
Neil

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3236
    • View Profile
    • uTasker
Re: waken up task
« Reply #1 on: January 22, 2010, 11:58:20 AM »
Hi Neil

uTaskerMonoTimer( TASK_SAMPLE, (DELAY_LIMIT)(0.25*SEC), 0 );

This is a special case due to the fact that the event is 0. This has the effect of adjusting the repetitive rate of the task TASK_SAMPLE. Effectively it will wake the task (without an event,  not requiring an input queue and therefore not requiring a read) after 0.25s. The task will then be scheduled every further 0.25s. By calling

   uTaskerMonoTimer( OWN_TASK, 0, 0 ); in the task itself it can however stop the repetitive scheduling and so behave like a single-shot timer.

Note that a suitable configuration for this task is:

  { "Sample",      fnSampleTask, NO_QUE,   (DELAY_LIMIT)(NO_DELAY_RESERVE_MONO), 0,  UTASKER_STOP},

It needs a timer but doesn't need a queue.

The case is different if the event has a non-zero value. In this case the event is sent to the task when the timer fires and so the task needs an input queue to be able to receive it. In this case it should read the input so that the queue doesn't get full after several events. This means that the receiving task can handle different timer events and know exactly which timer it is.

However a non-zero event can also be sent to a task without an input queue! In this case it will try to send the event to the task's input queue but will fail (this is not a problem, it just doesn't find the task's queue and ignores it). The effect is that the task is still scheduled and so this can also be used for a simple task without input queue which only responds to one known event.

This gives you several possibilities. If you don't have a queue and don't need one it is in fact simplest to send a dummy (non-zero) event so that it will result in a single-shot timer. If you prefer a periodic timer then the zero event is the method to use.

Regards

Mark