Hello Dmitry,
Thanks for your comments. They are especially appreciated since you
designed the version 1 of the protocol. Please see my comments inline.
[...]
> Sometimes we had problems with synchronisation/recovery/etc. If a
> character is lost,
> it takes some (1-2) packets to resync kernel and a device.
I don't doubt your word, but I don't think I have witnessed such
issues. It could be because the Econotag's UART code has been improved
lately. Regardless, it's good to design robust protocol and we can't
account for upcoming devices, so your point makes sense.
> Second topic is protocol upgrades/compatibility. Having no clear
> field
> for packet length/
> fast resync makes impossible for the device/host to quickly drop
> unsupported packets
> (and report them back to the other partner).
Yes, that's right. I have never gave to much thoughts on the
unsupported commands. I'll add a length field on the next revision (or
move it at the beginning of the command in the commands where it's
already present).
> I have two suggestions (we can agree on either of them or on both).
>
> 1) I suggest for 's' to be used only as a packet start character.
> Let's pick up something like
> SLIP/PPP have:
>
> For transmitter:
> 's' = start of the packet. If it happens in the packet, transmitter
> should replace it. 's' => 'ec'
> 'e' = escape char. If it happens in the packet, replace it with 'e'
> => 'ee'
>
> For the receiver:
> 's' => start of the packet. If it is found, finish the current packet
> (possibly truncated/damaged)
> and start parsing new packet
> 'e' => escape char. Replace:
> 'ee' => 'e'
> 'ec' => 's'
>
> After 's' comes protocol version ('s' '2').
Byte stuffing makes perfect sense here. I would tend to favor Mariano's
suggestion and use Consistent Overhead Byte Stuffing (COBS). I haven't
read the paper in details yet, but the implementation seems lightweight
and it does not add much overhead.
>
> 2) Packet length. I would suggest to change the protocol a bit:
> After command id comes packet length (after unescaping all characters
> if we agree to escape them).
> Thus it will be possible to skip 'till the next packet'.
>
> Examples:
> Command: 0x00[=NOOP] 0x00[=no args]
> Response: 0x80[=rNOOP] 0x01[=1 byte] 0x80[=SUCCESS]
>
> Command: 0x04[=XMIT] 0x33[=len] .....[=0x33 bytes]
> Response: 0x84[=rXMIT] 0x02[=2 bytes] 0x80[=status] 0xed[=level]
Agreed. I'll add this one in the next version of the text.
> Also what is the point of reversing the high bit in the 'received
> block' event/response?
It makes it extra easy to match a request to its response and to
compute the response message in the case you don't even support the
command (provided that all your command have the same "header", such as
"s2" and <status>, you can indicate a failure). Perhaps that not needed
if you report errors in a different manner.
Regards,
Tony
------------------------------------------------------------------------------
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j
_______________________________________________
Linux-zigbee-devel mailing list
Linux-zigbee-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
