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

"End" byte #11

Open
rwaldron opened this issue May 17, 2014 · 12 comments
Open

"End" byte #11

rwaldron opened this issue May 17, 2014 · 12 comments

Comments

@rwaldron
Copy link
Collaborator

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

@rwaldron
Copy link
Collaborator Author

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.

@voodootikigod
Copy link
Owner

Would love to dialogue about it. Its a worthwhile thought.
On May 17, 2014 1:14 PM, "Rick Waldron" [email protected] wrote:

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.


Reply to this email directly or view it on GitHubhttps://github.com//issues/11#issuecomment-43415643
.

@rwaldron
Copy link
Collaborator Author

Cool, I'll ping you when I have a clearer idea. Basically the short version is a "buffer" that looks like...

[action, pin, ...arbitrary number of data bytes, END]

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.

@voodootikigod
Copy link
Owner

Other possibly better idea is to do a fixed length packet. Only "issue" is
serial/spi writes.
On May 17, 2014 2:13 PM, "Rick Waldron" [email protected] wrote:

Cool, I'll ping you when I have a clearer idea. Basically the short
version is a "buffer" that looks like...

[action, pin, ...arbitrary number of data bytes, END]

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.


Reply to this email directly or view it on GitHubhttps://github.com//issues/11#issuecomment-43417129
.

@rwaldron
Copy link
Collaborator Author

I think that's enough issue to pass on fixed length. Also it won't scale, eg. if we wanted pulseIn pattern support.

@reconbot
Copy link

The other common way is to include the length of the packet in the header.

[action, pin, length of data, data]

@rwaldron
Copy link
Collaborator Author

I think I like this more.

@voodootikigod
Copy link
Owner

We should move it to first position and two byte in order to allow for full
sending capability in the Api.

I can revise this side if someone can handle the spark-io side

On Saturday, October 11, 2014, Rick Waldron [email protected]
wrote:

I think I like this more.


Reply to this email directly or view it on GitHub
#11 (comment)
.

Chris Williams

@voodootikigod http://twitter.com/voodootikigod | GitHub
http://github.com/voodootikigod

The things I make that you should check out:
SaferAging http://www.saferaging.com/ | JSConf http://jsconf.com/ |
RobotsConf http://robotsconf.com/ | RobotsWeekly
http://robotsweekly.com/

Help me end the negativity on the internet, share this
http://jsconf.eu/2011/an_end_to_negativity.html.

@rwaldron
Copy link
Collaborator Author

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?

@voodootikigod
Copy link
Owner

[messagelength, messagelength, action, pin, data, ..., data]

message length = uint16

Chris Williams

@voodootikigod http://twitter.com/voodootikigod | GitHub
http://github.com/voodootikigod

The things I make that you should check out:
SaferAging http://www.saferaging.com/ | JSConf http://jsconf.com/ |
RobotsConf http://robotsconf.com/ | RobotsWeekly
http://robotsweekly.com/

Help me end the negativity on the internet, share this
http://jsconf.eu/2011/an_end_to_negativity.html.

On Sun, Oct 12, 2014 at 8:47 AM, Rick Waldron [email protected]
wrote:

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?


Reply to this email directly or view it on GitHub
#11 (comment)
.

@rwaldron
Copy link
Collaborator Author

This design would prevent us from sending 2 bytes for data values in the future, because the received bytes would be ambiguous:

...data LSB, data MSB, length LSB, length MSB, action, pin, data LSB, data MSB, data LSB, data MSB, length LSB, length MSB....

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:

...data LSB, data MSB, action, pin, length LSB, length MSB, data LSB, data MSB, data LSB, data MSB, action, pin, length LSB, length MSB, data LSB, data MSB, data LSB, data MSB....

@canda
Copy link
Contributor

canda commented Mar 25, 2015

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants