Forgive if I am wrong. Although I am in sw development since a long time, I am still new to open source development.
I have a proposal.
What turned out to be extremely usefull in my application was a modification to Queues. I keep track on the minimum number of item slots available throughout a program run. This gives me an idea of which queues are heavily oversized while other queues might be undersized.
While I agree, a program must be ready to deal with the situation of a queue running out of space, I think it is nevertheless a good idea to have some understanding of what a reasonable queue size might be under average and worst case conditions.
The metric “uxQueueMinimumSpacesAvailable” can aid with that.
If guarded with into configSUPPORT_RUNTIME_STATISTICS sections it doesn’t impose a runtime penalty if not activated.
The modifications themselfs are trivial but I don’t know how to procede further. How do I contribute my code modifications? What are your thoughts on this addition?
Hmm.
I have to admit I haven’t thought about those. I think it is possible to use them to achieve the same goal.
Nevertheless I consider integrating this functionality into the statistics package the better solution
I’m not sure it wants to be in the current “Run-Time Stats”, as it is really orthogonal. It could make sense for a Queue stats section that maintains a list somehow of Queues, and have the queue maintain a max usage/min free value.
@richard-damon I think I understand your suggestion, but the “queue stats section” confuses me a bit. Are you suggesting a section within the existing run-time stats (or the “get system state” functionality), or a completely new function that returns queue stats.
Anything that helps developers is good - but for consistency if we build the functionality for queues then we should do likewise for the stream buffers, message buffers, etc. too.
It would be a completely new set of functions. The existing functions have no way to actually return Queue stats, except maybe the “connivence” function that returns a string array.
Yes, and Stream Buffers could either be included in it or a seperate entry, fundamentally usage stats for a Stream Buffer is similar to q Queue, unless you are going to try to keep track of the number of sends/gets to the object.
Message Buffers are really just Stream Buffers with a minor change so would likely use the same API as Stream Buffers.
@Kalle
Would you like to create a pull request in FreeRTOS-Kernel repository? We can look into your modification there and have more discussion with you.