I am really surprised that with the latest version of RTX that Keil has changed the functionality of the millisecond parameter to delay functions.
See
http://www.keil.com/support/docs/3766.htm
It sees that now the delay parameter is having 1 added to it in the latest version of RTX.
This is a significant functional change that I would have thought would not have been implemented without reaching out to the community of users. This change breaks a ton of existing code that relies on polling intervals of the tick frequency.
I regularly have threads that implement a 1 ms polling of hardware devices. This is implemented as a simple delay of 1 ms. Granted the first call to this delay function may return in less than 1 ms, but after that it is consistently 1 ms in duration. With the changes I don't believe that I will be able to poll at the tick frequency of 1 ms, it would be 2 ms. It seems to me that minimum polling time has been decreased to 2 times the tick frequency with the latest version.
I would strongly encourage KEIL to put back the original functionality, but I was wondering if others had the same concern.
Hi Andrew,
we have documented that change in the Revision History of CMSIS-RTOS RTX. www.keil.com/.../rtx_revision_history.html Now a delay or timeout value of '1; ensures that it is at least 1 millisecond (actually between 1..2). Before the modification a delay or timeout value of '1' was actually between 0..1 milliseconds and this caused complains form other users.
The real issue is that the behaviour is not specified precisely. Also a osDelay function cannot be used to implement interval timers (use osTimer functions instead for that).
Currently we have a discussion in team. We consider to revert back to the previous behaviour where a delay or timeout value was effectively up to 1 millisecond less then than specified value.
Can we get some opinions from other users.
Thanks
I don't like this change even though the user can re-compile the source code to get his own compatible version. I agree osTimer is better than osDelay to implement interval timers. But this doesn't help preventing previous code from breaking.
Keil support just made me aware of another change to RTX that wasn't clear in the release notes.
>>> in this new CMSIS RTOS, you must call your delays in milliseconds, >>> so even if you speed up the OS clock, you can't get a delay of less than 1 mSec. >>> I don't see a way to use the RTOS to generate a timeout of less than 1 mSec. >>> You can use a hardware timer to create any timeout you like, but the RTOS is >>> not set up for that kind of use.
So not my only hope for a work-around (to reduce my SYSTICK period to 0.5ms) won't actually work.
Considering that the old behavior is the way that FreeRTOS, uC/OS-III and ThreadX all work, I am surprised that KEIL wants their RTOS to behave differently and quite unexpectedly to the advanced user.
Again please consider making this new functionality configurable.