You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm writing a crate that parses data directly out of an embassy_stm32 BufferedUartRx. This goes wrong when the internal ring buffer wraps around, causing only the "front" slice to be returned by BufRead::fill_buf() until it is consumed, meaning I can't avoid allocating a second buffer for parsing. I wonder if we can do better than that.
Initially I thought that BufRead shouldn't be implemented for ring buffers, and this implementation would have to move around its contents to keep them contiguous, but that's probably not a good idea. Besides, std implements BufRead for VecDeque.
One idea would be an additional RingBufRead trait, since ring buffers are common enough, especially on embedded:
I'm writing a crate that parses data directly out of an embassy_stm32
BufferedUartRx
. This goes wrong when the internal ring buffer wraps around, causing only the "front" slice to be returned byBufRead::fill_buf()
until it is consumed, meaning I can't avoid allocating a second buffer for parsing. I wonder if we can do better than that.Initially I thought that BufRead shouldn't be implemented for ring buffers, and this implementation would have to move around its contents to keep them contiguous, but that's probably not a good idea. Besides,
std
implementsBufRead
forVecDeque
.One idea would be an additional RingBufRead trait, since ring buffers are common enough, especially on embedded:
Or, this method could be added to
BufRead
with a default implementation that callsfill_buf
and returns(fill_buf_result, &[])
.Thoughts?
The text was updated successfully, but these errors were encountered: