Take a look at the TOSThreads TEP I wrote.  It goes into alot more
detail about how the threads are organized, including the boot
sequence.

http://www.tinyos.net/tinyos-2.1.0/doc/html/tep134.html

Kevin

On Mon, Mar 22, 2010 at 6:39 PM, sadun silva <[email protected]> wrote:
> 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
>



-- 
~Kevin

_______________________________________________
Tinyos-help mailing list
[email protected]
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Reply via email to