Hi all,
is Clock_start can start the clock again after timeout? and if i called Clock_start after Clock_stop, does the clock resumes the timer or restart it?
This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Hi all,
is Clock_start can start the clock again after timeout? and if i called Clock_start after Clock_stop, does the clock resumes the timer or restart it?
Mohamed,
It's not totally clear what you're asking here. What kind of timeout are you trying to resume from? And what device are you using?
Clock instances are stopped and re-started using successive calls to Clock_start() and Clock_stop(). Notice that I say "clock instance" (meaning the RTOS software object) and not the underlying timer that drives the clock instance. If this is uunclear, you might want to look at the SYS/BIOS online tutorials at http://processors.wiki.ti.com/index.php/SYS/BIOS_Online_Training, and particularly the module on Timers and Clocks.
Dave
Dave -
I have a very similar question to the one asked by Mohamed. The training slides you cited do not address the question Mohamed asked. Maybe I can add more detail about my specific need that will make the question clearer.
My system has a trigger event that will be asynchronous and repeating, with 50-75 ms between trigger events. When the trigger event occurs, I need to start a delay timer with a fixed timeout value starting from the time of the trigger event. When the delay timer expires, a semaphore is sent that activates a task that performed an action at a fixed delay following the trigger event.
Because we do not want expiration of a timer to trigger a restart of the same timer with the same parameters, a periodic timer does not fit. So I planned to use one-shot Clocks. So I would set up clock parameters, but wait to do a Clock_start() until the trigger event occurs. That approach works for the first trigger event. The question is how best to implement a one-shot timer to serve the next trigger that starts the next event cycle.
Deleting the old clock instance and creating a new clock instance on each cycle seems like it would have excessive overhead. It seems there must be a more light weight approach to recycle one-shot timers. This would be possible if each one-shot clock instance is not automatically deconstructed on expiration of its timeout timer. Then the clock could be reinitialized by refreshing its timeout value if necessary, then it could sit idle and ready until the Clock_start() call is made at the next trigger event.
I have tried doing a Clock_stop, refreshing clock parameters, and calling Clock_start() when the trigger event happens, but the clock instance works only once, and does not come back to life for the 2nd cycle.
I have tried Clock_delete() followed by Clock_create, re-assigning the same clock handle, but that crashes the program.
Is what I need even possible with the Clock API? Do I need to use hardware timers? What would be the cleanest approach? If you could point me to a reference resource, great! I have not found any published documents that address a need for continuous use of timers with asynchronous start events.
Thanks,
Tom
Hi Tom,
I would recommend using the hal/Timer module to implement the one-shot functionality you want instead of using the clock module. Using the hal/timer allows you to implement device independent code.
Here are the steps:
Step1: Create a hal/Timer instance with start mode set to user and run mode set to one-shot.
Example *.cfg code to statically create timer: Program.global.obj = Timer.create(-1, '&myIsr', {period: 0, runMode: Timer.RunMode_ONESHOT, startMode: Timer.StartMode_USER, periodType: Timer.PeriodType_MICROSECS, arg:1});
Step2: Repeat the following sequence each time you want to trigger an event after "period" micro seconds.
key = Hwi_disable();
Timer_setPeriodMicroSecs(obj, period);
Timer_start(obj);
Hwi_restore(key);
Best,
Ashish