On Sun, Mar 4, 2012 at 11:30 PM, jonsm...@gmail.com <jonsm...@gmail.com> wrote: > On Sun, Mar 4, 2012 at 12:45 PM, Prajosh Premdas > <premdas.praj...@gmail.com> wrote: >> On Sun, Mar 4, 2012 at 11:08 PM, jonsm...@gmail.com <jonsm...@gmail.com> >> wrote: >>> On Sun, Mar 4, 2012 at 12:19 PM, Prajosh Premdas >>> <premdas.praj...@gmail.com> wrote: >>>> On Sun, Mar 4, 2012 at 9:59 PM, Felix Varghese <felixv1...@gmail.com> >>>> wrote: >>>>> Hi, >>>>> >>>>>> BTW: I remember rf231/rf212 chips having ACK/filter MAC acceleration. >>>>>> Does >>>>>> Atmel have a chip with support for beaconing or beaconed networks? >>>>> >>>>> You are right, they both support auto ACK, CSMA-CA, retries and >>>>> address filtering. They do support beacon-enabled networks in that >>>>> they can send out slotted auto-ACKs, etc. But in this case, the burden >>>>> of providing the exact timing falls on the micro-controller. It should >>>>> pulse a pin to trigger the actual sending of the ACK. This is probably >>>>> because of the fact that only the stack would know the relevant >>>>> timings such as slot-boundaries. >>>>> >>>>>>> As far as a single radio joining two PANs is concerned, in case the >>>>>>> aforementioned hardware acceleration is used, it cannot be done, >>>>>>> unless the radio itself supports dual addresses, pan ids, etc. If such >>>>>>> a radio does arrive in the market, can we not have two instances of >>>>>>> wpan phy itself, one bound to each such 'logical' radio? >>>>>> 76.164.216.197:8181 >>>>>> >>>>>> >>>>>> No, because it would be still a single radio with single channel >>>>>> settings. >>>>> >>>>> Ok, I think I got your point there, thanks. >>>>> >>>>>>>> No. At this moment IEEE 802.15.4 does not qualify as a sane default, >>>>>>>> because MAC implementation is far from being complete. >>>>>>> >>>>>>> We were hoping to help you guys rectify that problem :) >>>>>> >>>>>> We really appreciate your efforts. Maybe we should meet on IRC or on ML >>>>>> to discuss your intentions, your goals and your plan. What do you think? >>>>> >>>>> We think that is a good idea! >>>> >>>> In short, we are trying to get add a 802.15.4 stack to Linux to >>>> support various radios like at86rf23x/212 cc2420/2520, support modules >>>> like ZigBit and extend support for USB based sticks. So i think we >>>> should join forces and build this stack. >>> >>> Have you considered using SOC 802.15.4 chips attached to your Linux >>> host as a way of avoiding the real-time issues? Beaconed mode is going >>> to require some difficult code on the Linux side in order to maintain >>> the tight timing requirements. Most SOC 802.15.4 chips are available >>> in USB sticks making development easy. >>> >>> An approach would be to fully implement the 802.15.4 MAC in Contiki >>> (it is partially there). Then run the MAC on a dedicated SOC 802.15.4 >>> chip. Use Linux to talk to this hard MAC implementation. >>> >> Yes when we have to consider SOCs like ATmegaRF series and some from >> Ti too. This can be treated as a set of modules i mentioned. But the >> first priority i think should be on the native Linux > > cc2530, mc13224 and stm32w are all in common use. They don't cost that > much more than the non-SOC chips. > > Doing a full MAC on native Linux with radio-only chips is probably > going to require the real-time kernel in order to meet timing > restrictions. You also have to allow for the different speed links > into the chips - serial, SPI, USB, etc. It is much easier to move the > hard real-time code onto a SOC. 95% of the code will still run on > Linux, you just off-load the problem bits into the SOC. > I agree with you that SOCs are low cost. I think the support is already present as raw packets. If you create a raw 802.15.4 socket and then i think it can be extended for any SOC. There is some development required here as the format of raw frames being send to radio has to be designed.
Since today most of the radios are smart the crucial timing parameters are handled by the radio. Rest of the timings are handle able by the linux box with not so real time os. >>> >>>> >>>> We have completed the reset, get, set pib and associate functions in >>>> mac. We have so far send patches of nl based changes only. >>>> >>>> I think we should use IIRchat and sync up on the design before >>>> proceeding further. >>>> >>>> A new 802.15.4g std is in pipeline with a higher mpdu size and lots of >>>> additional modes. >>>>> >>>>> Regards, >>>>> Felix. >>>> >>>> >>>> >>>> -- >>>> Regards, >>>> >>>> Prajosh Premdas >>>> >>>> ------------------------------------------------------------------------------ >>>> Virtualization & Cloud Management Using Capacity Planning >>>> Cloud computing makes use of virtualization - but cloud computing >>>> also focuses on allowing computing to be delivered as a service. >>>> http://www.accelacomm.com/jaw/sfnl/114/51521223/ >>>> _______________________________________________ >>>> Linux-zigbee-devel mailing list >>>> Linux-zigbee-devel@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel >>> >>> >>> >>> -- >>> Jon Smirl >>> jonsm...@gmail.com >> >> >> >> -- >> Regards, >> >> Prajosh Premdas > > > > -- > Jon Smirl > jonsm...@gmail.com -- Regards, Prajosh Premdas ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
