Test suite issues with high-precision timer settings

Discussions and support about ChibiOS/RT, the free embedded RTOS.
Thargon
Posts: 27
Joined: Wed Feb 04, 2015 5:03 pm
Location: CITEC, Bielefeld University, germany
Been thanked: 1 time

Test suite issues with high-precision timer settings

Postby Thargon » Fri Feb 17, 2017 11:53 am

Hi,

I just ran in some issues when executing the TestThread() function (test/rt/test.c). In my chconf.h I configured the CH_CFG_ST_FREQUENCY to be 1000000 for microsecond precision, but on a STM32F1 with its 16 bit timer register, the ST timestamps will repeat every ~65 milliseconds. For my project this is ok, but obviously any chThdSleep function with an argument that is more than these 65 milliseconds will fail. During the thread tests (test/rt/testthd.c), however, sleeps up to one second are used and consequently fail.
Since the error in these test scenarios is not the kernel code or configuration but the test code, I would recommend to either introduce adjustable macros or let the test adapt to the current system configuration (chconf.h). I would offer to provide an according patch, if such a modification is wanted ;)

I would like to add another minor request regarding the CH_CFG_ST_TIMEDELTA macro. The documentation states that this is "the minimum number of [system] ticks that is safe to specify in a timeout directive". When I run my tests (CH_CFG_ST_FREQUENCY = 1000000) on a STM32F4 (32 bit timer, so no register overrun issues), I have to increase the time delta from the default value of 2 to 8, or the TestThread() function fails. Actually, I have no clue why timeouts must be at least 8us in this case and how I can validate this number without try & error testing. Can you please give me some information or a link to a more detailed documentation about this time delta?

Best regards,
Thomas

EDIT: I had a third request, I just forgot: Since I run much more test than just the TestThread() function, my own test suite uses return values to indicate success or failure of single tests, so I can print a summary at the end and don't need to check several hundred output lines by hand. So far TestThread() returns void, but at least a msg_t would be great to indicate whether everything was fine or some test(s) failed. A more complex return value would be even better ;)

User avatar
Giovanni
Site Admin
Posts: 9761
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 150 times
Been thanked: 138 times
Contact:

Re: Test suite issues with high-precision timer settings

Postby Giovanni » Fri Feb 17, 2017 1:44 pm

Hi,

The delta parameter is meant to be increased when increasing resolution, it represents the intrinsic system jitter caused by ISRs and critical zones.

With a jitter of 10uS you cannot have a real 1uS resolution you have always a N*uS+delta.

Delta is not a calculated parameters because it depends on CPU performance, ISRs, callbacks and critical sections.

Giovanni

Thargon
Posts: 27
Joined: Wed Feb 04, 2015 5:03 pm
Location: CITEC, Bielefeld University, germany
Been thanked: 1 time

Re: Test suite issues with high-precision timer settings

Postby Thargon » Fri Feb 17, 2017 2:12 pm

Giovanni wrote: [CH_CFG_ST_TIMEDELTA] represents the intrinsic system jitter caused by ISRs and critical zones [and thus depends on CPU performance and implementation].


That sentence would be a nice addition to the CH_CFG_ST_TIMEDELTA description ;)

Any comments on my other notes and offers?

User avatar
Giovanni
Site Admin
Posts: 9761
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 150 times
Been thanked: 138 times
Contact:

Re: Test suite issues with high-precision timer settings

Postby Giovanni » Fri Feb 17, 2017 2:43 pm

About your edit, in RT4 there is a new test engine and a new test suite (code generated from an XML, very nice). The new code returns a status code like you suggested.

About 16 bit timers, there is not much that I can do, redesigning the test code just for that would be crazy complex considering how often second delays are used.

Giovanni

Thargon
Posts: 27
Joined: Wed Feb 04, 2015 5:03 pm
Location: CITEC, Bielefeld University, germany
Been thanked: 1 time

Re: Test suite issues with high-precision timer settings

Postby Thargon » Fri Feb 17, 2017 3:02 pm

RT4? I wasn't aware that you are redesigning the kernel again. Is there a list with planned features/changes? The new test suite sounds very nice, indeed :)

Regarding the 16 bit timers: I did not mean to enhance the tests, so you can sleep for one second even if the configured frequency is too high. I rather though about adapting the values or printing warnings if the the test could not be applied.
Example: The timer can only represent ~65 milliseconds. The tests can detect this and adapt the delays accordingly. In cases where even the smallest value can not be applied (e.g. chThdSleepSeconds() in this example) the test should not fail, but respond with a warning.
That wouldn't be too complex, I think.

