Hi Miklos and people on the list ! First, a big thanks for your prompt and helpful answers! Answers to your questions inline below...
On Mon, Apr 18, 2011 at 3:38 PM, Miklos Maroti <[email protected]> wrote: > 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. In a first step I will for sure rely on packet oriented ACK mechanism. Even if it is not the best solution, it is the most comfortable to implement and to debug . > If I know correctly, then on the CC1000 the ACK is really just a pulse of > energy. As far as I could see, the standard CC1000 implementation also relies on packet-oriented ACKs (ackCode[5] array in CC1000SendReceiveP.nc). I think I will therefore be able to take over much of the logic of CC1000 stack. > So what do you plan to do? First, a packet-oriented software-driven ACK, then, if required, a more evolved mechanism > What chipset are we talking about? The radio for which I'm going to write a driver is integrated in a ultra low-power system-on-chip designed at CSEM (Swiss Center for Electronics and Microtechnology). The chip has a 32 bits processor cores, some standard peripherals (UART,I2C, SPI,...) and an integrated 868-915 MHz transceiver. You can have a look at the spec sheet for more details: Product note: http://csem.ch/docs/Show.aspx?id=12228 Technical report: http://csem.ch/docs/Show.aspx?id=12657 Unfortunately, detailed datasheets have not already been published but I can still give you some general information. - The radio registers are directly accessible (mapped at fixed address in the memory layout of the core). Therefore no dedicated interface (SPI,UART,I2C,...) is required to talk to the radio. - TX and RX are based on 32 bits words (1 TX and 1 RX register). - The chip does not handle any MAC feature in hardware (no CRC, no framing, no ACKs,...) and these are let to the software implementation. - The chip supports configurable-length preambles for synchronization and pattern/sync word for start of frame detection. >>>> 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. OK, I'll go on with a TEP when I'll start to write doc. Regards Romain > 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
