Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unbuffered version? #5

Open
cmcqueen opened this issue Oct 16, 2015 · 2 comments
Open

Unbuffered version? #5

cmcqueen opened this issue Oct 16, 2015 · 2 comments

Comments

@cmcqueen
Copy link
Owner

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.


@cmcqueen
Copy link
Owner Author

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.

@rsaxvc
Copy link

rsaxvc commented Jan 9, 2019

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

@cmcqueen cmcqueen removed the trivial label Nov 11, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants