Hello,
This may be quite rare, as it seems like most of the ports are on 32-bit MCUs, however, my 16-bit processor surpisingly has a "CLZ-like" instruction.
Now, unfortunately due to the fact that the priority type is UBaseType_t, I can only assign 16 different priorities when using the bitmap approach. Is there any way for me to extend to 32-bit, or potentially introducing a type for priorities?
E.g. PrioMapType_t, BitMapType_t, BMapType_t, etc...
I understand many ports won't be interested in creating additional types, so it could be typed similar to configSTACK_DEPTH_TYPE.
E.g. configOPTIMIZED_TASK_SELECTION_BITMAP_TYPE
#if configUSE_PORT_OPTIMISED_TASK_SELECTION
#ifndef configOPTIMIZED_TASK_SELECTION_BITMAP_TYPE
#define configOPTIMIZED_TASK_SELECTION_BITMAP_TYPE UBaseType_t
#endif //configOPTIMIZED_TASK_SELECTION_BITMAP_TYPE
#endif //configUSE_PORT_OPTIMISED_TASK_SELECTION
This would be helpful for my 16-bit application, and applications which want to use greater than 32 priorities.
Thanks & kind regards,
Victor B.
It is a little more complex than this as there may be placed in the code where updating the priority is assumed to be atomic - hence the base type - whereas in your case making it 32-bits would mean udpates would no longer be atomic.
I have to admit to being curious - it is rare to have more than 16 priorities - especially in FreeRTOS where many tasks can share the same priority - and I would have thought it rarer on a 16-bit device as it would imply you had >16 tasks. Which 16-bit device do you have and how much RAM does it provide?
I see, that makes perfect sense. I already refactored to use 16 task priorities (with the fast context switching), the performance gains were ~ 33%.
The target application is for a proprietary framework that originated on the Infineon C166 architecture. The target I am working on is based on the C166v2 core, the successor to the C166 architecture. It has an address space of up to 16MB, and has some very interesting features. Many of the derivatives are very similar, and mostly change the external periphery connected to the main CPU (MultiCAN, USIC, etc.).
Porting FreeRTOS to this platform went smoothly, I had more issues from designing the wrapper for FreeRTOS to RTX API.
Last edit: Victor Brzeski 2019-11-26
Very nice. It would be great if you could upload your port code.
Currently the FreeRTOS Interactive site, which was used for that
purpose, is broken for new posts - but soon we will have a new method on
forms that are on the FreeRTOS URL.
Thank you! I will if I am legally able to.