Increasing the number of event bits per an event group

I’m using the Event Group API for IPC (inter-processor communication). I need more event bits per a single event group, but the number of event bits is limited to 64 in my platform. Because my platform is 64-bit processor, I re-defined the TickType_t to uint64_t in my system. Is there an easy way to increase the number of event bits to 128? I know that the Queue API could be used for IPC instead of Event Group API. But I don’t want to replace it because I do want to keep the existing applications.

Not at the moment as the number of bits is tied to the TickType_t type. We could separate the types, for example to provide a separate EventBits_t type that can be defined separately from TickType_t - but I would need to check the source code to see if that would create any other issues (for example, lists use TickType_t, so if the code uses lists on the assumption the type used by event groups matches TickType_t then we would not be able to separate the types).

I see a code that EventBits_t type variable is casted to uint32_t.

xReturn = xTimerPendFunctionCallFromISR( vEventGroupClearBitsCallback, ( void * ) xEventGroup, ( uint32_t ) uxBitsToClear, NULL );

Is this safe when configUSE_16_BIT_TICKS == 1?

I’m concerning if I’m fixing all the relevant codes correctly. So, is there a plan to support 128-bit or more events per a group in the kernel?

I assume that you are talking about uxBitsToClear. That should be okay as it should upcast. Are you seeing any problem?


Thanks for your response. I see an issue when dealing with uxBitsToSet. Upper bits are ignored due to casting. I think either downcasting or upcasting do not matter. How about changing the prototype for the pending callback function? The second parameter is uint32_t now. How about changing it to TickType_t which matches with the EventBits_t?

FYI, I’m using the TickType_t as 64-bit type in my port. Also, I added configUSE_64_BIT_TICKS option to support 64-bit based event group.

xTimerPendFunctionCallFromISR() is a public API function - I don’t think changing the uint32_t parameter to a TickType_t parameter would make sense in any case other than where the function is used within the event groups source file. Making it TickType_t would probably break user’s code as it could contain fewer bits. If the prototype were to change it would probably be best to make it a size_t, so it would be 64-bits in your case - assuming you are using a 64-bit processor. Which processor are you using?

Thanks for your comment. Yes, size_t looks better. I’m using Cortex-A53 processor and working on SMP kernel port.