On Tue, Jan 22, 2013 at 4:24 PM, Miklos Maroti <[email protected]>wrote:
> On Tue, Jan 22, 2013 at 5:03 PM, Eric Decker <[email protected]> wrote: > > > > Is there any mechanism for LPL with respect to 6lowpan? > > I do not know, I think they are orthogonal. > > > Or is LPL intimately linked to the AM stack? AM is a light weight > > protocol stack. > > LPL is implemented inside the AM stack > > > I'm fine by the way with getting rid of the ifdefs by moving the > > functionality to a set of appropriate interfaces exposed via the protocol > > stack edge. > > I think we should get rid of the ifdefs. Any opposition? > I definitely agree. they are very ugly and problematic. > > Miklos > > > > > > > On Tue, Jan 22, 2013 at 12:17 PM, Miklos Maroti < > [email protected]> > > wrote: > >> > >> I think we just need to move more interfaces to ActiveMessageC. If the > >> given radio does not support those interfaces, then we will get a > >> compile time error. There is no need to introduce yet more components. > >> > >> Just grepping through the tree I see these tests: > >> > >> - apps/tests/TestLpl/TestLplAppC.nc: we need the LowPowerListening > >> interface, rfxlink based radios provide these in their ActiveMessageC, > >> cc2420 and cc1000 based ones do not, and there is the odd case of > >> EYESIFX platform where the active message layer is called LplC. We > >> should fix these that all platforms expose their LowPowerListening > >> interface through their ActiveMessageC. > >> > >> - apps/tutorials/LowPowerSensing/Base/LowPowerSensingBaseAppC.nc and > >> > >> > apps/tutorials/LowPowerSensing/Sampler/LowPowerSensingPeriodicSamplerAppC.nc: > >> the same as above, this need the LowPowerListening interface too > >> > >> - apps/tutorials/RssiDemo/RssiBase/RssiBaseAppC.nc and > >> apps/tutorials/RssiDemo/RssiBase/RssiBaseC: new problem, there is no > >> standard way to get the RSSI value of the received packet, rfxlink > >> based radios use the PacketField interface, CC2420 uses its specific > >> one. We would need to select the appropriate interface (I propose to > >> use the PacketField interface). > >> > >> - tos/lib/net/ctp/CtpP.nc: this needs the LinkPacketMetadata > >> interface, we should just expose this interface also thorugh > >> ActiveMessageC, although there are cases where some > >> DummyActiveMessageC is used. However, Doug would know what to do. > >> > >> So in summary, I think we should get rid of these ifdefs by moving the > >> required interface to the ActiveMessageC component. > >> > >> Miklos > >> > >> > >> On Mon, Jan 21, 2013 at 1:13 PM, Eric Decker <[email protected]> wrote: > >> > > >> > anyone want to take a stab up coming up with a reasonable abstraction? > >> > > >> > > >> > On Mon, Jan 21, 2013 at 2:26 AM, András Bíró <[email protected]> > >> > wrote: > >> >> > >> >> If we're changing ActiveMessageC provided interfaces, we probably > >> >> should > >> >> add getRssi/getLqi, using these features needs similarly ugly ifdefs > >> >> for > >> >> platform independent code (see apps/tutorials/RssiDemo/RssiBase). > >> >> However we > >> >> have different interface for cc2420, rfxlink and tda5250, so it's a > bit > >> >> more > >> >> difficult. > >> >> > >> >> Andras Biro > >> >> > >> >> > >> >> On Sat, Jan 19, 2013 at 3:10 PM, Miklos Maroti > >> >> <[email protected]> > >> >> wrote: > >> >>> > >> >>> In this case moving the appropriate interface to ActiveMessageC is > the > >> >>> right solution. Down the road I will look all uses of ifdefs that > >> >>> select radio specific versions of the ActiveMessageC, and see what > is > >> >>> really going on. Miklos > >> >>> > >> >>> On Sat, Jan 19, 2013 at 3:02 AM, Eric Decker <[email protected]> > >> >>> wrote: > >> >>> > > >> >>> > We should define an appropriate mechanism for encapsulating the > >> >>> > platform > >> >>> > specific stuff down in platform (tos/platform) and/or via the > >> >>> > Platform > >> >>> > mechanism that I've started defining. > >> >>> > > >> >>> > On Fri, Jan 18, 2013 at 4:28 PM, Vlado Handziski > >> >>> > <[email protected]> wrote: > >> >>> >> > >> >>> >> This discussion about the use of ifdefs to solve > platform-specific > >> >>> >> behavior has popped up frequently here on -devel. Given that one > of > >> >>> >> the main > >> >>> >> features of TinyOS/NesC is the component-oriented code > >> >>> >> organization, > >> >>> >> component shadowing/selection should always have precedence > before > >> >>> >> low-level > >> >>> >> C solutions like #defines and #ifdefs. I fully agree with Doug, > >> >>> >> that > >> >>> >> the > >> >>> >> proper solution is to encapsulate the platform-specific code in a > >> >>> >> component > >> >>> >> (or component part) that resides in /tos/platform. I am not very > >> >>> >> much > >> >>> >> in > >> >>> >> favor of standardizing radio chip defines. It is true that many > >> >>> >> platforms > >> >>> >> share radio chips, and having a common define value will simplify > >> >>> >> these > >> >>> >> ifdefs, but this is not the proper direction to be moving to, > imho. > >> >>> >> > >> >>> >> --Vlado > >> >>> >> > >> >>> >> > >> >>> >> On Fri, Jan 18, 2013 at 9:30 PM, Doug Carlson < > [email protected]> > >> >>> >> wrote: > >> >>> >>> > >> >>> >>> Howdy. > >> >>> >>> Glancing at the code you pointed out, this is due to the fact > that > >> >>> >>> Ctp > >> >>> >>> needs LinkPacketMetadata interface, and according to TEP116 this > >> >>> >>> isn't one > >> >>> >>> of the interfaces that the platform ActiveMessageC components > need > >> >>> >>> to > >> >>> >>> provide. > >> >>> >>> > >> >>> >>> A little grepping indicates that all of the chip-specific > >> >>> >>> ActiveMessage > >> >>> >>> components provide LinkPacketMetadata EXCEPT for these three: > >> >>> >>> > >> >>> >>> chips/cc2520/CC2520ActiveMessageC.nc > >> >>> >>> chips/xe1205/XE1205ActiveMessageC.nc > >> >>> >>> chips/tda5250/Tda5250ActiveMessageC.nc > >> >>> >>> > >> >>> >>> For this particular case, it would make sense to me to add > >> >>> >>> LinkPacketMetadata to the list of expected interfaces in TEP116, > >> >>> >>> add > >> >>> >>> the > >> >>> >>> relevant wire-throughs to the > >> >>> >>> tos/platforms/xxx/ActiveMessageC.nc's, > >> >>> >>> and add > >> >>> >>> LinkPacketMetadata to those three radios. > >> >>> >>> > >> >>> >>> There's always going to be a certain amount of > platform-dependence > >> >>> >>> to > >> >>> >>> deal with, but this seems like something that's still relatively > >> >>> >>> platform-independent. If it turns out that there's a lot more > >> >>> >>> complexity > >> >>> >>> than the case with LinkPacketMetadata, then #defining the radio > in > >> >>> >>> use in a > >> >>> >>> more uniform fashion also makes sense to me. I'd probably put it > >> >>> >>> in > >> >>> >>> the > >> >>> >>> hardware.h file for each platform (see TEP 131). > >> >>> >>> > >> >>> >>> Maybe the best way forward would be to look at all the cases > where > >> >>> >>> explicit platform-checks like this happen and see if there's > >> >>> >>> really > >> >>> >>> only one > >> >>> >>> or two largely platform-independent matters (such as > >> >>> >>> LinkPacketMetadata) > >> >>> >>> which should be moved up to the platform ActiveMessageC or > whether > >> >>> >>> there's > >> >>> >>> tons of platform-specific behavior, in which case we might also > >> >>> >>> want > >> >>> >>> a > >> >>> >>> uniform convention for defining the relevant variables in > >> >>> >>> hardware.h. > >> >>> >>> > >> >>> >>> Anyway, that's my opinion. > >> >>> >>> > >> >>> >>> -Doug > >> >>> >>> > >> >>> >>> On Fri, Jan 18, 2013 at 2:14 PM, Martin Cerveny < > [email protected]> > >> >>> >>> wrote: > >> >>> >>>> > >> >>> >>>> Hello. > >> >>> >>>> > >> >>> >>>> There are many distributed "#ifdef PLATFORM_XXX" that > complicates > >> >>> >>>> adding > >> >>> >>>> new platforms. > >> >>> >>>> For example (tos/lib/net/ctp/CtpP.nc): > >> >>> >>>> > >> >>> >>>> ================ > >> >>> >>>> if defined(CC2420X) > >> >>> >>>> components CC2420XActiveMessageC as PlatformActiveMessageC; > >> >>> >>>> #elif defined(PLATFORM_TELOSB) || defined(PLATFORM_MICAZ) > >> >>> >>>> #ifndef TOSSIM > >> >>> >>>> components CC2420ActiveMessageC as PlatformActiveMessageC; > >> >>> >>>> #else > >> >>> >>>> components DummyActiveMessageP as PlatformActiveMessageC; > >> >>> >>>> #endif > >> >>> >>>> #elif defined (PLATFORM_MICA2) || defined (PLATFORM_MICA2DOT) > >> >>> >>>> components CC1000ActiveMessageC as PlatformActiveMessageC; > >> >>> >>>> #elif defined(PLATFORM_EYESIFXV1) || > defined(PLATFORM_EYESIFXV2) > >> >>> >>>> components WhiteBitAccessorC as PlatformActiveMessageC; > >> >>> >>>> #elif defined(PLATFORM_IRIS) || defined(PLATFORM_MESHBEAN) > >> >>> >>>> components RF230ActiveMessageC as PlatformActiveMessageC; > >> >>> >>>> #elif defined(PLATFORM_MESHBEAN900) > >> >>> >>>> components RF212ActiveMessageC as PlatformActiveMessageC; > >> >>> >>>> #elif defined(PLATFORM_UCMINI) > >> >>> >>>> components RFA1ActiveMessageC as PlatformActiveMessageC; > >> >>> >>>> #else > >> >>> >>>> components DummyActiveMessageP as PlatformActiveMessageC; > >> >>> >>>> #endif > >> >>> >>>> ============== > >> >>> >>>> > >> >>> >>>> More similar: > >> >>> >>>> ./tos/lib/serial/SerialPacketInfo802_15_4P.nc > >> >>> >>>> ./tos/lib/net/ctp/CtpP.nc > >> >>> >>>> ./tos/lib/net/ctp/CtpForwardingEngine.h > >> >>> >>>> ./tos/lib/net/Deluge/DelugePageTransfer.h > >> >>> >>>> ./tos/lib/net/Deluge/FlashVolumeManager/FlashVolumeManagerP.nc > >> >>> >>>> > ./tos/lib/net/Deluge/BlockStorageManager/BlockStorageManagerC.nc > >> >>> >>>> > ./tos/lib/net/Deluge/BlockStorageManager/BlockStorageManagerP.nc > >> >>> >>>> ./tos/lib/net/blip/nwprog/NWProgC.nc > >> >>> >>>> ./tos/lib/net/blip/ReadLqiC.nc > >> >>> >>>> ./tos/lib/tosboot/TosBootP.nc > >> >>> >>>> ./support/sdk/java/net/tinyos/tools/ListenRaw.java > >> >>> >>>> ./support/make/threads.extra > >> >>> >>>> ./apps/tests/rfxlink/TestPacketTimeSync/NoSleepP.nc > >> >>> >>>> ./apps/tests/rfxlink/RadioSniffer/RadioSnifferC.nc > >> >>> >>>> ./apps/tests/rfxlink/TestTransmit/TestRadioDriverC.nc > >> >>> >>>> ./apps/tests/rfxlink/TestTransmit/RadioDriverConfigP.nc > >> >>> >>>> ./apps/tests/TestLpl/TestLplAppC.nc > >> >>> >>>> ./apps/AntiTheft/Root/AntiTheftRootAppC.nc > >> >>> >>>> ./apps/AntiTheft/Nodes/AntiTheftAppC.nc > >> >>> >>>> > >> >>> >>>> > >> >>> >>>> > >> >>> >>>> > ./apps/tutorials/LowPowerSensing/Sampler/LowPowerSensingPeriodicSamplerAppC.nc > >> >>> >>>> > ./apps/tutorials/LowPowerSensing/Base/LowPowerSensingBaseAppC.nc > >> >>> >>>> ./apps/tutorials/RssiDemo/RssiBase/RssiBaseC.nc > >> >>> >>>> ./apps/tutorials/RssiDemo/RssiBase/RssiBaseAppC.nc > >> >>> >>>> > >> >>> >>>> Is it possible to create some centralized conditional "#define > >> >>> >>>> RADIO_XXX" > >> >>> >>>> to resolve "radio" type (somewhere in tos/system/...) ? > >> >>> >>>> Or > >> >>> >>>> Is it possible to create some ditributed define "-DRADIO_XXX" > to > >> >>> >>>> tos/platforms/*/.platform ? > >> >>> >>>> > >> >>> >>>> Thanks for you opinion, M.C> > >> >>> >>>> _______________________________________________ > >> >>> >>>> Tinyos-devel mailing list > >> >>> >>>> [email protected] > >> >>> >>>> > >> >>> >>>> > >> >>> >>>> > >> >>> >>>> > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel > >> >>> >>> > >> >>> >>> > >> >>> >>> > >> >>> >>> _______________________________________________ > >> >>> >>> Tinyos-devel mailing list > >> >>> >>> [email protected] > >> >>> >>> > >> >>> >>> > >> >>> >>> > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel > >> >>> >>> > >> >>> >> > >> >>> >> > >> >>> >> _______________________________________________ > >> >>> >> Tinyos-devel mailing list > >> >>> >> [email protected] > >> >>> >> > >> >>> >> > >> >>> >> > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel > >> >>> >> > >> >>> > > >> >>> > > >> >>> > > >> >>> > -- > >> >>> > Eric B. Decker > >> >>> > Senior (over 50 :-) Researcher > >> >>> > > >> >>> > > >> >>> > _______________________________________________ > >> >>> > Tinyos-devel mailing list > >> >>> > [email protected] > >> >>> > > >> >>> > > >> >>> > > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel > >> >>> > > >> >>> _______________________________________________ > >> >>> Tinyos-devel mailing list > >> >>> [email protected] > >> >>> > >> >>> > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel > >> >> > >> >> > >> > > >> > > >> > > >> > -- > >> > Eric B. Decker > >> > Senior (over 50 :-) Researcher > >> > > > > > > > > > > > -- > > Eric B. Decker > > Senior (over 50 :-) Researcher > > > -- Eric B. Decker Senior (over 50 :-) Researcher
_______________________________________________ Tinyos-devel mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
