Good afternoon,
I'm currently working on improving/cleaning the serial driver [1] which
implement the serial protocol [2] on some Econotag board. During this
work, a
few question and comments popped to my mind, and I believe this ML is
the
proper place to foster a interesting conversation.
First, I'm wondering if the Econotag is the only board that relies on
the
serial protocol. The linux-zigbee wiki mentions the "MC13192 eval.
boards", but
I do not know how widely that is used and if the firmware part can be
modified
(in case there is some changes to the serial protocol).
Secondly, I'm wondering if there would be room (and interests of the
community)
in a serial protocol v2 (more about this below). The way, I see it,
there is
some limitations in the current protocol and, I believe some
improvements could
be done on both driver and firmware sides. If only the Econotag is
using the
serial driver, then it does not cost much to modify the serial
protocol,
because the firmware can easily be modified as well. If other devices
make use
of this code, then it might be more problematic.
For example, the CCA command is not very useful (IMHO), because some
timing
requirements can never be met: If I look at the current serial.c code,
in order
to send a packet I would:
- run a CCA
- wait for the status of the CCA (not implemented in the Econotag, so
it always
returns OK)
- send my packet to the board
By doing this, it seems hard to respect the CCA timing at all (assuming
the
link to the board is running at 115200 bauds), because:
- 4 bytes for the CCA response: ~ 34 us
- 80 bytes for a transmission block packet (for a 76 bytes long
packet): ~ 694us
The time it takes after a successful CCA to get the board to actually
try to
send the packet is way more that the CCA + Turnaround time (8 + 12
symbols or
128 + 192 us) in the protocol.
For example, in this case, I suggest a simplification of the protocol.
That is
the CCA command is removed and is instead placed within the firmware,
at the
beginning the "Transmit Block" command. In the case of the Econotag,
CCA is not
implemented anyway so that would not make any difference.
Another example, this time, to introduce a new feature: automatic
hardware
acknowledgment. In order to make use of the auto-acknowledgment feature
(which
I implemented on the Econotag linux serial firmware), I propose three
new
commands (and the corresponding responses):
- set PANID
- set short address
- set 64-bit address
In the end, I came up with a list of changes I'd like to see in the
serial
protocol/serial driver:
- remove Set State command (not needed, device is always receiving,
except when
it's trying to send; the device can take care of changing the mode by
itself)
- remove CCA command (included in the Transmit Block, that should do a
full
CSMA-CA if possible)
- add a Set PANID command (MAC filtering/auto-ack feature)
- add a Set short address command (MAC filtering/auto-ack feature)
- add a Set long address command (MAC filtering/auto-ack feature)
- a return status that say the command is not implemented
I might be completely off, that's why I'm trying to get others people
opinion here.
Ultimately, my questions are: would anyone be interested in seeing
these kind
of changes? Would it make sense for me to contribute these changes once
I've
done them?
Regards,
Tony
[1]: the one in drivers/ieee802154/serial.c
[2]: http://sourceforge.net/apps/trac/linux-zigbee/wiki/SerialV1
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Linux-zigbee-devel mailing list
Linux-zigbee-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
