Hello,
On Thu, Jun 6, 2013 at 2:02 AM, Tony Cheneau <tony.chen...@amnesiak.org> wrote:
> Hello everyone,
>
> I just uploaded a draft version of a version 2 of the serial protocol
> that is used to command the Redbee Econotags with the "serial" driver on
> Linux. You can find the text here [1]. The specification for the version
> 1 can be found here [2] for a comparison (although I discussed the
> changes in the draft).
Great! I always thought that serial proto should be improved but never had time
and courage to improve that.
> I have not yet updated the code that currently makes use of the serial
> protocol (Econotag's firmware, serial driver, the virtual serial device
> [3] (currently experimental)), because I intend to do so when this draft
> document becomes more stable.
Great!
I have few suggestions, based on my past experience with proto V1.
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.
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).
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').
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]
Also what is the point of reversing the high bit in the 'received
block' event/response?
>
> Please don't hesitate to provide some feedback (preferably on the
> linux-zigbee mailing list).
>
> Regards,
> Tony
>
> P.-S.: I cc'ed the mc1322x mailing list, because I believe Econotag's
> user might be interested as well.
>
> [1]:
> https://github.com/linux-wpan/ieee802154-serial-protocol-version2/blob/master/ieee802154-serial-protocol-2.md
> [3]: https://github.com/tcheneau/virtual-ieee802154-serial
> [2]: http://sourceforge.net/apps/trac/linux-zigbee/wiki/SerialV1
--
With best wishes
Dmitry
------------------------------------------------------------------------------
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
