Hello, On 6/17/11, Werner Almesberger <wer...@almesberger.net> wrote: > Dmitry Eremin-Solenikov wrote: >> * Did I miss something? > > CSMA ? ARQ without hardware assistance ? Security ? (Though I find the > concept of link-layer security dubious in most cases.)
No, No, Maybe. Basically CSMA-CA and ACK without hw assistance won't meet necessary time constraints. We did have implementation (kinda of) of those features in mac802154 for some time, but then I had to kill them, as they were useless and wrong. Regarding security. It a good direction to implement, but I'd defer it for some time. First, it's not a really urgent feature for simple communication. Second, there were already two different definitions of security in 802.15.4 standard. Who knows whether they had define new security standard in the -2011 version of standard or will define it soon. > > Since it would be a shame to leave things in an almost-usable-yet-not- > quite-there state, I've hacked a quick and dirty IPv4 tunnel I call > "dirtpan": > > http://projects.qi-hardware.com/index.php/p/ben-wpan/source/tree/master/tools/dirtpan/ I'll get a look on that. > Anyway, this is the general direction in which I'm heading. If I can > be of help with anything specific, please let me know. I have one thought on atusb stick you are working on. IIUC, you are trying to make an MCU a simple passthrough which will just forward register access commands to AT86 radio. I think that it may be better to implement more smart firmware at MCU (ATmega?) that will be able to support simple scenarios (just like commands supported by serial dongles). Then: 1) you won't have to implement strange split of AT86RF230 driver 2) one may implement more interesting features in firmware (like timed beacons, etc). I had some ideas on this (packets should be commands with data encoded with TLV, with some attributes being defined by standard, some optional attributes, etc. However directly implementing some kind of TLV (BER, DER) seems like too much of code to fit the kernel. OTOH I didn't try implementing this. Basically I was looking for expansible protocol, without special cases on protocol level (vs. serial proto) and with possibility for both sides to send data that the other side will be able to drop/ignore correctly. -- With best wishes Dmitry ------------------------------------------------------------------------------ EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev _______________________________________________ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
