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