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

[Giovanni]

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]

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

[Giovanni]

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]

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

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

[steved]

I'd like to see some extension of the support for handling memory caching. I've pulled together my random thoughts here:

1. Within processor definitions, add a #define MEM_CACHE_ALIGNMENT
Set to zero if no cache controller.
It can then be used as the parameter to Chibi's heap allocators to set the alignment boundary.
It can also be used in multi-platform code to modify behaviour (if nothing else, aligning to a 32-byte boundary has the potential to waste a significant amount of RAM, and RAM is likely to be less plentiful on platforms that don't support caching).


2. Add various #defines to support memory allocation. The ones I use are:

Code: Select all

#ifdef STM32F7xx
#define CACHE_ALIGN         __attribute__((aligned (32))) __attribute__((section(".ram0")))
#define CACHE_ALIGN_ZERO    __attribute__((aligned (32))) __attribute__((section(".bss")))
#define CACHE_NONE          __attribute__((section(".ram3")))
#else
#define CACHE_ALIGN
#define CACHE_ALIGN_ZERO
#define CACHE_NONE
#endif


3. Is there any reason that .bss is forced into non-cacheable RAM?


4. A mechanism by which additional RAM can be declared or marked as non-cacheable. In the case of the 32F7XX, this would probably set up the MPU.
In an ideal world this could be defined in the makefile. However not sure how easy that would be, so maybe an appropriate function to call, which (like the DMA functions) is null if caching not supported.


5. Somewhat linked to the previous point, a method to manage allocation of definition blocks in the MPU - primarily to avoid clashes with Chibi usage. (I had to search the source to establish that Chibi only uses the MPU in one place, and only if stack guard bands are implemented).
A simple allocate-only mechanism would suffice; a deallocation method could be useful to someone.

[Giovanni]

I am introducing a "factory" mechanism for both RT and NIL, it allows to fabricate objects like buffers, semaphores, mutexes, mailboxes etc and give them a name. The objects have a reference counter so the memory is freed when all object users have released their reference.

This will allow for creation of global objects accessible by name and allows for dynamic objects in general. The mechanism could also be exploited by the debug plugin to make a view of named objects and their state.

The code is under /os/common/oslib, feedback is welcome.

Giovanni

[faisal]

Memory pool object chain:
Basically a dynamically sizable memory object, which can grow by allocating and appending new memory pool objects to a linked list, and shrink by deallocating memory pool objects and deleting them from the list. This is useful for all sorts of applications. Some helper methods would include to read from and write to the object given an offset. As you keep writing, it allocates new memory pool objects and resizes it in real time. This would be similar to, but a more generic version, the packet buffer concept in LwIP. It would also be cool if there was a clean way so that mem pool buffers of different sizes could be chained together.

Message Queue:
An abstraction for mempool + mailbox for ptr to mempool obj + direct events + free_mem callback for thread to thread messaging.

Yes, I like mempools .

[faisal]

I am introducing a "factory" mechanism for both RT and NIL, it allows to fabricate objects like buffers, semaphores, mutexes, mailboxes etc and give them a name. The objects have a reference counter so the memory is freed when all object users have released their reference.

This will allow for creation of global objects accessible by name and allows for dynamic objects in general. The mechanism could also be exploited by the debug plugin to make a view of named objects and their state.

The code is under /os/common/oslib, feedback is welcome.

Giovanni

Ok, that's super cool. I can already think of using something like those factory objects in a simple publish/subscribe object request broker. I haven't put too much thought into it, but one thing I would already request is that it work with a memory pool - or even better that memory pool object chain thing that I requested in the previous post.
Also, support for statically allocated buffers - in which case the release will not do anything .. Useful for persistent globally accessible configurations, etc ..

[Giovanni]

Hi,

Yes, I also added a way to register pre-existing static objects in order to "export" them in addition to the "factory"..

I will also look in other suggestions, the new "oslib" organization allows to introduce high-level mechanisms that are not directly linked to RT and NIL, this library can grow easily.

Probably I should remove oslib settings from chconf.h and create a specific oslibconf.h, this way there would be no need to update all chconf.h files each time a new library module is added.

Giovanni

[Giovanni]

Hi,

I added an "Objects FIFO" class to "oslib", it is a FIFO of objects that can be taken/returned using a Pool. It is very similar to that "mail" module that I posted on the forum a while ago. It can be used with both RT and NIL.

The library is growing well, I am thinking to remove direct inclusion from RT5 and NIL3 and make it a separate "product": ChibiOS/LIB or some other better name.
Ideally anything that could be built from the "ch" API alone and generic enough should be included there. So far it is spectacularly modular and clean, I am liking where it is headed.

On a side note, I am considering removing dynamic threads from RT5, the same functionality would be handled by the new "factory". RT5 would have no more dependencies on the allocators.

Giovanni