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