Dmitry Eremin-Solenikov wrote: > 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.
Hmm, if I get all the equations right, that maximum turn-around time at the receiver should be 500 us for the 2.4 GHz PHY. That doesn't sound impossible, but one would certainly have to optimize the stack a little, change it towards a more asynchronous model, and pushing the choice whether to sleep or not into the drivers. > Who knows whether they had define new security standard in the -2011 > version of standard or will define it soon. Heh ;-) Here's a fitting oxymoron: long-lived wireless link-layer security :-) > 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. Yup. > I think that it may be better > to implement more smart firmware at MCU (ATmega?) Yes, it's an ATmega32U2. By the way, I made an overview page of the Ben-WPAN project: http://downloads.qi-hardware.com/people/werner/wpan/web/ > 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). The register access side of the split is very easy and clean. I'm having more trouble finding a clean division at the entry (SPI driver) side. I'm considering to just make it look like an SPI host, then special-case only SLP_TR, nRST, and maybe the interrupt. The "smart" firmware idea is something I was thinking of for the longer term. There are certain heavily used sequences that could be optimized that way, e.g., RX mode -> interrupt -> read IRQ_STATUS -> ah, it's TRX_END -> copy the frame -> send TRX_END content plus frame over USB. At the moment, the driver does very little but TX/RX, so doing all the work in the MCU would look good. However, in the long run, it would have to take care of more complex setup tasks (address match, ARQ, CSMA, etc.), and also one or two periodic management tasks that interfere with the simple RX/TX state machine, i.e., the calibrations. I don't like the idea of duplicating the configuration code or of creating a "wide" device interface that tracks the interface between IEEE 802.15.4 stack and driver. But if the setup code could be shared among AT86RF23x drivers, a combination of "dumb" register access and a "smart" main loop may not look too bad. What do you think ? > 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. Hmm, sounds a bit heavy. I'd rather have the kernel do as much as possible, with a lean firmware. Debugging kernel code is easier than debugging firmware code :-) - Werner ------------------------------------------------------------------------------ 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
