Hi Romain! On Mon, Apr 18, 2011 at 8:28 AM, Romain Bornet <[email protected]> wrote: > Hi Miklos, > > Thanks for the quick and precise answer ! I think I have all pieces of > information I need to go on for now. > >>> Everything else is practically ready (I can write for you a packet layout >>> layer that is compatible with CC1000 and uses fewer bytes than 802.15.4). > If it doesn't take you much time I would really appreciate. It would > give me an additional reference to base my stuff on.
Ok, I will do that. Question for you: how do you want ACKs? Currently, it is packet oriented, that is the ACK is a separate (very small) packet. If I know correctly, then on the CC1000 the ACK is really just a pulse of energy. So what do you plan to do? What chipset are we talking about? >>> Unfortunately there is no current documentation, other than emails. I plan >>> to write it up soon, but found no time to do it yet. > Once I will have dived deep into rfxlink and understood its features > and details, I'm ready to help you and write part of the > documentation. In which format do you plan to write it ? As a TEP? > Something similar to the CC2420 TEP126 > (http://www.tinyos.net/tinyos-2.1.0/doc/html/tep126.html) or Packet > Link Layer TEP127 > (http://www.tinyos.net/tinyos-2.1.0/doc/html/tep127.html) or would you > prefer a separate documentation ? A TEP would be fine. Miklos > > Best regards, > Romain > > On Fri, Apr 15, 2011 at 5:23 PM, Miklos Maroti <[email protected]> > wrote: >> Ho Romain, >> >> On Fri, Apr 15, 2011 at 3:27 PM, Romain Bornet <[email protected]> wrote: >>> Hi TinyOS gurus, >>> >>> I'm currently porting TOS to a new CPU architecture (low-power SoC >>> with integrated radio) and will start soon with the writing of the >>> radio driver/stack for this chip. >>> The radio peripheral does not support advanced features in hardware >>> (no FIFOs, no hardware address recognition, no 802.15.4 features...) >>> and can only send/receive single bytes. By looking at the different >>> radios supported by TOS, I found that the CC1000 seems to provide >>> rather similar features and that it is also a "byte radio". >>> >>> The current CC1000 implementation is not based on rfxlink and I wonder >>> if it could be supported by rfxlink or not ? Or in other words: is >>> there any strong dependence on 802.15.4 in rfxlink that would prevent >>> its use with simpler Sub-1GHz byte radios ? >> >> You can use the rfxlink library to support non 802.15.4 radios. In >> fact we have an SI443x based mote and plan to use rfxlink for the >> driver. I would suggest you to use rfxlink as it is actively >> maintained, supports other chips and you get improvements will >> automatically (e.g BLIP support, LPL improvements). >> >>> And a second question... Is there some detailed documententation on >>> rfxlink, its architecture, its configuration options,... ? I can for >>> sure walk through the code and figure it out myself but if it's >>> already summarized somewhere I would probably jump in more quickly :-) >> >> Unfortunately there is no current documentation, other than emails. I >> plan to write it up soon, but found no time to do it yet. Here is some >> info I have copied from an older mail. I have updated stuff to match >> what is currently in the mainline: >> >> 1) Everything is in lib/rfxlink. The layers and util subdirectories >> are chip independent. All rf230 specific code is in the chips/rf230 >> directory. The RF230RadioC connects all components. On top of that are >> the RF230ActiveMessageC, RF230Ieee154MessageC and >> RF230TimeSyncMessageC. You want to look at RF230RadioC. >> >> 2) The RF230RadioC radio stack is a vertical layer of components. The >> components come from the layer directory. Most components need some >> configuration interface (to adopt it to the particular radio chip), >> which are implemented in RF230RadioP. There is very little >> interconnection between layers, so you can mix and match it. >> >> 3) The lowest layer is the RF230DriverLayerC, an important middle >> layer is the MessageBufferLayerC, and finally comes the >> ActiveMessageLayer and/or Ieee154MessageLayerC on top. Every >> communication between the RF230DriverLayerC and the >> MessageBufferLayerC is happening in interrupt context via the >> RadioSend/RadioReceive and RadioState interfaces. Everything above the >> MessageBuffer is in task context and communication is via BareSend and >> BareReceive (almost the same as Send and Receive). This is important, >> since we want fast software ACKs but only want to send it if we can >> surely deliver it (have some buffer space), so all of this is done in >> interrupt context, while the rest of the processing is done from >> tasks. >> >> 4) You can configure to run the interrupt context code in task context >> with a simple define (TASKLET_IS_TASK) or keep it in interrupt >> context. These tasklets are funny. When run in interrupt context you >> still do not need atomic sections (the whole RF230 driver contains a >> couple 2-3 line atomic sections), since we serialize tasklets. A >> tasklet can be scheduled and it will be run just before the original >> interrupt is about to return. We keep executing tasklets until there >> is no more and we can return from the original interrupt. >> >> 5) The only radio chip specific part of the whole architecture is the >> RF230DriverLayerC. It provides a Send/Receive/State functionality and >> other accessors to packet fields. Send is only a best effort: if the >> radio stack is busy then it immediately returns EBUSY, the same goes >> for busy channel. It never retries anything, if everything goes right >> then it should transmit the packet immediately with no delay. The >> RF230 radio can be busy because it is downloading an incoming frame, >> or executing another command (e.g. turn off/on, standby, cca). >> >> 6) The RF230DriverLayerC needs the platform specific HplRF230C >> component (from platforms/iris/chips/rf230) to access the SPI bus and >> the proper pins. The whole radio stack is using a single hardware >> alarm (also provided by the HplRF230C). To support a new IEEE 802.15.4 >> radio chip one has to write the XxxxDriverLayerC, the rest of the xxxx >> directory is almost an exact copy of the rf230 directory. >> >> I think this is enough for the high level overview. Let me know if you >> need more details. What you really need to write is your driver. >> Everything else is practically ready (I can write for you a packet >> layout layer that is compatible with CC1000 and uses fewer bytes than >> 802.15.4. >> >> Best, >> Miklos >> >>> >>> Regards from Switzerland, >>> Romain >>> >> > _______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
