Bug with _time_delay()?

Treskewl — Fri, 20 Nov 2015 02:44:49 GMT

I’ve recently started to move a project across from MQX 3.8 to MQX 4.2, and have discovered that there is a change in functionality on the _time_delay() function. I believe in MQX 3.8, _time_delay() would always round down the given delay to the nearest tick, where as in MQX 4.2, it will round up to the nearest tick, but also add an additional tick. I performed some simple tests by toggling an output and observing this on an oscilloscope, and have found that MQX 4.2 increases the requested time by 1 tick.

So, I started to dig into the _time_delay() function in MQX 4.2, there indeed has been some code changes since MQX 3.8; a comment found in _time_delay()is as follows:

Now it seems that by adding “time_per_tick[ms] - 1” to the “required_time[ms]” is an attempt to force the ticks to round up, which I think it will. But I do not understand why there is the addition of the +1 tick - I believe this to be the problem.

I first noticed this when trying to get the ethernet PHY drivers going (phy_lan8720.c). Within phy_lan8720_init() there is a loop that spins an appropriate amount of times to simulate a 3s timeout on detecting the completion of the auto negotiation. In MQX 3.8, this loop takes 3 seconds to timeout, but in MQX 4.2, this loop takes 6 seconds to timeout. It appears that with a system tick resolution of 5ms, and requesting a _time_delay(5), we actually get a 10ms delay (+100% error) - this explains why my loop delay of 3s is now 6s on MQX 4.2.

I would suspect that for larger delays, this 1 tick is barely noticable, but when your delay is 1 tick, or thereabouts, this error is quite noticable.

Have I understood this correctly?

Re: Bug with _time_delay()?

danielchen — Wed, 25 Nov 2015 08:30:28 GMT

Hi Luke:

_time_delay function translated time into number of ticks. Basically it just counts the requested number of timer interrupts. If you want to delay one tick for example, you need to count 2 ticks.

Argument of _time_delay() function is minimum number of milliseconds to suspend the task because time between last tick and call of _time_delay could vary in range 0..1 tick. I think that is the reason to add the additional tick.

_time_delay is useful when you wish to just release the CPU to other tasks for some time, it is not useful for precise delays, for that case you need to consider different features, most likely driver by hardware timer modules.

Regards

Daniel

MQX Software Solutions中的主题 Re: Bug with _time_delay()?

Bug with _time_delay()?

Re: Bug with _time_delay()?