cobs-c icon indicating copy to clipboard operation
cobs-c copied to clipboard

Unbuffered version?

Open cmcqueen opened this issue 9 years ago • 2 comments

Originally reported by: Yaroslav Boris (Bitbucket: Boris_Yaroslav, GitHub: Unknown)


How about to realize the version without using buffers? This will be useful for the controllers, who do not have a lot of memory.

For example: I received byte - passed to the function, the function may call another function, which sends the decoded byte.


  • Bitbucket: https://bitbucket.org/cmcqueen1975/cobs-c/issue/5

cmcqueen avatar Oct 16 '15 11:10 cmcqueen

Original comment by Craig McQueen (Bitbucket: cmcqueen1975, GitHub: Unknown):


Yes, this could be done.

Encoding would require a 254-byte state buffer (plus probably a few more bytes for state/counters/flags). Decoding would require a 1-byte state buffer (plus probably another byte for state/flags).

Encoding is "bursty", in that it only generates output after receiving a zero byte, 254 consecutive non-zero bytes, or end of packet. At this point, up to 254 bytes could be ready to read at once, but depending on the application it might not be appropriate to have all 254 bytes output at once (by the encoding function calling another output function up to 254 times). So I would probably want to have separate write and read functions. Read function might return "nothing to read (yet)". Then write function might return "can't write until buffered bytes have been read". What do you think? Alternatively, it could be implemented as a fixed 254-byte delay line to smooth out this "burstiness" (that is, 254 bytes have to be input before the first output byte appears). But this seems less flexible and less likely to meet target use cases.

cmcqueen avatar Oct 22 '15 23:10 cmcqueen

I'd prefer the bursty-method rather than a delay-line, to better take advantage of UARTs with DMA and USB packets.

rsaxvc avatar Jan 09 '19 04:01 rsaxvc