My system receives commands through an RS232 serial port, which is sent to the application through a FreeRTOS message queue.
Usually the RS232 messages are more than 1 byte long, typically about 10, but the length is variable up to 61 bytes.
In the current situation, the application task requests to receive 1 byte from the queue (xQueueReceive()) and is put to sleep because the queue is still empty, resulting in a task-switch (to for example the idle task).
When the RS232 port receives a byte, the interrupt service routine moves this byte to the queue (xQueueSendFromISR()). The kernel discovers that a task is waiting for this queue to deliver the byte and this task is woken. This causes another task switch from the idle task bvack to my application task.
However, only 1 byte does not make a full command. The application task continues to receive the rest of the bytes in the message (which haven’t even been received by the RS232 by now, thus are not in the queue). Thus the task is immediately suspended again until it is rewoken (indirectly by the RS232 interrupt service) after the 2nd byte has been sent to the queue. Also for the 3rd, 4th etc bytes, the task is repeatedly suspended and rewoken when the byte is received until the message is complete.
This way, the application is suspended and rewoken once for every byte that is received.
Every time this costs a few hundred cycles, and for a 60 bytes message on the RS232, this amounts to an awful lot of lost cycles.
I would like to have the option to specify a variable number of items that is expected from the queue. The application would then only be woken after that number of bytes is received (or at a time-out of course, just like xQueueReceive())
Thus only 1 suspend + wake are required for an arbitrary length message.
Does anybody know if there is a clever way to do this with the current API?
I would think this requires a modification of the API since the queue mechanism needs a parameter to specify the number of bytes for each waiting task.
I have 3 years experience with FreeRTOS by now and am very willing to do my part on this but if I am correct on needing to modify the task manager code I’m going to need some support (especially I would like it to become included in the API when it has matured enough, so I don’t get stuck with 5.0.0 for the rest of this products economical life…)