| |
Jacob S. Barrett <jsbarrett@acm.org> wrote:
> I thought it might be good to repost this with some changes...
>
> Okay a little smaller... Only a 4 byte header...
>
> |0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7|
> -----------------------------------------------------------------
> | 0xF | VER | TOADDR | PORT| FRADDR | PORT| PAYLOADLEN |
> -----------------------------------------------------------------
> / PAYLOAD /
> -----------------------------------------------------------------
> / PAYLOAD / CRC16 |
> -----------------------------------------------------------------
My only thoughts are that not everybody will need or want the generality of
port support in the protocol. I would suggest reordering the first four
bytes, moving the payload length up toward the front, and defining it to
explicitly include the two port bytes, as follows:
|0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7|
-----------------------------------------------------------------
| 0xF | VER | PAYLOADLEN | TOADDR | PORT| FRADDR | PORT|
-----------------------------------------------------------------
/ PAYLOAD /
-----------------------------------------------------------------
/ PAYLOAD / CRC16 |
-----------------------------------------------------------------
With this, plus possible changes to the definition of the first header byte
(the F-version byte), it will easy to implement a separate compatible
protocol that does not provide port support, e.g.:
|0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7|
-----------------------------------------------------------------
| 0xF | VER | PAYLOADLEN | PAYLOAD |
-----------------------------------------------------------------
/ PAYLOAD /
-----------------------------------------------------------------
/ PAYLOAD / CRC16 |
-----------------------------------------------------------------
Ports would then be a specific case of a more general protocol, with
essentially the same parse code being able to handle both types of
messages.
Regarding the CRC, I would use a CRC8 unless practice shows that a CRC16 is
required. I would look ahead to the day when a CRC16 is used and choose
the more important byte of the CRC16 to be the CRC8. Tagging an extra byte
onto the end of a message can then be completely backwards compatible
assuming you write the software correctly.
-Kekoa
|
|
Message has 2 Replies:
 | | Re: LNP Repost (Me banging on about checksums)
|
| (...) With much respect, I would suggest that CRC8 is probably not sufficient, especially if we go for a broadcast (Ethernet) solution, where lots of collisions, and hence errors, will probably occur - with CRC8 you will probably miss about 1 in 256 (...) (25 years ago, 29-Jul-99, to lugnet.robotics.rcx.legos)
| | | Re: LNP Repost
|
| (...) I'm not sure you can construct a sensible CRC16 that has a CRC8 as one byte. Cheers, Ben. -- (URL) grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first (...) (25 years ago, 30-Jul-99, to lugnet.robotics.rcx.legos)
|
Message is in Reply To:
| | LNP Repost
|
| I thought it might be good to repost this with some changes... Okay a little smaller... Only a 4 byte header... |0|1|2|3|4|5|6|7|0|1...3|4|5|6|7| ---...--- | 0xF | VER | TOADDR | PORT| FRADDR | PORT| PAYLOADLEN | ---...--- / PAYLOAD / ---...--- / (...) (25 years ago, 16-Apr-99, to lugnet.robotics.rcx.legos)
|
21 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
