RTX timing change

I agree with you 100%

At the very least if they wanted to make this change they should have made it a modifiable parameter with the default being the original implementation.

Rule number 1 is to never break existing code.

What baffles me is that previously there was a simple work-around (add 1 to the delay), but now there is no work-around for those that need the original implementation.

I really hope that Keil reconsiders this ill conceived change.

So this is the official Keil response to my request to make the change configurable.

>>> I've spoken to several people, and the conclusion was that our developers
>>> will not entertain any request to restore the old functionality.
>>> We do supply the full source of the CMSIS RTOS, so you can recompile the
>>> library with any changes you want.

I would love to know if others feel this is a poorly thought out change. Thankfully Keil is correct, I can make my own changes with the source, but I would really prefer not to have to do this.

After much consideration of this, my stance is that the change itself does not seem unreasonable. So many times I've see code that assumes (for example) a 1ms delay can be derived from a timer having 1ms granularity, just to find that delays based on it often end up being less. The change made basically just changes the situation that would occur with a software based delay; ie, assume it is a 'wait for a minimum amount of time'.

With regards changing an API: that is always undesirable, but at least Keil have documented it as a change. I would not like to count the number of times I've witnessed a change made to an API where there has been no notification. With the detail given, it should be a relatively simple task to update the application to use the new API detail.

But that is just it, it isn't a simple task.

To make my application work with the new RTOS I would either need to change my SYSTICK period to 0.5 ms so that I ensure my state machine polling states poll every 1 ms. Or I need to change many states to a new polling period of 2 ms.

Neither is desirable. Changing the SYSTICK period would mean that I now have twice as many timer interrupts causing a reduction in available bandwidth. Changing the polling period though possible, means that my syncronization period is now twice what it used to be with possible ramifications due to the real-time nature of my application. Also this change would impact many threads

In addition the code is now more confusing since either way the code will say a delay of 1 timer tick period but the actual delay between polling iterations will be a period of 2 timer ticks, how is this helpful.

It seems to me that as far as making the behavior easier to understand we have reduced the readability and understandably of the code, since an osDelay(1) in a loop will actually introduce a delay of 2ms, that doesn't make sense to me.

Almost all delay functions in existence are implemented in a way where the user must understand the concept of timer granularity and that the initial period may be shorter because the delay might be called a random time into that first time quantum. If they aren't implemented that way, then they normally manage by internally operating on a much faster time base than the delay parameter - so if 1ms is requested, they might be based on a 1us timer meaning you get a shortetst delay of 999us.

Sometimes, people are lucky enough to reserve a single timer for their task, allowing them to run the timer at a high enough frequency that the length of the first tick doesn't matter. One such example are the multimedia timers in Windows.

In this case, Keil is doing something that is deviating from the normal practice, and for the single reason that they want to protect beginners from making a mistake. Should Keil protect beginners from stupid assumptions, by instead forcing their experienced users to suffer?

The scary scenario here would be that it is a junior developer at Keil that recently suffered from the specific assumption that the first tick will be a full time period - and so made the decision that the delay should always add +1 instead of letting the individual developers decide if they need a guaranteed minimum time, or if it is more important that multiple delays in sequence accumulates correctly. Or if they want to run a timer at 10 times the speed of the granularity to make sure that first tick can never be shorter than 0.9 times the nominal time.

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.