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
Original comment byCraig 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.
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.
The text was updated successfully, but these errors were encountered: