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

Reply via email to