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<http://www.tinyos.net/tinyos-2.x/doc/txt/tep116.txt> 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<http://www.tinyos.net/tinyos-2.1.0/doc/html/tep131.html> > ). > > 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
