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();
}
A LED toggling every 10[ms] :-)
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)
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.
"..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.
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.