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.
After considering all the feedback we will remove this change for the next revision. This effectively revert back to behaviour before the fix.
Sorry for the confusion.
Reinhard
Hi,
another CMSIS-RTOS non-conformity: try osSignalWait(0, 100000); You will observe that the function will only wait for 65.53 s. This is due to the fact, that RTX can handle only uint16_t waits. See also the so called "helper function"
static uint16_t rt_ms2tick(uint32_t millisec)
and its use in several wait functions of rt_CMSIS.c.
A change of this or at least a mention in the CMSIS-RTOS documentation was promised to me in a support case in March of this year. I wonder when this will happen.
Best regards, Ralph
Much thanks for your consideration of this request.
Cheers, Andrew Lucas