Hi,
We are enabling the system main task at every 10ms interval.
but now we are facing the problem with enabling of the system task @10ms interval ..
could you please any one help us How we can verify the time set by Os_itv_set(1) and Os_itv_wait funciton
our main task is as shown below void task1(void) {
os_itv_set(1);
for(;;) { os_itv_wait();
}
Hi Tnank you for your reply,
The Os_idle_task is running in the background, This i verified by incrementing the count in the os_idle_task. and displaying on the lcd.
When i replaced the os_itv_set and Os_itv_wait with the os_dly_wait the problem is solved and now it is not resetting.
but i have some issues with respect to the timing like i want to poll the flags at every 1second(exatly).
Info I have:
1) takes about 5 minutes for "system task: to run. 2) Idle task is also not running during this period.
Problem:
Something IS running and not allowing any cpu time for system task (or Idle) to run. When you do a os_itv_wait() the task is blocked for the number of ticks to get to the timeout period. When this period ends, the task is put into the ready queue behind all task that are a higher or the same priority. Your main task is not getting to run because there is another task at the same or higher priority that is running.
The advantages with LEDs is that they consume very little CPU time so you can use this type of debugging almost everywhere.
The serial port is way too slow to handle printouts. And the CPU load from creating the trace strings is too high for critical sections. In many situations, you will not be able to have serial output from ISR because of reentrancy issues.
A debugger may be fun, but only for looking at a single-threaded algorithm. Life is no fun anymore when trying to use a debugger with an embedded system with RTOS - the peripherials will not stop just because you reach a breakpoint. You may look at the current snapshot, but when stepping the next instruction, all interrupt sources will fight for the attention. And when the ISR gets called, it is already too late because the ISR didn't get serviced in time because of the breakpoint.
One thing I have done when debugging an RTOS-based application is to have one diode for each task, and let the task turn on the LED when exiting the wait function, and turn off the LED before starting the next wait.
The LED for the most prioritized thread will directly show how much CPU time it consumes, and a good scope can help with jitter, longest execution time etc.
The LED for the second-most prioritized thread will light when this thread runs, or when this thread gots preempted by the most prioritized thread. So longest lit time for LEDB shows longest time to do one action. And (LEDB && !LEDA) informs about CPU load from thread B.
(LEDC && !(LEDA || LEDB)) informs about the CPU load from the third-most prioritized thread.
Most of the time, you don't need a scope. The flicker or intensity of the individual diodes is enough.
"..it helps a lot ot have a couple of LED.
Very good advice - I cut my embedded teeth with methods like this.
And still, when we get prototype boards built, I always request LEDs be fitted.
Doesn't matter if it toggles every 10us or every 10ms or even every 10 minutes.
For low frequencies, you would use your eyes and possibly a stopwatch. For high frequencies, you would just look at the glow, to see if something happens, and use an oscilloscope to verify the frequency.
Having a diode can allow your eyes to get a feeling for the behaviour of a process, by just looking at the result of the PWM drive of the LED. For prototypes and preproduction, it helps a lot ot have a couple of LED. for full production, you can remove any extra LED from the BOM.
Thank you for your reply
The task is not getting executed for 5 minutes and starts executing after that (The above is verified with the display)
During when system task is idle, OS_idle_demon task is also not getting executed .. (Verified by reading the idle count which we are randomly changing in the idle task)
A LED toggling every 10[ms] :-)
The simplest way to check your thread is to let the thread toggle a LED each time directly after os_itv_wait().
View all questions in Keil forum