I am not 100% sure how xStreamBufferSend / xStreamBufferReceive works. Is it safe to assume that xDataLengthBytes are guaranteed to be sent / received when portMAX_DELAY is specified when the call is finished?
If that is the case, then the following wrapper is not necessary. Is that corret?
I am not 100% sure how xStreamBufferSend / xStreamBufferReceive
works. Is it safe to assume that xDataLengthBytes are guaranteed to be
sent / received when portMAX_DELAY is specified when the call is finished?
Apparently xStreamBufferSend handles that for you inside the do { } while loop, so no wrapper is necessary there.
With xStreamBufferReceive, the situation is different though… the call can return without having the desired length available under normal circumstances (as task can get notified from various reasons) - even if portMAX_DELAY has been specified.
This is the wrapper (with timeout support) I have been using for reference (feedback is welcome):
Correct, in xStreamBufferReceive() the second parameter is the size of
the buffer into which data is to be copied, not the number of bytes to
receive, so xSteamBufferRecevie() will return as soon as it has ‘some’
data, the length of the data it receives in one go being capped to the
buffer length. See the xBufferLengthBytes description here: https://www.freertos.org/xStreamBufferReceive.html
Ref your implementation of os_stream_timed_read() - from a brief look it
seems you have have an issue if the tick count overflows, the likelihood
of which you have avoided by using a uint64_t - access to which will
probably not be atomic. It may be easier to use code similar to that
shown on this page: https://www.freertos.org/xTaskCheckForTimeOut.html
which uses FreeRTOS API calls to take possible overflows into account
for you.