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? 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 > _______________________________________________ Tinyos-devel mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
