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. >> 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 ? 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
