Hi Romain, On Tue, Jul 12, 2011 at 1:37 PM, Romain Bornet <[email protected]> wrote: > Hi Miklos, > > Thanks for the advised hints! > >> However, if you want a proper driver development environment, then do >> not use any of the layers, and write your application that drivers the >> RadioDriverLayer directly. Look into the apps\tests\rfxlink directory, >> and the RadioSniffer and TestTransmit applications as examples. > > OK I'll have a look at these test applications and components. Thanks > for pointing them out. > >> You do not need the CollisionAvoidanceLayerC, simply use the dummy. >> You do not need the SoftwarewAckLayerC either, but then the >> PacketAcknowledgements interface has to be implemented somehow (in a >> dummy way). > > OK I'll use the DummyLayer for the CollisionAvoidance (in a first step). > >>> Are your radio driver is Ieee 802.15.4 compliant? > My radio chip is not 802.15.4 compliant but I think I'll use the > Ieee154 packet layout in a first step and will optimize later when > I'll have a working stack. My idea is to have a "802.15.4 compliant" > driver on a "non 802.15.4" chip. I think this is not a problem and I > can handle the Ieee154 layout completely in software. > > Regrads, > Romain > > On Tue, Jul 12, 2011 at 11:24 AM, Miklos Maroti > <[email protected]> wrote: >> Hi Romain, >> >> On Mon, Jul 11, 2011 at 5:18 PM, Romain Bornet <[email protected]> wrote: >>> Hi, >>> >>> I'm porting TinyOS to a new CPU architecture and I'm currently working >>> on the radio stack for the radio integrated in my SoC. >>> I took the RF230 from mainline TinyOS repository and the ATMega128 >>> RFA1 from http://sourceforge.net/projects/szte-wsn/ as references. >> >> That is a good starting point indeed. >> >>> These two implementations support a full-featured radio stack based on >>> rfxlink with, for example, packet timestamping, software/hardware >>> acks, collision avoidance, ... >>> >>> For my first tests with my radio driver implementation I would like to >>> have the simplest/minimal possible configuration to just test send and >>> receive paths. I saw that many components are optional and can be >>> replaced by DummyLayerC component instances. >> >> True, you can almost replace everything with the DummyLayerC, except >> there are some interfaces that will not be available (e.g. >> PacketAcknowledgements) >> >>> For my first test I will simply use point-to-point transmissions >>> between 2 nodes and won't need any "advanced" features. What is the >>> minimal/simplest configuration/wiring for this scenario ? >> >> You can keep the whole stack as it is, I think it will not interact >> badly with your driver, or just replace stuff with the dummy layer. >> However, if you want a proper driver development environment, then do >> not use any of the layers, and write your application that drivers the >> RadioDriverLayer directly. Look into the apps\tests\rfxlink directory, >> and the RadioSniffer and TestTransmit applications as examples. >> >> >>> >>> For now I could identify following setup for the send datapath: >>> (receive datapath is very similar) >>> >>> ActiveMessageLayerC >>> | >>> AutoResourceAcquireLayerC (optional: can be replaced by a DummyLayer >>> if Ieee154MessageLayerC is not used) >>> | >>> TinyosNetworkLayerC >>> | >>> UniqueLayerC >>> | >>> PacketLinkLayerC (optional: can be replaced by a DummyLayer if >>> reliable packet link is not used) >>> | >>> LowPowerListeningLayerC (optional: can be replaced by a >>> LowPowerListeningDummyC if we don't want to support LPL) >>> | >>> MessageBufferLayerC (mandatory) >>> | >>> CollisionAvoidanceLayerC (random or slotted. Is this a mandatory >>> component or can it be also replaced ???) >>> | >>> SoftwareAckLayerC >>> | >>> CsmaLayerC (can be bypassed with a DummyLayerC) >>> | >>> TrafficMonitorLayerC (can be bypassed with a DummyLayerC if no traffic >>> monitoring is necessary/wished) >>> | >>> RadioXXXDriverLayerC >>> >>> May I replace SoftwareAckLayerC and CollisionAvoidanceLayerC with >>> dummy implementations for the first tests ? It's clear that these >>> components are important in the stack but I would like to start with >>> the "dumbest" possible configuration and introduce new layers one by >>> one later. >> >> You do not need the CollisionAvoidanceLayerC, simply use the dummy. >> You do not need the SoftwarewAckLayerC either, but then the >> PacketAcknowledgements interface has to be implemented somehow (in a >> dummy way). Are your radio driver is Ieee 802.15.4 compliant?
Yes, this is the approach we are taking as well. If the need arises, then there will be an optimized packet layout available, which saves a few bytes. Otherwise, people will be able to use the 802.15.4 packet layout. Best, Miklos >> >> Best, >> Miklos >> >>> >>> Any hint is welcome :-) >>> >>> Kind regards, >>> Romain >>> >> > _______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
