In my humble, humbling, and limited experience with academically driven software, upgrading to the new-improved version of something generally exposes one to the Latest Software Engineering Paradigms, since such software is generally developed by grad-students who need thesis topics, without actually providing much in the way of functionality to those of us who ply the trade without benefit of publication opportunities...
So, aside from applying my rusty hermeneutic skills to the TEPS, is there someplace I can find a good description of the advantages of re-experiencing the TOS learning cliff under T2? I mean, if I port my working systems to some-slightly-different-but-almost- the-same--except-oh-yeah-we-forgot--that version, what's in it for me and mine? MS Kevin Klues wrote: > "In response to an email posted on tinyos-help" > > I think one problem with all of these issues that seem to come up in > tinyos-1.x is that no one is really maintaining that tree much anymore. > There are no new releases, and whenever a bug is discovered, it doesn't > get fixed, and everyone has to follow some workaround procedure that > they discover from searching the tinyos help list. > > In fact, since June of 2006, less than 20 commits have been made to the > baseline tinyos-1.x tree, and none of these have been reflected in any > sort of release that people actually use. I'm sure there have been lots > of commits to the contrib tree, but this code tends to be even less > documented than the standard tinyos tree (which admittedly is not all > that great to begin with), and some users don't even know that it exists. > > My solution to all this would be to try and convince everyone to switch > over to tinyos-2.x, but I realize that some people are reluctant to do > so right away. Many of the crossbow sensor drivers only exist for > tinyos-1.x , and many users have written code for their own applications > that relies on the way the 1.x task scheduler operates (which is quite > different than the 2.x task scheduler). Code between the two versions > is therefore unfortunately not backwards compatible. So whats the right > answer here? Do we need someone who is really invested in tinyos-1.x to > step up and become the official maintainer of the tinyos-1.x tree -- > fixing bugs, etc. as they come in and pushing out new releases that have > the bug fixes in them? Or would it be better to start motivating people > to start porting everything over to tinyos-2.x, so that their reliance > on 1.x slowly fades away? > > As with most things, the real problem is motivation and time. People > who have been working with tinyos for quite awhile only tend to port > things in an on demand fashion when they realize that they need > something that existed in tinyos-1.x but doesn't in 2.x. This leaves > unexperienced users that may not have the know-how to do a port stuck > with using tinyos-1.x rather than switching to the much more stable, and > much better maintained codebase of 2.x. In in ideal world, everything > that runs on 1.x would already be ported over to 2.x, and new users > could jump right in without every having thought about using 1.x. This > is not an ideal world, however, and none of us are getting paid to do > any of these ports, hence they are not getting done in a timely fashion. > > Maybe money would be a good incentive to get some of these things ported > over though. If there are any companies out there that really feel they > would benefit from using 2.x rather than 1.x, but don't want to deal > with the complexities of digging into the code base and doing the > porting themselves, maybe they could hire out consultants to do the work > for them. I'm sure plenty of people on this list would be willing to > take some time to do these ports if they knew they could get a little > extra cash for it. Just a thought....... > > Kevin > > On Dec 16, 2007 9:35 AM, Michael Schippling <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > Well, isn't this nice... "portable" TOS demo apps have > some platform dependencies defined into them... > > SimpleCmd uses a "Pot" component that is specific to the > mica (NOT mica2 or micaz, _mica_) platform. You may be able > to just go edit out references to "Pot", since it was used > to adjust the radio output of the mica. Or you can copy the > Pot*.nc files into a telos platform directory and stub them. > > There's no replacement for repeated-head-banging experimentation > when working with TOS. > > Lovely. > > I'll move on to your other questions under separate cover... > MS > > Renee Azhen wrote: > > yeah, when I am uploding the sapmle > > /opt/tinyos-1.x/apps/SimpleCmd > > I use this comman: make telosb install > > and following info was output in the screenshot: > > mkdir -p build/telosb > > compiling SimpleCmd to a telosb binary > > ncc -o build/telosb/main.exe -O -Wall -Wshadow > -DDEF_TOS_AM_GROUP=0x7d > > -Wnesc-al > > l -target=telosb -fnesc-cfile=build/telosb/app.c -board= > -I%T/lib/Deluge > > -Wl,--s > > ection-start=.text=0x4800,--defsym=_reset_vector__=0x4000 > > -DIDENT_PROGRAM_NAME=\ > > "SimpleCmd\" -DIDENT_USER_ID=\"ibm\" > > -DIDENT_HOSTNAME=\"ibm-vs2a1bhcns0\" -DIDEN > > T_USER_HASH=0x245ca709L -DIDENT_UNIX_TIME=0x4764c622L > > -DIDENT_UID_HASH=0x629f1f3 > > 3L -mdisable-hwmul -I/opt/tinyos-1.x/tos/lib/CC2420Radio > SimpleCmd.nc -lm > > C:/PROGRA~1/UCB/cygwin/opt/tinyos-1.x/tos/system/PotC.nc:90: > component > > HPLPotC n > > ot found > > C:/PROGRA~1/UCB/cygwin/opt/tinyos-1.x/tos/system/PotC.nc:93: no match > > make: *** [exe0] Error 1 > > I want to demo the SimpleCmd sample in the node, so do you know > how to > > fix this problem?? > > thanks > > Sam > > */Michael Schippling <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>>/* 写道： > > > > There is a dreaded DemoSensor impl in the T1 msp430 directory > > so that should handle the demo apps which use such, like > O'scope. > > After that, it's probably an exercise for the reader of the > > tutorial to swap out sensors. > > > > Other than the specifics of sensing devices, which would > > necessarily be application dependent anyway, TOS _should_ > > hide platform details (or else one of it's design criteria > > is a moot point). Did you have specific errors with some > > of the apps? > > > > MS > > > > Urs Hunkeler wrote: > > > Hi Sam, > > > > > > You could try boomerang from the former Moteiv. Their > Tmote Skys > > should > > > be compatible with the telosb platform. > > > > > > http://docs.tinyos.net/index.php/Boomerang > > > > > > Cheers, > > > Urs > > > > > > > > > Renee Azhen schrieb: > > >> dear friend: > > >> yeah, but my sensor can not use the Photo mudule, it is only > > humidity senses. > > >> many samples in /apps if installed into my sensor will > occur an > > error. I found that most of the sample code is only suitable to > > mica/micasb, so do you know where I can get the corresponding > code > > for my telosb node? > > >> > > >> thanks > > >> Sam > > >> > > >> Urs Hunkeler 写道： > > >> Hi Sam, > > >> > > >> The MicaZ uses the same radio chip (cc2420). Usually > > applications for > > >> the MicaZ also work on the Telosb platforms. The main > > differences are > > >> the sensors, but they should be relatively straight > forward to > > change. > > >> Of course the Telosb platform use a different > microcontroller > > (msp430 > > >> instead of an ATmega), but most differences should be handled > > >> transparently by the compiler. > > >> > > >> The examples in the tutorials should work. I have the > impression > > that > > >> there are more examples for Telosb in TinyOS 2.x. > > >> > > >> Cheers, > > >> Urs > > >> > > >> Renee Azhen schrieb: > > >>> dear all: > > >>> My platform is a telosb node. > > >>> Most Sample code in /opt/tinyos 1.x/apps/ is for mica&mica2, > > then can not work on telosb platform. > > >>> > > >>> so I want to get some sample application that are > suitable to > > telosb platform, could you tell me where and how I can get > > them??(Website, link or ....) > > >>> > > >>> Thanks > > >>> Sam > > > _______________________________________________ > > > Tinyos-help mailing list > > > Tinyos-help@millennium.berkeley.edu > <mailto:Tinyos-help@millennium.berkeley.edu> > > > > > > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help > <https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help> > > > > -- > > Platform: WinXP/Cygwin > > TinyOS version: 1.x, Boomerang > > Programmer: MIB510 > > Device(s): Mica2, MicaZ, Tmote > > Sensor board: homebrew > > > > _______________________________________________ > > Tinyos-help mailing list > > Tinyos-help@millennium.berkeley.edu > <mailto:Tinyos-help@millennium.berkeley.edu> > > > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help > > > > > > > ------------------------------------------------------------------------ > > 天生购物狂，狂抢购物券，你还等什么！ > > < > > http://cn.mail.yahoo.com/promo/taobao20/index.php?souce=mail_mailletter_tagline> > > > > -- > Platform: WinXP/Cygwin > TinyOS version: 1.x, Boomerang > Programmer: MIB510 > Device(s): Mica2, MicaZ, Tmote > Sensor board: homebrew > > _______________________________________________ > Tinyos-help mailing list > Tinyos-help@millennium.berkeley.edu > <mailto:Tinyos-help@millennium.berkeley.edu> > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help > <https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help> > > > > > -- > ~Kevin -- Platform: WinXP/Cygwin TinyOS version: 1.x, Boomerang Programmer: MIB510 Device(s): Mica2, MicaZ, Tmote Sensor board: homebrew _______________________________________________ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
