fix(serial): Unblock if the queue is full

For some reason a portYIELD() is not enough to give the serial task the option to run. I tried vTaskDelay() and that works. To not block more than needed portYIELD() is still called when the queue is not full and only call vTaskDelay() when it is full.

Closes #218 (closed)

changed milestone to %v1.16

added 1 commit

• f7719151 - fix(serial): Unblock if the queue is full

Compare with previous version

Looks good to me! Thanks for keeping our codebase clean.

However, I'm only a bot - so a human will still have to approve this request.

If portYIELD() is not enough, this means a higher priority task has filled the queue and now the lower priority serial task can't flush it ... I wonder what the correct way to deal with this is, it feels a bit like a situation similar to priority inversion to me. I.e. maybe one should temporarily raise the serial task's priority when a high prio task blocks it? Or lower the current task's priority until the queue is drained enough for the whole buffer to be written?

I think in the meantime this workaround is good enough, but we should put a TODO sign up to keep notice that this should be fixed properly at some point ...

added 1-Bug 3-Epicardium labels

I didn't observe that: The BHI task with priority tskIDLE_PRIORITY + 1 filled the queue of the serial task with priority tskIDLE_PRIORITY + 3.

To be honest I have no idea why this is happening. Everything I know about RTOSes tells me that the serial task should have woken up to consume from the queue. Instead I saw it getting stuck at slightly different locations and FreeRTOS not serving it anymore. Instead it spin looped in the lower priority task which was trying to fill the queue. I tried to see if there are any locks involved which both try to take but that also does not seem to be the case.

merged

mentioned in commit ab9b10cf