Eric,
Thank you very much for the detailed explanation. I looked at the app.c file it is little hard to really understand the entire thing but I got an idea. I really need this because I have an idea where user level threads will run in a mote. These threads for example will run in different group ids. So I want the tinyosthread to do some kind of administrative tasks. Such as when a user level thread gets loaded the tinyosthread has to assign the group id (from a queue may be) to the user level thread. So that is why I need to know how the main tinyosthread is working so that I can make some changes. Thanks again On Mon, Mar 22, 2010 at 3:55 PM, Eric Decker <[email protected]> wrote: > With TosThreads there are at least two different levels of Boot.booted, > TinyOSMainP.TinyOSBoot.booted and TinyOSMainP.Boot.booted. > > The first, TinyOSMainP.TinOSBoot.booted, is what gets signalled after the > Thread start runs (it needs to run first before any of the normal TinyOS > initilization starts up because it wraps the TinyOS stuff inside a thread). > What gets run as part of TinyOSMainP.TinyOSBoot.booted is all the normal > TinyOS initilization code, platform.init etc. > > When the init code is done, then TinyOSMainP.Boot.booted is signaled when > tells the rest of the system to go ahead. > > For TOSThreads to work it wraps the main TOS task level (sync level) in a > thread, the TOSThread. > > You can figure all this out for yourself, by looking at the generated app.c > and searching for TinyOSMainP__TinyOSBoot__booted and following the calls > backwards. That provides some level of insight and perhaps makes > deciphering the wiring easier. > > TOSThreads was added sometime after the initilization code existed for > TinyOS 2. So what was done was to simply wrap the TinyOS initilization > code in some TOSThreads start up code. Once this code executes, then it > make good sense for the TinyOS startup code to run. It is similar to an > operating system with many more resources such as virtual memory. It first > establishes the environment for the executing code and then that code > executes its initilization code. > > And it really does just work. So I'll byte why do you "need" an answer for > this? > > eric > > On Mon, Mar 22, 2010 at 3:11 PM, sadun silva <[email protected]>wrote: > >> Hi all, >> >> >> Sorry for multiple copies. I really need to find an answer for this. >> > > I was going thru the TOSThreads code related to boot. When I looked through >> TinyOSMainP I found out that we are initializing platform & software >> specific components after boot.booted event. >> >> As far as I understand these things are already being done before the >> boot.booted event is signaled. >> >> >> >> Is this what is happening? If I’m wrong let me know. >> >> >> >> Thanks in advance. >> >> >> >> >> >> >> _______________________________________________ >> Tinyos-help mailing list >> [email protected] >> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help >> > > > > -- > Eric B. Decker > Senior (over 50 :-) Researcher > > >
_______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
