-
Notifications
You must be signed in to change notification settings - Fork 35
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
"End" byte #11
Comments
This was just a "note to self". I need more time to think about this and any potential edge cases before actually considering for inclusion. |
Would love to dialogue about it. Its a worthwhile thought.
|
Cool, I'll ping you when I have a clearer idea. Basically the short version is a "buffer" that looks like...
The first and most obvious issue is how to differentiate a data byte from the END byte. In Firmata, data values are split into two 7-bit bytes: lsb, msb; this means that 0xF7 (247, "END_SYSEX") is always out of range. It would be a significant amount of refactoring work to do it this way. |
Other possibly better idea is to do a fixed length packet. Only "issue" is
|
I think that's enough issue to pass on fixed length. Also it won't scale, eg. if we wanted pulseIn pattern support. |
The other common way is to include the length of the packet in the header.
|
I think I like this more. |
We should move it to first position and two byte in order to allow for full I can revise this side if someone can handle the spark-io side On Saturday, October 11, 2014, Rick Waldron [email protected]
Chris Williams @voodootikigod http://twitter.com/voodootikigod | GitHub The things I make that you should check out: Help me end the negativity on the internet, share this |
I don't want to rush into any major changes. What do you mean by first position? Before the command? Can you show an example message? |
[messagelength, messagelength, action, pin, data, ..., data] message length = uint16 Chris Williams @voodootikigod http://twitter.com/voodootikigod | GitHub The things I make that you should check out: Help me end the negativity on the internet, share this On Sun, Oct 12, 2014 at 8:47 AM, Rick Waldron [email protected]
|
This design would prevent us from sending 2 bytes for data values in the future, because the received bytes would be ambiguous:
No way to tell that the length pairs from the data pairs and the length of the next action's data. If it comes after the action byte this doesn't cause any issues:
|
I think the ending byte is a more flexible schema. You don't fix the maximum size of packets. And you only use one byte instead of the two suggested, decreasing packet size. |
There's a lot of code being used to determine the "end" of a series of read bytes. It's still early enough in the development to add an "end" byte without much refactoring of dependents
The text was updated successfully, but these errors were encountered: