Hi Vlado, On Wed, Jan 23, 2013 at 7:25 AM, Vlado Handziski <[email protected]> wrote: > I agree with the general direction. We should of course be very careful at > each step, because a lot of code will be impacted by this. As for the
I think nothing will break if we expose extra interfaces at ActiveMessageC which were already available from XXXActiveMessageC. I will do this now for LowPowerListening and see how it goes. > eyesIFX/tda5250 peculiarities, I would not be that concerned, the platform > is not used that much anymore and it will be deprecated and removed even Good question on how to retire old platforms. > from TWIST soon. BTW, after finalization, TEPs can not be modified. But a > new TEP can depreciate an old one. I did not know of the immutability of TEPs. Strange. Why was this design selected? Miklos > > --Vlado > > > On Wed, Jan 23, 2013 at 1:54 PM, Doug Carlson <[email protected]> wrote: >> >> Sounds reasonable to me. >> >> I'd also be OK with putting the LinkPacketMetadata and PacketField >> interfaces into a new PacketMetadataC (defined under platforms/xxx/). Non-AM >> stacks could still use these, if I'm not mistaken. >> >> Putting LowPowerListening in the ActiveMessageC interfaces sounds >> reasonable to me-- part of the AM stack, frequently used, relatively >> platform independent. >> >> It would be good to update the TEPs to be consistent with whatever changes >> are made. Is there a preferred method for updating TEPs? >> >> -Doug >> >> On Wed, Jan 23, 2013 at 12:21 AM, Eric Decker <[email protected]> wrote: >>> >>> >>> >>> 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
