MQX Software SolutionsのトピックRe: Bug report: _time_delay() not the good delay.

Bug report: _time_delay() not the good delay.

arnogir — Tue, 13 Jan 2015 15:54:49 GMT

Hello,

I made some test because task period seem to me so long..

Then I with test MQX 4.1 and only one task:

Task:

 /*Port initialization */
[...]

 for (;;)
   /* Toggle led */
   /* ****** Here instruction which toggle Led ****/

   _time_delay(X);
}

Then I measured the SIgnal on the Led and measure the period for different value of "X" passed in _time_delay();.

X= 1 measured time = 10ms
X= 5 measured time = 10ms

X= 10 measured time = 15ms

X = 12 measured time = 20ms

X = 100 measured time = 105ms.

For information, BSP_ALARM_FREQUENCY = 200 (5ms)

Then, the time is always delayed by 5ms. (When asked time is a multiple of BSP_ALARM_FREQUENCY)

What do you think of this? How can I make _time_delay exactly the asked time?

Re: Bug report: _time_delay() not the good delay.

DavidS — Tue, 13 Jan 2015 20:11:01 GMT

Hi Arno,

If you need to have the timedelay(ms); more accurate you can increase the BSP_ALARM_FREQUENCY (max is 1000) or implement a routine to take advantage of one of the on-chip timers that could generate and ISR and set an event flag for your application to continue.

In general the timedelay(ms); is ensuring your application will block for at least the number of ms you enter as a minimum and not a maximum. The ms is converted to TICKS in the function call and rounded up one TICK. The TICK is the heartbeat of the RTOS and is synchronice. Many internal timers and services use it to determine when another task should be blocked or unblocked. Then the scheduler will run to determine which task is the highest priority ready to run task.

Regards,

David

Re: Bug report: _time_delay() not the good delay.

arnogir — Wed, 14 Jan 2015 06:22:13 GMT

In fact we should use time_delay to appy "at least" the specified time.

SO to have a periodic task, a simple way will be to call _time_delay(task_Period -1)...