michaeln32 wrote on Sunday, June 10, 2018:
Hi,
Tasks in the system can creating SW timers using API xTimersCreate().
When the time has come the time service task execute the callback of the timer that was created.
While time service task execute the callback -> Is there a way to know who was the task that creatined this SW timer ?
Thank you
richard_damon wrote on Sunday, June 10, 2018:
The TimerCallback function is given the handle to the Timer that fired, and that handle has a void* pointer that the application can use to store information for its use. You could set that to the task handle when creating the timer, and then the timer callback could get that.
michaeln32 wrote on Monday, June 11, 2018:
Thanks Richard.
Is it ok to add one more filed to TIMER struct - pointer to TCB ?
richard_damon wrote on Monday, June 11, 2018:
My comment is that you don’t need to add a new item to the struct, it already has a void* pointer in it that is for the use of the user. YOU just need to make sure that when you create a timer you assign it to the creating tasks handle, then the timer call back can get that handle.
The create timer functions prototype is:
TimerHandle_t xTimerCreate
( const char * const pcTimerName,
const TickType_t xTimerPeriod,
const UBaseType_t uxAutoReload,
void * const pvTimerID,
TimerCallbackFunction_t pxCallbackFunction );
That pvTimerID parameter is for YOU to use, it sounds like you want to make it the handle of the task creating the timer.
The timer callback function then just needs to call pvTimerGetID() on the timer handle it was passed to itself to get that value.
michaeln32 wrote on Tuesday, June 12, 2018:
Thanks Richard
Are Only tasks can do xTimerCreate() ? or ISR can do also xTimerCreate() ?
If task do xTimerCreate() and after that it deleted without delete the timer, Is the callback of the timer will continue running pereodicly ?
richard_damon wrote on Tuesday, June 12, 2018:
xTimerCreate doesn’t end in FromISR, so it shouldn’t be called from an ISR.
Since creating a timer will allocate memory for the timer, this really isn’t something to be done in an ISR.
xTimerCreate() can (and I often do) be called before the scheduler starts, so before tasks start to run.
Deleting a task does NOT delete anything that it created, because FreeRTOS doesn’t track that sort of thing, and more importatly because it is quite possible for one task to create various resources that other tasks may use. There is not any natural connection of the creator of a timer and the timer itself. If it creates a timer, the timer will continue to operate even after the task is gone.
michaeln32 wrote on Wednesday, June 13, 2018:
Thank you Richard for your good and helpful answers.
The timer service task will run (be in running state) when a timer expired.
The timer greated by a task or by main (before scheduler run) using the API xTimerCreate().
Are there more resons that causes the timer service task to run that are not retelted to xTimerCreate() ?
richard_damon wrote on Wednesday, June 13, 2018:
The Timer Service Tasks needs to run (for a very short time) everytime you adjust the state of a timer (start, stop, restart, etc) as these operations put a command on the Timer Queue for the Timer Service Task to perform these operationss.
The Timer Service Task also handles requests from xTimerPendFunctionCall and xTimerPendFunctionCallFromISR, and those pended function run just like timer callback in the context of the Timer Service Task.
The Timer Service Task will run any time a timer callback is needed to run, and that callback is run in the contex of the Timer Service Task.
One way to think of the Timer Service Task is that it waits on the Timer Request Queue for commands (Start/Stop /Change requests on Timers and Pend Function requests) with a timeout value such that it also wakes up to call timers callbacks as their time expires.