"End" byte

[rwaldron]

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]

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]

Would love to dialogue about it. Its a worthwhile thought.
On May 17, 2014 1:14 PM, "Rick Waldron" notifications@github.com 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]

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]

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" notifications@github.com 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]

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

[reconbot]

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

[action, pin, length of data, data]

[rwaldron]

I think I like this more.

[voodootikigod]

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 notifications@github.com
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]

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]

[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 notifications@github.com
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]

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]

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.