Feeding bytes to a parser

[elpiel]

Thank you for working on this parser and publishing it to crates.io!

I'd love to see a way to feed bytes to the parser until a valid frame(s) are encountered and returned.
This will greatly help when developing firmware for embedded devices or any IO input which can feed partial frames.

PS: I'm the community manger at @AeroRust and I would love to take your crate repository under our organization. I'd love to hear your though on this.

[mariano-f-r]

This wouldn't be too hard. Some sort of IbusPacketBuilder, could be created, and then it could receive bytes until it encountered a whole valid packet, at which point it would be consumed and return an IbusPacket. At least, this is how I've understood it. Or do you mean some sort of sink for bytes that also functions as a stream for packets?

In regards to having this repository added to an organization, I am curious as to what that would entail. I am open to anything.

Lastly, apologies for the delay in response, I am fairly busy at this moment.

[elpiel]

Yeah, I think it's easy impl as well as otherwise I have to do it manually (finding the header of the packet and duplicating part of the parsing)

One caveat would be that in no_std we don't want to have big buffers, maybe 64 bytes should be enough or it should be configurable by the user with a const. generic?

[elpiel]

Recently a colleague of mine worked on our sbus impl and they based it on embedded_io and embedded_io_async Read traits using read_exact. I haven't tested it in a real environment,e.g. with a UART but it's worth taking a look:

https://github.com/AeroRust/sbus-rs/blob/master/src/parser/blocking.rs

[mariano-f-r]

I appreciate the reference. I was personally imagining a fixed size buffer wherein a user feeds bytes, and once a full packet exists, it is returned, and the remaining buffer are shifted over to the left. I will consider using the Read trait (Rust traits are its superpowers after all).

[elpiel]

Yes I think before I might be an easy solution especially if it's a Ring buffer of some sort.

There is one drawback to the read trait which I personally haven't researched:
It might be possible to get a partial frame initially so using read_exact might not be ideal.

[mariano-f-r]

There is one drawback to the read trait which I personally haven't researched: It might be possible to get a partial frame initially so using read_exact might not be ideal.

I am inclined to agree, which is why I am now hesistant to implement the Read trait, especially since this parser is not a source in the same way a UART or an I2C/TWI line is - that is, the bytes are not meant to be used raw, rather, sent through a parser.

It should be said that I am trying to keep this library in line with the Unix philosophy - do one thing and do it well. It is not the library's job to acquire the bytes from a source, simply to parse them once received.

Lastly, ironically, if I were to implement the embedded_io Read trait, I'd actually not be able to use this new buffered parser with the rppal library, which is ironically the whole reason I started developing this library.

I think a configurable array buffer should suffice for the time being. I will try to learn how to implement a ring buffer using only core and alloc. std has one, but I can't use it, although I may feature-gate it later.