• State Not Answered
  • Locked Locked
  • Replies 25 replies
  • Subscribers 22 subscribers
  • Views 6985 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

RTX timing change

Andrew Lucas

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.

Parents
  • 0 Arm Employee Badge in reply to Andrew Lucas

    Hi Andrew,

    we have documented that change in the Revision History of CMSIS-RTOS RTX.
    www.keil.com/.../rtx_revision_history.html
    Now a delay or timeout value of '1; ensures that it is at least 1 millisecond (actually between 1..2). Before the modification a delay or timeout value of '1' was actually between 0..1 milliseconds and this caused complains form other users.

    The real issue is that the behaviour is not specified precisely. Also a osDelay function cannot be used to implement interval timers (use osTimer functions instead for that).

    Currently we have a discussion in team. We consider to revert back to the previous behaviour where a delay or timeout value was effectively up to 1 millisecond less then than specified value.

    Can we get some opinions from other users.

    Thanks

Reply
  • 0 Arm Employee Badge in reply to Andrew Lucas

    Hi Andrew,

    we have documented that change in the Revision History of CMSIS-RTOS RTX.
    www.keil.com/.../rtx_revision_history.html
    Now a delay or timeout value of '1; ensures that it is at least 1 millisecond (actually between 1..2). Before the modification a delay or timeout value of '1' was actually between 0..1 milliseconds and this caused complains form other users.

    The real issue is that the behaviour is not specified precisely. Also a osDelay function cannot be used to implement interval timers (use osTimer functions instead for that).

    Currently we have a discussion in team. We consider to revert back to the previous behaviour where a delay or timeout value was effectively up to 1 millisecond less then than specified value.

    Can we get some opinions from other users.

    Thanks

Children
  • 0 in reply to Reinhard Keil

    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.

  • 0 in reply to Reinhard Keil

    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.