Hello. On Sat, 2011-06-18 at 21:26, Dmitry Eremin-Solenikov wrote: > On 6/18/11, Stefan Schmidt <ste...@datenfreihafen.org> wrote: > > > > On Fri, 2011-06-17 at 20:30, Dmitry Eremin-Solenikov wrote: > >> > >> On 17.06.2011 19:55, Stefan Schmidt wrote: > >> * New drivers/hardware to support (at86rf230, rf212, cc25xx chips, etc.) > > > > Depends on people havceing access to the hardware as usual. > > Yes. On the other hand there are still plenty of tasks/features to be > implemented > for current hardware. I myself have cards with rf231 and rf230 and I > have unsoldered > rf212 chip. Maybe I'll solder it on one of the rf231 (no real radio > output, but it will > help driver porting).
Makes sense. At least for the complete init and configuration a simple SPI interface plus some gpios is normally all one need. > >> * Implement generic messaging code which can work across rs-232, USB, > >> etc, like HCI interface for bluetooth. It should be extensible and > >> simple enough (don't look at current serial protocol, it's a mess). > >> * Did I miss something? > > > > o CSMA-CA in combination with some MAC acceleration features (Werner > > did mention this as well) > > Well, as I wrote earlier, the only CSMA-CA that should be supported is the > one completely handled by radio/firmware. There is really no point > in implementing CCA support in our stack. Hmm, can we be sure that all hardware will handle this? On the other, if the timing requirements are that strict that even acks are implemented in hardware we should be on the save side here. :) > > o Re-transmit in case of missing ACK? As far as I understand the spec > > the ACK must arrive in a given timeframe and thats why most of the > > chips implement hardware ACKing. While the at86rf231 can handle > > retransmissions as well the cc2420 is not able to do this. Sounds like > > a mac8021544 feature to me. > > Yes, definitely. I'd generalise this a bit. mac802154 should handle > return codes from transmit. It can be either OK, timeout, etc. Agreed. Re-transmit was just an obvious one for me while comparing the two different chips. > > I will keep working on the cc2420 driver to get it reliable. Some > > patches should land here today. But its needs a lot more debugging and > > rewrite to work better (at all). > > :) Just send some patches out. The rest relays on problem I have with the pxa2xx_spi driver, or better my usage of it, being to slow to give me status informations back. > > I also got myself some of the ATUSB devices Werner designed (at86rf231 > > behind and ATmega32 and connected as USB stick to a linux host) and > > will help out there with the driver as well if needed. All this work > > is done for my diploma thesis and is only the groundwork for my actual > > work. Time has to show if I have some more spare cycles to tackle > > other tasks in the stack. > > I'll look on that devices. ATUSB seems interesting for me, but I have no > previous experience with AVR, so it really depends on the amount > of my spare time. I was able to set up the avr toolchain, compile and flash and image on it in around two hours. So the setup is pretty easy. Doing real development for the ATmega32 I leave to Werner right now. :) regards Stefan Schmidt ------------------------------------------------------------------------------ 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