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