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.
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.