Hi Romain, On Wed, Apr 20, 2011 at 1:43 PM, Romain Bornet <[email protected]> wrote: > 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 .
I agree. > >> 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. I did not know this. I knew that at some point it was different (maybe I am confusing stuff with LPL?) >> 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 Wow, very interesting chip. > 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. Yes, that is nice. The atmega128rfa1 has memory mapped radio control registers. Look at its driver here as a starting point. http://szte-wsn.svn.sourceforge.net/viewvc/szte-wsn/tinyos-2.x/trunk/tos/chips/atm128rfa1/radio/RFA1DriverLayerP.nc This is work in progress, so maybe you want to look at the fully implemented tos/chips/rf230 or tos/chips/rf212 directories. > - 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. I think this is not a problem, provided that you can handle the datarate (e.g. interrupts). I would recommend the Ieee154Packet format for now, and if you want to save a few bytes (the fcf field can be shorter, the ack packet format can be different, etc) then we can write a new packet format. Best, Miklos >>>>> 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
