RTX timing change

Reading: http://www.keil.com/support/docs/3766.htm

Looking at os_dly_wait (since I use RL-ARM RTX):
os_dly_wait(1 /* rest of current tick */ + 1) ; /* in KEIL RL-ARM RTX */

The library code now adds one on entry. I change my code to passing one less and hey-presto, the library uses the same value as it did before.

"RL-ARM/ RTL / RTX" DOES NOT add one for os_dly_wait()  I would be careful subtracting 1
from any value you pass to it.   You obviously did not look at the code nor did
you try subtracting 1 and see that it uses the same value as before.

First off let me help to fix your current issue with something that works the same as before. Actualy EXACTLY the same as before.

1) include "rtl.h" in your file // it is in ARM/RV31\INC
2) call os_dly_wait(1) every place you now call osDelay(1);

Your code will function as it did before the update (yet you still fully have the update)
Since Keil's CMSIS OS implementaion uses RTX as the base os, you actually have full access to
all of the RTX functionality. If you are looking for functionality that RTX has, then you may
want to consider making calls to RTX directly. If you would like to only use the CMSIS OS function calls, then you will be required to work within that framework, not the framework of your choice.

1) rt_dly_wait(uint16_t ticks) // does not add 1 to the tick count
2) os_dly_wait(uint16_t ticks) // does not add 1 to the tick count
3) osDelay(uint32_t ms)        // after converting the ms to ticks it DOES add 1 to the ticks.


1) rt_dly_wait() is an RTX function
2) os_dly_wait() calls the rt_dly_wait() function through the SVC interface (RTX API Function)
3) osDelay() calls the rt_dly_wait() function through the SVC   (CMSIS_OS API Function)

Lets understand the CMSIS-RTOS approach.

http://www.keil.com/pack/doc/cmsis/RTOS/html/index.html

For Keil, They have choosen RTX as the Basic RTOS and they made an CMSIS-RTOS API wrapper around that OS.

For Keil, the CMSIS-RTOS API is defined in cmsis_os.h
This provides the application with the interface to the "Real Time Kernel" RTX.

The change you are referring to is not an RTX change at all, but a CMSIS-API wrapper change. This change was made because in the CMSIS OS API, the time out in ms and is supposed to guarantee "at least as long" as the timeout value. This is the specification for all ms timeout values in the CMSIS OS. IF Keil wants to be CMSIS OS compliant, they need to do what they did. IF you really believe that Keil should do it different, then I believe you will need to get the spec changed. Then asking them to change the code will be easy.

So for now we need to fix your code.

1) The fix above does work.  Make the change.

2) Your code is working as it did.  Now you can relax and decide how best to fix your
code going forward.

Reading: http://www.keil.com/support/docs/3766.htm

Looking at os_dly_wait (since I use RL-ARM RTX):
os_dly_wait(1 /* rest of current tick */ + 1) ; /* in KEIL RL-ARM RTX */

The library code now adds one on entry. I change my code to passing one less and hey-presto, the library uses the same value as it did before.

"RL-ARM/ RTL / RTX" DOES NOT add one for os_dly_wait()  I would be careful subtracting 1
from any value you pass to it.   You obviously did not look at the code nor did
you try subtracting 1 and see that it uses the same value as before.

First off let me help to fix your current issue with something that works the same as before. Actualy EXACTLY the same as before.

1) include "rtl.h" in your file // it is in ARM/RV31\INC
2) call os_dly_wait(1) every place you now call osDelay(1);

Your code will function as it did before the update (yet you still fully have the update)
Since Keil's CMSIS OS implementaion uses RTX as the base os, you actually have full access to
all of the RTX functionality. If you are looking for functionality that RTX has, then you may
want to consider making calls to RTX directly. If you would like to only use the CMSIS OS function calls, then you will be required to work within that framework, not the framework of your choice.

1) rt_dly_wait(uint16_t ticks) // does not add 1 to the tick count
2) os_dly_wait(uint16_t ticks) // does not add 1 to the tick count
3) osDelay(uint32_t ms)        // after converting the ms to ticks it DOES add 1 to the ticks.


1) rt_dly_wait() is an RTX function
2) os_dly_wait() calls the rt_dly_wait() function through the SVC interface (RTX API Function)
3) osDelay() calls the rt_dly_wait() function through the SVC   (CMSIS_OS API Function)

Lets understand the CMSIS-RTOS approach.

http://www.keil.com/pack/doc/cmsis/RTOS/html/index.html

For Keil, They have choosen RTX as the Basic RTOS and they made an CMSIS-RTOS API wrapper around that OS.

For Keil, the CMSIS-RTOS API is defined in cmsis_os.h
This provides the application with the interface to the "Real Time Kernel" RTX.

The change you are referring to is not an RTX change at all, but a CMSIS-API wrapper change. This change was made because in the CMSIS OS API, the time out in ms and is supposed to guarantee "at least as long" as the timeout value. This is the specification for all ms timeout values in the CMSIS OS. IF Keil wants to be CMSIS OS compliant, they need to do what they did. IF you really believe that Keil should do it different, then I believe you will need to get the spec changed. Then asking them to change the code will be easy.

So for now we need to fix your code.

1) The fix above does work.  Make the change.

2) Your code is working as it did.  Now you can relax and decide how best to fix your
code going forward.