On 06/03/14 23:06, Phoebe Buckheister wrote: > On Thu, March 6, 2014 10:24 pm, Martin Townsend wrote: >> I was going to start implementing some low level features of the >> 802.15.4 MAC layer in SW such as Inter Frame Gap, Clear Channel >> Assessment (including the backoff algorithm), and Acknowledgements and >> use this to hopefully lay down a basic scheduler for higher level >> features for a beacon enabled PAN. I'm hoping to get away with just >> using the HR timers and maybe Linux RT if required. > Does your chip actually not implement any of that? I haven't yet seen a > chip that supports 802.15.4 and that cannot at least perform automatic > acknowldgement and CCA/multiple access schemes. Not yet, we are going to implement it in SW which will feedback into the HW design. > What do you mean with "scheduler for higher level features"? The scheduling of Beacons, Timeslots for CFP etc, but maybe this is not possible. >> Is anyone else already working on this? if not would anyone else find it >> useful? Also I would appreciate it if someone could explain what the >> slaves list found in the mac802154 private data structure is for? > The slave list contains wpan device instances. struct mac802154_priv > itself does not represent any device, it pretty much only holds on to a > PHY and a list of netdevs that are running on that PHY. I consider this > list a huge mistake, a break of semantics and a hindrance for development; > I'm drafting a proposal to remove this list and a more general > simplification of the stack. This works for me. > Takeaway: struct mac802154_sub_if_data is where you want to put netdev > specific things, but some stuff is probably best handled by the PHY > driver. I've recently added infrastructure to enabled MAC features of a > PHY chip, like CCA, automatic acknowledgement and retransmit and a few > other things. Even if your PHY does not support any such feature, I think > it is more sensible to do CCA/CSMA in the driver. ACK transmission also > must not happen in the main stack at the moment, because received packet > processing is done in a workqueue and thus involves scheduler. > Sure, if I can get it all working in my driver I'll create a framework that other drivers can use.
------------------------------------------------------------------------------ Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk _______________________________________________ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
