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