steved
Posts: 338
Joined: Fri Nov 09, 2012 2:22 pm
Has thanked: 1 time
Been thanked: 12 times

Re: Test suite issues with high-precision timer settings

Postby steved » Fri Feb 17, 2017 7:01 pm

How practical would it be to make the 'thread sleep' macros such as chThdSleepSeconds() implement a small code loop round chThdSleep() if the desired time is out of range of the hardware counter?

User avatar
Giovanni
Site Admin
Posts: 9761
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 150 times
Been thanked: 138 times
Contact:

Re: Test suite issues with high-precision timer settings

Postby Giovanni » Fri Feb 17, 2017 9:14 pm

Hi,

A list of changes in RT4 and NIL2 is discussed here: viewtopic.php?f=3&t=3094

A macro would not be possible but a dedicated function yes, actually is a good idea, perhaps it could be embedded in chthdSleep() itself.

Giovanni

Thargon
Posts: 27
Joined: Wed Feb 04, 2015 5:03 pm
Location: CITEC, Bielefeld University, germany
Been thanked: 1 time

Re: Test suite issues with high-precision timer settings

Postby Thargon » Mon Feb 20, 2017 10:42 am

Thank you for sharing the link. :)

As for the sleeping problem: Currently chThdSleep() takes systime_t as argument, which is the same type as the hardware timer. As a result, you can not specify a time frame that would cause the timer to overflow for this function, which I think is intended and should stay this way, since chThdSleep() is the close-to-hardware function here.
Instead of modifying chThdSleep() in a way that would make it less efficient or even incompatible (due to another argument type), introducing new functions should be the preferable way. As of now, I usually use the MS2ST() type macros to convert a time scale to system ticks and pass the result to chThdSleep() or chibios_rt::BaseThread::sleep() respectively. Instead of using these macros, which are prone to truncate the intended value without giving information about this (explicit casts as used in the macros even suppress compiler warnings), there should be according functions (e.g. chThdMSSleep() ) that detect too large values of the argument and react accordingly by sleeping in a loop.
At this point it would also be very nice to have functions that give information about, how well the specified time can be represented by the system. For instance, if my MCU has a 16 bit timer, is configured to run at microsecond precision, but the time delta is 10 microseconds, The minimum sleep time is 11 microseconds whereas the maximum (without loop) is 65534 microseconds. A function (or macro) giving information whether the specified value for a sleep is below the minimum and will be increased implicitly, fits for most efficient sleeping, or is too large and has to be divided into several individual sleeps would be very welcome, I think ;)

As I said before, I would like to implement these features and provide a patch, IF you want such features in ChibiOS/RT. But maybe you have good reason why not to introduce something like this, though. Just let me know ;)

Best regards,
Thomas

User avatar
Giovanni
Site Admin
Posts: 9761
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 150 times
Been thanked: 138 times
Contact:

Re: Test suite issues with high-precision timer settings

Postby Giovanni » Mon Feb 20, 2017 1:32 pm

Note that the problem would persist in all functions with a timeout parameters, this thing cannot be embedded in a xx2ST() macro because it would have to return a systime_t.

Probably the simplest thing is to introduce chSysLongSleep[Milli/Micro/Seconds]() functions and do not touch timeouts. My doubt is if use an uint64_t for argument or stay with an uint32_t for portability (because 8/16 bits targets).

Giovanni

Thargon
Posts: 27
Joined: Wed Feb 04, 2015 5:03 pm
Location: CITEC, Bielefeld University, germany
Been thanked: 1 time

Re: Test suite issues with high-precision timer settings

Postby Thargon » Mon Feb 20, 2017 2:00 pm

Imo these xx2ST() macros should be replaced by something more sophisticated, anyway. Depending on configuration and argument, the result of these macros might not fit the return type and is truncated without warning or anything. Personally this cost me some time debugging apparently correct code and is very nasty implicit behavior.

As for the timeouts, this can be solved as well, although with a small impact on performance. I use a static uint64_t as system time variable, which is updated periodically via GPT interrupt. All my own functions hence use such unique uint64_t time stamps for sleeping and timeouts. As for the compatibility for 8/16 bit targets, I would assume that today compilers can sufficiently emulate it. The performance impact, however, is already measurable on 32 bit MCUs and an additional hardware timer is required.

Thomas


Return to “ChibiOS/RT”

Who is online

Users browsing this forum: No registered users and 1 guest