[NOTE] Ideas for RT 5 and/or NIL 3

This forum is dedicated to feedback, discussions about ongoing or future developments, ideas and suggestions regarding the ChibiOS projects are welcome.
User avatar
Giovanni
Site Admin
Posts: 9891
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 170 times
Been thanked: 153 times
Contact:

[NOTE] Ideas for RT 5 and/or NIL 3

Postby Giovanni » Sat Aug 12, 2017 12:32 pm

Hi,

Things that could be added to RT 5:

- API to measure stack usage of threads, only available when the filler option is enabled.
- Long sleep function chThdLongSleep() taking a 32/64 bits time expressed in microseconds. The API would be systick-resolution independent but granularity would depend on systick frequency.

Things that could be added to NIL 3:

- Make tasks startable/re-startable, introduce chThdExit().

Giovanni

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

Re: [NOTE] Ideas for RT 5 and/or NIL 3

Postby Thargon » Mon Aug 14, 2017 10:39 am

Hi,

a more transparent API regarding thread stack in general would be great. Right now you can only define the size of the working area, which is more than just the stack, as I understand it. That is quite confusing since the stack actually is always smaller than the value you specify e.g. as template argument to BaseStaticThread. Functions to retrieve the start and end addresses of the stack would be appreciated as well ;)

As for the long sleep function, I think this will not satisfy people as it should. The same issues appear for all timeouts and there is still no possibility to get an unique times tamp, except for combining the current systick value with the RTC by hand - very cumbersome and probably not very precise either. I think there should be an option to completely switch from the current configurable systick system with hardware dependent width, to a 64bit system with microsecond precision. Of course all functions that use systime_t will be less efficient, but since there are not multiplications or divisions the performance impact should be reasonable. At the same time, all other API functions can be reused, which leads to high portability and reusability of code. Personally, I need unique timestamps and long timeouts anyway, so just a long sleep functions won't do for me.

Best regards,
Thomas

PS: If I can help with the implementation, let me know ;)

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

Re: [NOTE] Ideas for RT 5 and/or NIL 3

Postby Giovanni » Mon Aug 14, 2017 4:55 pm

Hi,

The value that you specify for working areas is just and exactly the stack size without all the extras caused by: alignment, OS structures, IRQ-related overhead. The memory taken is always greater than the value you specify.

About the 64 bits system time, it would be great but would not work in tickless mode unless you have a 64 bits timer, the system time is an HW counter in tickless mode as currently implemented. The best we can do is to have long delays and timeouts but not a long system time , at least not in tickless high-resolution mode.

Something that I am considering is to split the type for system time and timeouts, for example systime_t and sysinterval_t, intervals could be 64bits with real of approximated uS resolution. Long intervals management could be implemented directly at VT level, the rest of the system would use it if enabled.

Giovanni

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

Re: [NOTE] Ideas for RT 5 and/or NIL 3

Postby Thargon » Mon Aug 14, 2017 5:36 pm

Giovanni wrote:The value that you specify for working areas is just and exactly the stack size without all the extras caused by: alignment, OS structures, IRQ-related overhead. The memory taken is always greater than the value you specify.

I see. Good to know ;)

Giovanni wrote:About the 64 bits system time, it would be great but would not work in tickless mode unless you have a 64 bits timer, the system time is an HW counter in tickless mode as currently implemented. The best we can do is to have long delays and timeouts but not a long system time , at least not in tickless high-resolution mode.

I recently implemented a 64bit system time to run alongside to the systime in tickless mode. I used an additional hardware timer, configured it to tick with 1MHz and have it call a callback when the timer reaches the value (~0) - (ST2US(CH_CFG_ST_TIMEDELTA)). The callback then updates the 64bit value accordingly and the timer just resets and continues counting.
This solution would be completely fine in tickless mode, I think, you just have to store all timeouts and such with 64 bit width and check everything each time an overflow of the hardware timer occurs. Since this is quite bad at systems with 16 bit hardware timers, you can still decrease the de-facto resolution by any factor, similar as CH_CFG_ST_FREQUENCY can have (almost) any value.

Thomas


Return to “Development and Feedback”

Who is online

Users browsing this forum: No registered users and 2 guests