Re: [Tinyos-help] question on enqueue_receive_event from UscGainInterfaerenceModelC.nc

2006-07-05 Thread Philip Levis

On Jul 5, 2006, at 10:55 PM, Liu Haibin wrote:

But I still don't understand why there is a difference between  
first case (label 1) and second case (label 2)? label 2 is without  
sensitivity and other transmissions compared with label 1.


Can I say that label 1 is to receive a packet, but label 2 is to  
detect preamble? So does it mean that power level required for  
receiving a packet and that for detecting preamble are different?


Yes, that is what label 1 and label 2 mean. But as I said in my  
previous mail, the distinction they have in power level is a mistake.


Phil

___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help


Re: [Tinyos-help] question on enqueue_receive_event from UscGainInterfaerenceModelC.nc

2006-07-05 Thread Liu Haibin
But I still don't understand why there is a difference between first case (label 1) and second case (label 2)? label 2 is without sensitivity and other transmissions compared with label 1.Can I say that label 1 is to receive a packet, but label 2 is to detect preamble? So does it mean that power level required for receiving a packet and that for detecting preamble are different? 
Regards,HaibinOn 7/6/06, Philip Levis <[EMAIL PROTECTED]> wrote:
On Jul 5, 2006, at 8:08 PM, Liu Haibin wrote:> Hi,>> I'm confused with the following code from enqueue_receive_event> from UscGainInterfaerenceModelC.nc. The condition at label 1 is
> understandable. It checks if the power is large enough against the> destination noise plus all the other transmissions to the> destination. What I don't understand is the condition label 2. Why> does it need to compare the power with the max destination noise?
> What is the variable "receiving" used for?>> I have very limited knowledge in the area of radio transmission. I> guess I missed some very basic concepts here. Could someone help me
> out with it?>>> Regards,> Haibin>>> // If I'm off, I never receive the packet, but I need to keep> track of> // it in case I turn on and someone else starts sending me a
> weaker> // packet. So I don't set receiving to 1, but I keep track of> // the signal strength.> if (!sim_mote_is_on(sim_node())) {>   dbg("Gain", "Lost packet from %i due to %i being off\n",
> source, sim_node());>   rcv->lost = 1;> }> else {> 1if ((sigStr + sim_gain_sensitivity()) >= power) {>  dbg("Gain", "Lost packet from %i due to power being too
> low (%f >= %f)\n", source, sigStr, power);>  rcv->lost = 1;>   }>   else if (receiving) {>  dbg("Gain", "Lost packet from %i due to being in the midst
> of a reception.\n", source);>  rcv->lost = 1;>   }> 2if (power >= sim_gain_noise_mean(sim_node()) +> sim_gain_noise_range(sim_node())) {>  receiving = 1;
>   }> }>The receiving variable keeps track of whether the node thinks it isreceiving a packet or whether it is searching for packet preambles.You can only start receiving a packet if you are in the latter state
(unless you can recover preambles during packets, which no existingradio stack besides Kamin's prototype mica2 stack can do).The second case is for when the packet is strong enough to hear. Ifthe signal strength is not above noise, then you do not detect the
preamble.Actually, this looks like very optimistic approach. The logicshould be more like:if (signal is below noise + threshold) {   lose packet}else if (already receiving) {   lose packet
}else {   receive packet;}Note that the current approach resamples the noise but does notconsider the signal threshold. In the end, the difference between thetwo is pretty small (the number of preambles you detect of packets
that might be lost), but still, I should look at it carefully.Phil
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help


Re: [Tinyos-help] question on enqueue_receive_event from UscGainInterfaerenceModelC.nc

2006-07-05 Thread Philip Levis


On Jul 5, 2006, at 8:08 PM, Liu Haibin wrote:


Hi,

I'm confused with the following code from enqueue_receive_event  
from UscGainInterfaerenceModelC.nc. The condition at label 1 is  
understandable. It checks if the power is large enough against the  
destination noise plus all the other transmissions to the  
destination. What I don't understand is the condition label 2. Why  
does it need to compare the power with the max destination noise?  
What is the variable "receiving" used for?


I have very limited knowledge in the area of radio transmission. I  
guess I missed some very basic concepts here. Could someone help me  
out with it?



Regards,
Haibin


// If I'm off, I never receive the packet, but I need to keep  
track of
// it in case I turn on and someone else starts sending me a  
weaker

// packet. So I don't set receiving to 1, but I keep track of
// the signal strength.
if (!sim_mote_is_on(sim_node())) {
  dbg("Gain", "Lost packet from %i due to %i being off\n",  
source, sim_node());

  rcv->lost = 1;
}
else {
1if ((sigStr + sim_gain_sensitivity()) >= power) {
 dbg("Gain", "Lost packet from %i due to power being too  
low (%f >= %f)\n", source, sigStr, power);

 rcv->lost = 1;
  }
  else if (receiving) {
 dbg("Gain", "Lost packet from %i due to being in the midst  
of a reception.\n", source);

 rcv->lost = 1;
  }
2if (power >= sim_gain_noise_mean(sim_node()) +  
sim_gain_noise_range(sim_node())) {

 receiving = 1;
  }
}



The receiving variable keeps track of whether the node thinks it is  
receiving a packet or whether it is searching for packet preambles.  
You can only start receiving a packet if you are in the latter state  
(unless you can recover preambles during packets, which no existing  
radio stack besides Kamin's prototype mica2 stack can do).


The second case is for when the packet is strong enough to hear. If  
the signal strength is not above noise, then you do not detect the  
preamble.


Actually, this looks like a very optimistic approach. The logic  
should be more like:


if (signal is below noise + threshold) {
  lose packet
}
else if (already receiving) {
  lose packet
}
else {
  receive packet;
}

Note that the current approach resamples the noise but does not  
consider the signal threshold. In the end, the difference between the  
two is pretty small (the number of preambles you detect of packets  
that might be lost), but still, I should look at it carefully.


Phil

___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help


Re: [Tinyos-help] difference between #include and includes

2006-07-05 Thread Philip Levis

On Jul 5, 2006, at 6:55 PM, Manju wrote:


Hi,

In tinyos-2.x to include a header file, at certain places we use  
includes, while at other places we use #include.


Is there any difference between the two? Are there any scenarios or  
conditions, where we should use one over the other


The basic difference is whether the file is loaded once (includes) or  
each time (#include).


includes was part of an attempt to make header files more reasonable,  
back when we were also trying to remove the use of #define. This  
turned out to not be feasible (in particular, you can't use enums for  
floating point values). In TinyOS 2.x, includes should be deprecated.  
There are places where it is still used because it doesn't matter,  
but hopefully before the full release we'll clean it up.


TinyOS 1.x uses them both. Basically, use #include if you have  
#defines. Otherwise you can use either.


Phil
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help


RE: [TinyOS-help] Compile Error for SurgeTelos

2006-07-05 Thread Ben Kelley








That error seems to indicate that TOS_MSG
somehow has been defined twice, but they don’t match.  

 

Have you modified these files at all?

 

I don’t think either TOSMAKE_PATH
matters, either the moteiv one, if you have boomerang installed or just plain
tinyos, without one.

What version of tinyos?

 











From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ming
Sent: Wednesday, July 05, 2006
20:42
To: Adam
Cc:
tinyos-help@Millennium.Berkeley.EDU
Subject: Re: [TinyOS-help] Compile
Error for SurgeTelos



 

Thank you for you kind
reply.

I have tried to export TOSMARK_PATH, but the problem is still appear. Are there
any other problem cause the Error?



On 7/5/06, Adam
<[EMAIL PROTECTED]> wrote:

export
TOSMAKE_PATH=/opt/tinyos- 1.x/contrib/moteiv/tools/make
Should solve this.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:
[EMAIL PROTECTED]] On Behalf Of Joe
Polastre
Sent: Wednesday, July 05, 2006 9:19 AM
To: Ming
Cc: tinyos-help@Millennium.Berkeley.EDU

Subject: Re: [TinyOS-help] Compile Error for SurgeTelos

For some reason it isn't finding %T/lib/MultiHopLQI

On 7/4/06, Ming <[EMAIL PROTECTED]>
wrote: 
> Hi everyone
>
> When I try to compile the SurgeTelos on the Telos verB, I get the
> following error. How can I solve it?
>
> > # make telosb
> > mkdir -p build/telosb
> > compiling Surge to a telosb binary ncc -o
build/telosb/main.exe
> > -O -I%T/lib/MultiHopLQI -DSEND_QUEUE_SIZE=8
> -DMHOP_LEDS -Wall -Wshadow -DDEF_TOS_AM_GROUP=0x7d -Wnesc-all
> -target=telosb -fnesc-cfile=build/telosb/app.c -board= -I%T/lib/Deluge 
> -Wl,--section-start=.text=0x4800,--defsym=_reset_vector__=0x4000
> -DIDENT_PROGRAM_NAME=\"Surge\"
-DIDENT_USER_ID=\"root\"
> -DIDENT_HOSTNAME=\"new-host-11\"
> -DIDENT_USER_HASH=0xb4e3d2a8L -DIDENT_UNIX_TIME=0x44aac6c4L 
> -DIDENT_UID_HASH=0xfc1bbc3eL -mdisable-hwmul -I/opt/tinyos-
> 1.x/tos/lib/CC2420Radio Surge.nc -lm
> >
> /opt/tinyos-1.x/tos/lib/MultiHopLQI/MultiHopEngineM.nc:82: 
> `TOS_Msg' defined as wrong kind of tag
> >
> /opt/tinyos-1.x/tos/lib/MultiHopLQI/MultiHopEngineM.nc:83:
> `TOS_Msg' defined as wrong kind of tag
> > make: *** [exe0] Error 1
> > 
>
> Thank you.
>
> CM
>
> ___
> Tinyos-help mailing list
> Tinyos-help@Millennium.Berkeley.EDU

> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-h
> elp
>
>
>
___ 
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help




 








___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help


Re: [Tinyos-help] Can events preempt tasks?

2006-07-05 Thread Chalermphol Thammapalerd
Hi folks,
 
Ravi, You're right man! 
Although I use the boomerang distribution, the UserButtonM is a bit different.So I use the MSP430InterruptC to receive interrupt from the hard-button instead and "the event preempt that infinite task" now.

 
Thanks,
Chalermphol 
On 7/5/06, Ravi Prasad <[EMAIL PROTECTED]> wrote:

Check the following code extracted from UserButtonM.nc://-  event result_t Timer.fired()  {    atomic    {  call MSP430Interrupt.clear();  call MSP430Interrupt.enable
();    }    return SUCCESS;  }  task void debounce()  {    call Timer.start( TIMER_ONE_SHOT, 100 );  }  async event void MSP430Interrupt.fired()  {    atomic    {  signal 
UserButton.fired();  // debounce  call MSP430Interrupt.disable();  post debounce();    }//--Here for debouncing the button it disables the interrupt and uses a task (task debounce) to re-enable the interrupt. Now as our infinite task is running, this will never happen and thus no interrupt will occur again. Thats why it works for exactly ONE time (after our infinite task has been posted). and then stops. 
you can modify the code for async event void MSP430Interrupt.fired  like below ://--async event void MSP430Interrupt.fired()  {    atomic    {  signal UserButton.fired();
  // debounce  call MSP430Interrupt.disable();  //post debounce();      //I am implementing debounce here.   //A bad code but good fix for testing the concept :-)  TOSH_uwait(5);
  call MSP430Interrupt.clear();  call MSP430Interrupt.enable();    }//-I am only having the micaz motes and not the telos motes so I cannot test my suggested code. But it should work.

Chalermphol Thammapalerd <[EMAIL PROTECTED]
> wrote:



Sure man,
Please check info.txt
 
Chalermphol 


On 7/5/06, Ravi Prasad <
[EMAIL PROTECTED]> wrote: 



Can u send me the code. May be I can figure out the problem


Chalermphol Thammapalerd <[EMAIL PROTECTED] 
> wrote: 



Yes, it simply toggle the LED.
Note that I'd be happy to share my code because it's very important part of the system to prove.
 
Regards,
Chalermphol 


On 7/4/06, Ravi Prasad <
[EMAIL PROTECTED]> wrote: 



Is the event B is doing its job inside an ISR  or a lower level event called from ISR ?? OR it is trying to post a task for its job??It seems your's is the second case.I suggest you to simply toggle an LED in your event. 

Chalermphol Thammapalerd <[EMAIL PROTECTED] > wrote: 

Hi folks,
 
Thanks for the answer, but I'm sorry for my vague question.
Ravi, In your excellent case, the task is absolutely preempted.
But how about the unfinished task(actually I mean to the never-finish task)?
My test is,
 
A. A never-finish task which is periodically posted 
   {
   while(1) {
   //do a thing
   }
   }
 
B. Asynchronous Event
    SomeExternalInterrupt.fired {
    //do another thing    }
 
In this case, B is able to generate the event to "do another thing" but only once and the mote seems like hang.
I'm not sure if this kind of programming should never be used or there're some trick(s) to avoid this deadlock? or is it a deaklock anyway?
 
Regards,
Chalermphol 
On 7/4/06, Ravi Prasad <[EMAIL PROTECTED]> wrote: 


Make an application as follows:1. Implement a task        task free_run_timer(){          a. initiate a  _free_  runing timer to count.          b. wait a fixed amount of time.          c. stop timer. 
          d. Read and send the value of timer/counter to radio/uart.       }**Do not use any atomic statement in this task.schedule a timer to post this task periodically.2. Implement an event which is having a fixed delay in it. A short cut is to use the UART as an interrupt source. Everytime you send a character to mote from a PC by serial port it will generate an interrupt and thus an 
event.Remember to use the uart/radio interface in your application and start it properly.Now if there is no event generated (do not send any radio or UART packet to mote) then the counter value will be same every time. When you generate an event(possibly by sending a uart packet) you can easily see the counter value to be changed which proves the task was preemted to serve the event. 
**Probably you will have to genererate a series of events so that few of them fall inside the time when task is running.
Chalermphol Thammapalerd <[EMAIL PROTECTED] > wrote:
 



Hi,
 
I tried to prove one of the TinyOS concept, "Events preempt tasks, tasks do not", by using external event to preempt unfinished task.
However, the task is not seem to be preempted at all.
Are there any example(s) that prove this concept?
 
Regards,
Chalermphol
___Tinyos-help mailing listTinyos-help@Millennium.Berkeley.EDU 
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help 




__Do You Yahoo!?Tired of spam? Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 




Talk is cheap. Use Yahoo! M

[Tinyos-help] question on enqueue_receive_event from UscGainInterfaerenceModelC.nc

2006-07-05 Thread Liu Haibin
Hi,I'm confused with the following code from enqueue_receive_event from UscGainInterfaerenceModelC.nc. The condition at label 1 is understandable. It checks if the power is large enough against the destination noise plus all the other transmissions to the destination. What I don't understand is the condition label 2. Why does it need to compare the power with the max destination noise? What is the variable "receiving" used for?
I have very limited knowledge in the area of radio transmission. I guess I missed some very basic concepts here. Could someone help me out with it?Regards,Haibin    // If I'm off, I never receive the packet, but I need to keep track of
    // it in case I turn on and someone else starts sending me a weaker    // packet. So I don't set receiving to 1, but I keep track of    // the signal strength.    if (!sim_mote_is_on(sim_node())) { 
  dbg("Gain", "Lost packet from %i due to %i being off\n", source, sim_node());  rcv->lost = 1;    }    else {1    if ((sigStr + sim_gain_sensitivity()) >= power) {     dbg("Gain", "Lost packet from %i due to power being too low (%f >= %f)\n", source, sigStr, power);
     rcv->lost = 1;  }  else if (receiving) {     dbg("Gain", "Lost packet from %i due to being in the midst of a reception.\n", source);     rcv->lost = 1;
  }2    if (power >= sim_gain_noise_mean(sim_node()) + sim_gain_noise_range(sim_node())) {     receiving = 1;  }    }
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help


[Tinyos-help] difference between #include and includes

2006-07-05 Thread Manju
Hi,
 
In tinyos-2.x to include a header file, at certain places we use includes, while at other places we use #include.
 
Is there any difference between the two? Are there any scenarios or conditions, where we should use one over the other
 
thanks,
Manju.
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help


Re: [TinyOS-help] Compile Error for SurgeTelos

2006-07-05 Thread Ming
Thank you for you kind reply.I have tried to export TOSMARK_PATH, but the problem is still appear. Are there any other problem cause the Error?On 7/5/06, 
Adam <[EMAIL PROTECTED]> wrote:export TOSMAKE_PATH=/opt/tinyos-
1.x/contrib/moteiv/tools/makeShould solve this.-Original Message-From: [EMAIL PROTECTED][mailto:
[EMAIL PROTECTED]] On Behalf Of JoePolastreSent: Wednesday, July 05, 2006 9:19 AMTo: MingCc: tinyos-help@Millennium.Berkeley.EDU
Subject: Re: [TinyOS-help] Compile Error for SurgeTelosFor some reason it isn't finding %T/lib/MultiHopLQIOn 7/4/06, Ming <[EMAIL PROTECTED]> wrote:
> Hi everyone>> When I try to compile the SurgeTelos on the Telos verB, I get the> following error. How can I solve it?>> > # make telosb> > mkdir -p build/telosb
> > compiling Surge to a telosb binary ncc -o build/telosb/main.exe> > -O -I%T/lib/MultiHopLQI -DSEND_QUEUE_SIZE=8> -DMHOP_LEDS -Wall -Wshadow -DDEF_TOS_AM_GROUP=0x7d -Wnesc-all> -target=telosb -fnesc-cfile=build/telosb/app.c -board= -I%T/lib/Deluge
> -Wl,--section-start=.text=0x4800,--defsym=_reset_vector__=0x4000> -DIDENT_PROGRAM_NAME=\"Surge\" -DIDENT_USER_ID=\"root\"> -DIDENT_HOSTNAME=\"new-host-11\"> -DIDENT_USER_HASH=0xb4e3d2a8L -DIDENT_UNIX_TIME=0x44aac6c4L
> -DIDENT_UID_HASH=0xfc1bbc3eL -mdisable-hwmul -I/opt/tinyos-> 1.x/tos/lib/CC2420Radio Surge.nc -lm> >> /opt/tinyos-1.x/tos/lib/MultiHopLQI/MultiHopEngineM.nc:82:
> `TOS_Msg' defined as wrong kind of tag> >> /opt/tinyos-1.x/tos/lib/MultiHopLQI/MultiHopEngineM.nc:83:> `TOS_Msg' defined as wrong kind of tag> > make: *** [exe0] Error 1> >
>> Thank you.>> CM>> ___> Tinyos-help mailing list> Tinyos-help@Millennium.Berkeley.EDU
> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-h> elp>>>___
Tinyos-help mailing listTinyos-help@Millennium.Berkeley.EDUhttps://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help


Re: [Tinyos-help] TOSSIM Mica1, Mica2 Radios bug?

2006-07-05 Thread Shane B. Eisenman
1. Naturally, "send done (success)" does not imply "receive (crc = pass)".
What you see is not a bug.

2. The lossy model applies bit errors probabilistically (emulating a lossy
PHYSICAL channel) outside of any MAC issues you might introduce in your
simulation by having/allowing >=2 nodes transmit at the same time to the
same receiver.

> Hi all,
>
> I found that TOSSIM Mica1 and Mica2 radios lose packets in a particular
> scenario even when there is no lossy model used. The scenario is one
> mote broadcasts a request message and all the receivers sends a reply
> message to the sender. In this scenario, some of the reply messages sent
> by the receivers are lost in the network even though sendDone() gets
> called for all senders. I have attached a sample program and makefile
> that demonstrates the bug. In mica1 radio the number of motes required
> to cause message loss is 21 while in mica2 radio, it is only 15 motes.
> In real program that we implemented where there several other events, as
> small as 7 motes can cause the same problem for both radios.
>
> I traced the bug in Mica2 radio to two motes sending at the same time
> and as a result, the messages gets garbled. However, sendDone() gets
> called for both the senders with result 1(success) even though no motes
> received that message.
>
> Anyone knows a solution or work around for this bug?
>
> Thank you,
> Vinai.
>
> ___
> Tinyos-help mailing list
> Tinyos-help@Millennium.Berkeley.EDU
> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
>



http://www.comet.columbia.edu/~shane

___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help


[Tinyos-help] TOSSIM Mica1, Mica2 Radios bug?

2006-07-05 Thread Vinai Sundaram

Hi all,

I found that TOSSIM Mica1 and Mica2 radios lose packets in a particular 
scenario even when there is no lossy model used. The scenario is one 
mote broadcasts a request message and all the receivers sends a reply 
message to the sender. In this scenario, some of the reply messages sent 
by the receivers are lost in the network even though sendDone() gets 
called for all senders. I have attached a sample program and makefile 
that demonstrates the bug. In mica1 radio the number of motes required 
to cause message loss is 21 while in mica2 radio, it is only 15 motes. 
In real program that we implemented where there several other events, as 
small as 7 motes can cause the same problem for both radios.


I traced the bug in Mica2 radio to two motes sending at the same time 
and as a result, the messages gets garbled. However, sendDone() gets 
called for both the senders with result 1(success) even though no motes 
received that message.


Anyone knows a solution or work around for this bug?

Thank you,
Vinai.

COMPONENT=MsgLoss


# To use Mica2 Radio, uncomment next line
PFLAGS += -I%T/platform/pc/CC1000Radio 

# To use Packet-level Radio, uncomment next line
#PFLAGS+= -I%T/platform/pc/packet 

include ../Makerules


/** 
   File: MsgLoss.nc
   Author: Vinai Sundaram ( vsundar at purdue dot edu )
   Description: 
   The goal of this application is to determine the message loss \ 
   when several motes send message to the same receiver in TOSSIM \
   using mica, and mica2 radios. 
   Note: Packet-level radio doesn't experience packet loss. 

*/

configuration MsgLoss {

}

implementation {

components Main, GenericComm as Comm, MsgLossM, SysTimeC ;


Main.StdControl -> Comm;
Main.StdControl -> MsgLossM;

MsgLossM.CommSend -> Comm.SendMsg[1];
MsgLossM.CommReceive -> Comm.ReceiveMsg[1];
MsgLossM.SysTime -> SysTimeC;

}
/**
   File: MsgLossM.nc
   Author: Vinai Sundaram ( vsundar at purdue dot edu )
   Description: 
This file describes the MsgLossM module.

*/

module MsgLossM {

provides {
interface StdControl;   
}
uses {

interface SendMsg as CommSend;
interface ReceiveMsg as CommReceive;
interface SysTime;

}

}

implementation {


uint8_t count;
uint16_t dstAddr;
TOS_Msg sendBuf; // for sending out messages

struct SampleMsg {
uint8_t senderID;
uint32_t sendTime;
uint32_t recvTime;
};


command result_t StdControl.init( ) {

count = 0;
dstAddr = TOS_BCAST_ADDR;

return SUCCESS;
}


command result_t StdControl.start( ) {

struct SampleMsg* msg1;


// Only node 0 sends a message  
if ( TOS_LOCAL_ADDRESS == 0 ) {
msg1 = (struct SampleMsg *) sendBuf.data;
msg1->senderID = TOS_LOCAL_ADDRESS;
msg1->sendTime = call SysTime.getTime32(); 

 if ( call CommSend.send( dstAddr , sizeof( struct 
SampleMsg), &sendBuf ) == FAIL ) {
dbg( DBG_USR1, "Control.start: send failed\n" );
}
}

return SUCCESS;
}


command result_t StdControl.stop( ) {

return SUCCESS;
}


event result_t CommSend.sendDone( TOS_MsgPtr m, result_t res  ) {   

dbg( DBG_USR1, "sendDone: called with result = %i and count: %i 
\n", (int)res, (int)count ); 

return SUCCESS;

}

task void sendAckTask( ) {

struct SampleMsg *ackMsg = (struct SampleMsg*) sendBuf.data;

ackMsg->senderID = TOS_LOCAL_ADDRESS;
ackMsg->sendTime = call SysTime.getTime32(); 

if ( call CommSend.send( dstAddr , sizeof( struct SampleMsg), 
&sendBuf ) == FAIL ) {

dbg( DBG_USR1, "send failed when sending recv Ack\n" );
}

dbg( DBG_USR1, "send posted successfully \n");
}


event TOS_MsgPtr CommReceive.receive( TOS_MsgPtr m ) {

struct SampleMsg* msg1 = (struct SampleMsg*) m->data;

msg1->recvTime = call SysTime.getTime32( );
dstAddr = msg1->senderID;

dbg( DBG_USR1, "Msg received: addressed to:%x  length:%i 
senderID:%i sendTime:%ld recvTime:%d\n",m->addr, m->length, msg1->senderID, 
msg1->sendTime, msg1->recvTime );

if ( TOS_LOCAL_ADDRESS 

Re: [Tinyos-help] __attribute__ ((C, spontaneous))

2006-07-05 Thread David Gay

On 7/5/06, Adam <[EMAIL PROTECTED]> wrote:

Thanks. Does this mean it is recommended to add this attibute to all global
C functions? For my case, I write some buffer manage functions -- multiple
modules can call those functions -- I added "atomic" in  each of those
functions, will it be removed by compiler (since atomic is not a c KEYWORD)
if I use these attributes? I ASSUME NOT. Please correct me if I am wrong.
Thanks.


If your function is called from a nesC component, you don't need
spontaneous. I'm unclear what link you see between "spontaneous"
(telling the nesC optimiser that it shouldn't remove an apparently
uncalled function) and "atomic" (a nesC extension to C relating to
atomic execution of a block of a block of code) (so, no, adding or
removing spontaneous is not going to make the nesC compiler add or
remove atomic statements...).

Note that to use atomic in your "C" functions (well, they aren't
really C once you use atomic...), you'll need to either:

- include your C files in some nesC component with #include (nesC 1.2
or later required)
- add a #undef atomic to your C files before the first use of atomic
(not guaranteed to continue working into the indefinite future)

David Gay
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help


Re: [Tinyos-help] __attribute__ ((C, spontaneous))

2006-07-05 Thread Tehn Yit Chin


Philip Levis wrote:

On Jul 5, 2006, at 11:24 AM, Adam wrote:


I notice GenericComm has this following function:

TOS_MsgPtr handleReceived(TOS_MsgPtr packet)  __attribute__ ((C,
spontaneous))

I am curious that what's the difference if we use __attribute__ ((C,
spontaneous)) or not to define an global function? I have written  
several
global function without using the _attribute, it seems working fine  
so far.



Dead code elimination. Spontaneous tells nesC that the function might  
be called from "elsewhere" and therefore shouldn't be removed.


Phil


Out of curiosity, would nesC also not perform any optimisation on this 
bit of code as well, or is that left up to avr-gcc?


cheers,
Tehn Yit Chin
Embedded System Engineer, Grey Innovation Pty. Ltd.

___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help


Re: [Tinyos-help] async/sync events preemption

2006-07-05 Thread Philip Levis
On Wed, 2006-07-05 at 15:40, frigging frigging wrote:
> Thanks for all your help. There is still one thing which does not let
> me go on working. 
> I understand that any async function can preemp other async function
> and task (from your manual).
> My question is the follow:
> when an async function is interrupt because an other async function
> comes, is it correct that the second async function run to completion
> an after continue the former async function?

Yes. That's how interrupt handlers generally work, unless the OS does
some crazy stack swapping tricks.

Phil

___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help


[Tinyos-help] async/sync events preemption

2006-07-05 Thread frigging frigging
Thanks for all your help. There is still one thing which does not let me go on working. 
I understand that any async function can preemp other async function and task (from your manual).
My question is the follow:
when an async function is interrupt because an other async function comes, is it correct that the second async function run to completion an after continue the former async function?
 
Thanks.
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help


RE: [Tinyos-help] Mate and send_lqi on Telosb/tmote

2006-07-05 Thread Philip Levis
On Wed, 2006-07-05 at 14:53, Ben Kelley wrote:

> 
> I finally got it to work, I have no idea how.
> 
> I ended up going with
> 
> typedef struct MateRouteMsg {
>   uint16_t sourceaddr;
>   uint16_t originaddr;
>   int16_t seqno;
>   int16_t originseqno;
>   uint16_t hopcount;
>   uint8_t data[];
> } __attribute__ ((packed)) MateRouteMsg;
> 
> In $TOSDIR/lib/VM/types/mhop.h
> 
> I don't believe I changed anything else; however, just for the archives, it
> at least works. 

Right! Of course. My guess is that it will work fine without the packed
attribute.

There were two issues at play. The first was the size of the multihop
header. The one in lib/VM/types was from MintRoute and was too small. So
if you were using MultihopLQI, it would think that the Mate' data buffer
started somewhere in the MultihopLQI header, get confused, and tell you
that things weren't working right.

But if you loop at the MultihopLQI packet format, it's this:

typedef struct MultihopMsg {
  uint16_t sourceaddr;
  uint16_t originaddr;
  int16_t seqno;
  int16_t originseqno;
  uint16_t hopcount;
  uint8_t data[(TOSH_DATA_LENGTH - 10)];
} TOS_MHopMsg;

Note the major difference between your structure and this one: in yours,
you specify that data is an array of unknown size ([]), while
TOS_MHopMsg defines it as an array of size TOSH_DATA_LENGTH-10.

mig treats the two differently. With [], mig understands that the packet
will be variably sized and will accept payloads larger than or equal to
the minimum size. With [TOSH_DATA_LENGTH - 10], mig assumes the payload
is of a fixed size, and if it is shorter it says the packet is too
small.

Note that the original VM message buffer is this:

typedef struct MateRouteMsg {
  uint16_t sourceaddr;
  uint16_t originaddr;
  int16_t seqno;
  uint8_t hopcount;
  uint8_t data[];
} __attribute__ ((packed)) MateRouteMsg;

The Mate' implementation and java toolchain assume that you can send
variably sized packets. Basically, if your buffer has one item, it
doesn't send an entire buffer, just the one item. But if you use the
standard MultihopLQI format, mig thinks it is fixed size.

The trick of doing (TOSH_DATA_LENGTH - x) is old, before there were
interfaces that let you find out the payload length. It's also very
brittle, as it means you can't put MultihopLQI on top of another layer
that, say, adds other fields between the AM and multihop headers. All
network protocols in 2.x have stopped doing this for these reasons.

Phil

___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help


[Tinyos-help] Compiling Ditto from moteiv's Invent

2006-07-05 Thread Chiu Tan
Hi
I recently bought some Moteiv Invent motes. 
After doing a clean install from the provided CD, I tried to compile the Ditto program in /invent/Ditto
However, I get a very long error message starting with 
 
   Error : no such architecture: `msp430x1611'
   Error: jucnk at end of line, first unrecognized character is 'T'
   .
 
 
Since Tmote comes with its own tinyos, I ran toscheck from /opt/moteiv/tinyos-1.x/tools/scripts
It states that I already have msp430gcc 3.2.3 installed followed by a bunch of warnings like no avr-gcc found, etc. 
 
 
Question: Any ideas on what to do to compile the apps under moteiv's Invent? 
 
I used the installer provided (version 2.02), and there does not seem to be a newer version on moteiv's website, so I assume that it is the latest version. I have already tried to manually install the rpms found on the CD, but still doesnt work.

 
Thanks
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help


RE: [Tinyos-help] Mate and send_lqi on Telosb/tmote

2006-07-05 Thread Ben Kelley


> -Original Message-
> From: [EMAIL PROTECTED] [mailto:tinyos-help-
> [EMAIL PROTECTED] On Behalf Of Philip Levis
> Sent: Thursday, June 29, 2006 14:06
> To: [EMAIL PROTECTED]
> Cc: tinyos-help@Millennium.Berkeley.EDU
> Subject: RE: [Tinyos-help] Mate and send_lqi on Telosb/tmote
> 
> On Thu, 2006-06-29 at 11:29, Ben Kelley wrote:
> > MateRoute to the MultiHop
> > format?
> >
> > I can't help but wonder if this also has something to do with the
> > AM_BUFFERMSG that my makefile keeps trying to mig.
> 
> It doesn't have much to do with AM_BUFFERMSG. This is just how the Mate'
> build system gets mig to generate a Java class for the actual buffer
> data structure.
> 
> It has to do with the packet format. The mig-generated packet formats
> are not the same as those the node is using. What you need to do is get
> them to agree. My intention was to get you to correct the MateRoute to
> match the MultiHop format.
> 
> You want to put this in mhop.h:
> 
> typedef struct MateRouteMsg {
>   uint16_t sourceaddr;
>   uint16_t originaddr;
>   int16_t seqno;
>   int16_t originseqno;
>   uint16_t hopcount;
>   uint8_t data[(TOSH_DATA_LENGTH - 10)];
> } MateRouteMsg;
> 
> You then need to go into your VM app directory and
> 
> make clean
> 
> To remove all of the generated packet files. Then do the standard make,
> make install.
> 
> Here are the basic issues you might run into and their causes:
> 
> type UNKNOWN, type NONE: the packet format TinyOS is generating and the
> packet format the Java side is expecting do not agree. The Java side is
> looking for a type field in the buffer, and because the formats do not
> agree, it is looking in the wrong place, seeing a different byte, and
> then complaining it is not valid.
> 
> too short: The packet formats do not agree. TinyOS is sending a shorter
> packet than what the Java side expects. This happens if the Java side
> has been compiled to think that the header is larger than the one TinyOS
> expects.
> 
> Apologies that I can't look into the code right now: trying to get the
> 2.0 beta2 release out.
> 
> Phil
> 

I finally got it to work, I have no idea how.

I ended up going with

typedef struct MateRouteMsg {
  uint16_t sourceaddr;
  uint16_t originaddr;
  int16_t seqno;
  int16_t originseqno;
  uint16_t hopcount;
  uint8_t data[];
} __attribute__ ((packed)) MateRouteMsg;

In $TOSDIR/lib/VM/types/mhop.h

I don't believe I changed anything else; however, just for the archives, it
at least works.  

Received broadcast buffer of type TTEMP, size 10 @ Wed Jul 05 17:53:30 EDT
2006
  [7104][7105][7107][7107][7107][7108][7108][7108][7108][7107]
Message  
  [buffer.type=0x1]
  [buffer.data.length=0x16]
  [buffer.data.data=0x38 0xa 0xc0 0x1b 0xc1 0x1b 0xc3 0x1b 0xc3 0x1b 0xc3
0x1b 0xc4 0x1b 0xc4 0x1b 0xc4 0x1b 0xc4 0x1b 0xc3 0x1b 0x0 0x0 0x0 0x0 ]

Message  
  [sourceaddr=0x0]
  [originaddr=0x0]
  [seqno=0x0]
  [originseqno=0x8]
  [hopcount=0x0]

Ben

___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help


RE: [Tinyos-help] __attribute__ ((C, spontaneous))

2006-07-05 Thread Adam
Again, if these functions will be called inside nesC code only, is it not
necessary ? -- I just wan to confirm it is not related to byte order or
parameter order issues -- like between C and Fortran. 

-Original Message-
From: Adam [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, July 05, 2006 11:53 AM
To: 'Philip Levis'
Cc: 'tinyos-help'
Subject: RE: [Tinyos-help] __attribute__ ((C, spontaneous))

Thanks. Does this mean it is recommended to add this attibute to all global
C functions? For my case, I write some buffer manage functions -- multiple
modules can call those functions -- I added "atomic" in  each of those
functions, will it be removed by compiler (since atomic is not a c KEYWORD)
if I use these attributes? I ASSUME NOT. Please correct me if I am wrong.
Thanks.
 

-Original Message-
From: Philip Levis [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 05, 2006 11:37 AM
To: Adam
Cc: 'tinyos-help'
Subject: Re: [Tinyos-help] __attribute__ ((C, spontaneous))

On Jul 5, 2006, at 11:24 AM, Adam wrote:

> I notice GenericComm has this following function:
>
> TOS_MsgPtr handleReceived(TOS_MsgPtr packet)  __attribute__ ((C,
> spontaneous))
>
> I am curious that what's the difference if we use __attribute__ ((C,
> spontaneous)) or not to define an global function? I have written 
> several global function without using the _attribute, it seems working 
> fine so far.

Dead code elimination. Spontaneous tells nesC that the function might be
called from "elsewhere" and therefore shouldn't be removed.

Phil

___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help


RE: [Tinyos-help] __attribute__ ((C, spontaneous))

2006-07-05 Thread Adam
Thanks. Does this mean it is recommended to add this attibute to all global
C functions? For my case, I write some buffer manage functions -- multiple
modules can call those functions -- I added "atomic" in  each of those
functions, will it be removed by compiler (since atomic is not a c KEYWORD)
if I use these attributes? I ASSUME NOT. Please correct me if I am wrong.
Thanks.
 

-Original Message-
From: Philip Levis [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, July 05, 2006 11:37 AM
To: Adam
Cc: 'tinyos-help'
Subject: Re: [Tinyos-help] __attribute__ ((C, spontaneous))

On Jul 5, 2006, at 11:24 AM, Adam wrote:

> I notice GenericComm has this following function:
>
> TOS_MsgPtr handleReceived(TOS_MsgPtr packet)  __attribute__ ((C,
> spontaneous))
>
> I am curious that what's the difference if we use __attribute__ ((C,
> spontaneous)) or not to define an global function? I have written 
> several global function without using the _attribute, it seems working 
> fine so far.

Dead code elimination. Spontaneous tells nesC that the function might be
called from "elsewhere" and therefore shouldn't be removed.

Phil

___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help


[Tinyos-help] printing constants on flash

2006-07-05 Thread jose m
Hello all,

My mica2 application requires a lot of RAM for radio
messages. The mote is connected to a GPS, and must
initialize this one. For initialization purposes, the
system sends to the GPS a NMEA protocol ASCII string.
This string never changes, so is a constant string,
and needs several bytes of precious RAM. A posible
solution: store this constant structure in flash
memory. Is this posible? How can I do it? can be
retrieved? is a special nesc declaration?

Thanks in advance.

José





___ 
1GB gratis, Antivirus y Antispam 
Correo Yahoo!, el mejor correo web del mundo 
http://correo.yahoo.com.ar 

___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help


Re: [Tinyos-help] __attribute__ ((C, spontaneous))

2006-07-05 Thread Philip Levis

On Jul 5, 2006, at 11:24 AM, Adam wrote:


I notice GenericComm has this following function:

TOS_MsgPtr handleReceived(TOS_MsgPtr packet)  __attribute__ ((C,
spontaneous))

I am curious that what's the difference if we use __attribute__ ((C,
spontaneous)) or not to define an global function? I have written  
several
global function without using the _attribute, it seems working fine  
so far.


Dead code elimination. Spontaneous tells nesC that the function might  
be called from "elsewhere" and therefore shouldn't be removed.


Phil
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help


RE: [TinyOS-help] Compile Error for SurgeTelos

2006-07-05 Thread Adam
export TOSMAKE_PATH=/opt/tinyos-1.x/contrib/moteiv/tools/make
Should solve this. 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Joe
Polastre
Sent: Wednesday, July 05, 2006 9:19 AM
To: Ming
Cc: tinyos-help@Millennium.Berkeley.EDU
Subject: Re: [TinyOS-help] Compile Error for SurgeTelos

For some reason it isn't finding %T/lib/MultiHopLQI

On 7/4/06, Ming <[EMAIL PROTECTED]> wrote:
> Hi everyone
>
> When I try to compile the SurgeTelos on the Telos verB, I get the 
> following error. How can I solve it?
>
> > # make telosb
> > mkdir -p build/telosb
> > compiling Surge to a telosb binary ncc -o build/telosb/main.exe 
> > -O -I%T/lib/MultiHopLQI -DSEND_QUEUE_SIZE=8
> -DMHOP_LEDS -Wall -Wshadow -DDEF_TOS_AM_GROUP=0x7d -Wnesc-all 
> -target=telosb -fnesc-cfile=build/telosb/app.c -board= -I%T/lib/Deluge 
> -Wl,--section-start=.text=0x4800,--defsym=_reset_vector__=0x4000
> -DIDENT_PROGRAM_NAME=\"Surge\" -DIDENT_USER_ID=\"root\"
> -DIDENT_HOSTNAME=\"new-host-11\"
> -DIDENT_USER_HASH=0xb4e3d2a8L -DIDENT_UNIX_TIME=0x44aac6c4L 
> -DIDENT_UID_HASH=0xfc1bbc3eL -mdisable-hwmul -I/opt/tinyos- 
> 1.x/tos/lib/CC2420Radio Surge.nc -lm
> >
> /opt/tinyos-1.x/tos/lib/MultiHopLQI/MultiHopEngineM.nc:82:
> `TOS_Msg' defined as wrong kind of tag
> >
> /opt/tinyos-1.x/tos/lib/MultiHopLQI/MultiHopEngineM.nc:83:
> `TOS_Msg' defined as wrong kind of tag
> > make: *** [exe0] Error 1
> >
>
> Thank you.
>
> CM
>
> ___
> Tinyos-help mailing list
> Tinyos-help@Millennium.Berkeley.EDU
> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-h
> elp
>
>
>
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help


[Tinyos-help] __attribute__ ((C, spontaneous))

2006-07-05 Thread Adam
I notice GenericComm has this following function:

TOS_MsgPtr handleReceived(TOS_MsgPtr packet)  __attribute__ ((C,
spontaneous))

I am curious that what's the difference if we use __attribute__ ((C,
spontaneous)) or not to define an global function? I have written several
global function without using the _attribute, it seems working fine so far.

Thanks.

___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help


Re: [Tinyos-help] c serial forwarder in tinyos-2.x

2006-07-05 Thread David Gay

On 7/5/06, Razvan Musaloiu-E. <[EMAIL PROTECTED]> wrote:

Hi!

On Tue, 4 Jul 2006, Avinash Sridharan wrote:

> The ncc --version output is :
> ncc: 1.2
> nescc: 1.2.2
> gcc: gcc (GCC) 4.0.2 20051125 (Red Hat 4.0.2-8)
> Copyright (C) 2005 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> Output of make:
> mig -o serialpacket.h -c-prefix=spacket c
> /home/asridhar/developement/sandbox/latest/tinyos-2.x//tos/lib/serial/Serial.h
> serial_packet
> gcc: unrecognized option '-c-prefix=spacket'
> warning: Cannot determine AM type for serial_packet
>  (Looking for definition of AM_SERIAL_PACKET)
> Unknown tool c
> make: *** [serialpacket.h] Error 2

I encounter the same problem some time ago [1] and I was using 1.2.4 at
that time. Switching to the latest CVS fixed the problem in my case. Using


http://www.tinyos.net/dist-2.0.0/tinyos/linux/nesc-1.2.7-1.i386.rpm
or
http://www.tinyos.net/dist-2.0.0/tinyos/windows/nesc-1.2.7-1.cygwin.i386.rpm

should fix your problem.

David Gay
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help


Re: [Tinyos-help] async/sync events preemption

2006-07-05 Thread Philip Levis

On Jul 5, 2006, at 2:24 AM, Frigging wrote:


Hi,

by the way I'm interesting about tinyos 2.x

you've had wrote:
"Interrupts, however, can preempt tasks. All code that an interrupt  
handler
calls must be async. The hardware takes care of pushing some  
context on the
stack, and the compiler takes care of spilling registers to memory.  
The
question of when interrupts can be handled or not (interrupt  
preemption,
etc.) depends on 2 things: the chip architecture and whether the  
code has

disabled interrupts or adjusted the interrupt priority level."

but this means that asyc function could preempt an other async  
function?
However if an interrupt handler can call only async function, maybe  
it's
possible (if the chip architecture and whether the code has not  
disabled
interrupts or adjusted the interrupt priority level) preempt an  
other async
function. I think so, because I read your paper "TinyOS  
Programming" at page
39, and I understand that since "In this example, c can  
(theoretically)
preempt a ...", for me this means that async function can preempt  
task and
async function. While sync function is running (no-blocking), are  
interrupts

disabled? or is there a interrupts queue?

In tinyos 2.x where is interrupt priority level handled ?


You're asking about hardware at this point, rather than TinyOS.

Some interrupt handlers have interrupts disabled during their  
execution (e.g., the I2C/two-wire interrupt on the atm128 basically  
requires they be disabled in order to work properly). Others keep  
interrupts enabled during their execution. IPLs are generally  
hardware, not software, mechanisms. In microcontrollers, priority  
levels generally indicate execution order, but the MCU does not  
support conditional disabling in the way that microprocessors do.


Phil
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help


Re: [Tinyos-help] porting tinyos on 8051 microcontroller

2006-07-05 Thread Philip Levis

On Jul 5, 2006, at 6:44 AM, gagan gaba wrote:


Is it possible to port tinyos on 8051
microcontroller??
if yes then how it goes 
plzz reply i would be very thankful


Please read TEP 121.

Phil
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help


[Tinyos-help] Sensing Events in TOSSIM

2006-07-05 Thread Keyan Mahadevan
Hello All,
I am trying to simulate sensing events in TOSSIM. As an example:
Consider 10 nodes deployed. Each node is sensing for sound. One node at
random will start chirping. The neighboring nodes sensing this event
send out a message announcing the sound detected. I dont know how to
generate the sound event in TOSSIM. Can anyone give me some pointers. 
Thanks
Kn
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help


[Tinyos-help] WSN Source Coding Experiments

2006-07-05 Thread Muthiah Annamalai
Friends,We have some source code & algorithms from our experiments on MICA2 moteusing TinyOS. People working on source coding in WSN can benefit.Source is licensed under GPL. Check with the website for code  & docs.http://students.uta.edu/mx/mxa6471/WSNSrcCoding/Thanks for help on the TinyOS lists and support.RegardsMuthuGrad Student, EE,UT-Arlington. __Do You Yahoo!?Tired of spam?  Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help


Re: [Tinyos-help] Task queue

2006-07-05 Thread Joe Polastre

If you use Boomerang, then you use the new TinyOS 2.x task queue that
doesn't have this problem.  The 1.x task queue still has the
possibility of overflowing.

-Joe

On 7/5/06, giovanni gamba <[EMAIL PROTECTED]> wrote:

Hi all,
 i'm working on Tmote Sky.
 I experienced some event loss in my application (or i think this is the
problem..) and i want to increment the queue size.
 I have a master that polls many slave in a round robin fashion and after a
few minutes the timer that rules master's polling seems to fail.
 (i can also see the lack of polling request through leds blinkings).
 The result is that the master requests seems to slow down... while the
former polling period is e.g 90 ms, after the "loss" this period inflates
and can reach 1 second.
 A possible explanation is that the timer loose some events and so it can't
fire..

 I tried to increment the task queue modifying CFLAGS +=
-DTOSH_MAX_TASKS_LOG2=10 in the makefile.
 But after compiling the program i didn't see a RAM increment as i
expected...
 Is it correct?
 What is the maximum task queue size?

 Thank you very much

___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help




___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help


Re: [TinyOS-help] Compile Error for SurgeTelos

2006-07-05 Thread Joe Polastre

For some reason it isn't finding %T/lib/MultiHopLQI

On 7/4/06, Ming <[EMAIL PROTECTED]> wrote:

Hi everyone

When I try to compile the SurgeTelos on the Telos verB, I get the following
error. How can I solve it?

> # make telosb
> mkdir -p build/telosb
> compiling Surge to a telosb binary
> ncc -o build/telosb/main.exe -O -I%T/lib/MultiHopLQI -DSEND_QUEUE_SIZE=8
-DMHOP_LEDS -Wall -Wshadow -DDEF_TOS_AM_GROUP=0x7d -Wnesc-all -target=telosb
-fnesc-cfile=build/telosb/app.c -board= -I%T/lib/Deluge
-Wl,--section-start=.text=0x4800,--defsym=_reset_vector__=0x4000
-DIDENT_PROGRAM_NAME=\"Surge\" -DIDENT_USER_ID=\"root\"
-DIDENT_HOSTNAME=\"new-host-11\"
-DIDENT_USER_HASH=0xb4e3d2a8L -DIDENT_UNIX_TIME=0x44aac6c4L
-DIDENT_UID_HASH=0xfc1bbc3eL -mdisable-hwmul -I/opt/tinyos-
1.x/tos/lib/CC2420Radio Surge.nc -lm
>
/opt/tinyos-1.x/tos/lib/MultiHopLQI/MultiHopEngineM.nc:82:
`TOS_Msg' defined as wrong kind of tag
>
/opt/tinyos-1.x/tos/lib/MultiHopLQI/MultiHopEngineM.nc:83:
`TOS_Msg' defined as wrong kind of tag
> make: *** [exe0] Error 1
>

Thank you.

CM

___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help




___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help


[Tinyos-help] Re:porting tinyos on 8051 microcontroller

2006-07-05 Thread Alex Junyan Ma

Gaba,
The link below is the working group of tinyos 8051. Maybe you would
find something helpful

http://www.tinyos.net/scoop/special/working_group_tinyos_8051

--
Alex Junyan Ma

A804 Aviation Building
Northwestern Polytechnical University
Xi'an, Shaanxi, China P.R.

EMAIL: alexmajy at gmail dot com
MSN: alexmajy at hotmail dot com
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help


[Tinyos-help] Task queue

2006-07-05 Thread giovanni gamba
Hi all,
i'm working on Tmote Sky.
I experienced some event loss in my application (or i think this is the problem..) and i want to increment the queue size.
I have a master that polls many slave in a round robin fashion and
after a few minutes the timer that rules master's polling seems to fail.
(i can also see the lack of polling request through leds blinkings).
The result is that the master requests seems to slow down... while the
former polling period is e.g 90 ms, after the "loss" this period
inflates and can reach 1 second.
A possible explanation is that the timer loose some events and so it can't fire..

I tried to increment the task queue modifying CFLAGS += -DTOSH_MAX_TASKS_LOG2=10 in the makefile.
But after compiling the program i didn't see a RAM increment as i expected...
Is it correct?
What is the maximum task queue size?

Thank you very much
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help


[Tinyos-help] help:event Receive.receive()

2006-07-05 Thread Munaretto, Daniel
Hi all,
is there a fast and easy way to receive all messages arriving from the 
network?
Because if i only use
 
event TOS_MsgPtr ReceiveDataNC.receive(TOS_MsgPtr m){
  Datagram *dg=(Datagram *)m->data;
[..]
.
.
[..]
 return m;
}
 
i see in TOSSIM that some packets too close with each other (i mean in the 
time,really closed in arriving time), only the first is taken and 
elaborated,the next ones are not considered.
But i want to consider all these packets for my project, it's really 
important!!!
 
I hope someone can help me!
Thanks for your availability!!
 
Cheers
Daniele

___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help


Re: [Tinyos-help] c serial forwarder in tinyos-2.x

2006-07-05 Thread Razvan Musaloiu-E.
Hi!

On Tue, 4 Jul 2006, Avinash Sridharan wrote:

> The ncc --version output is :
> ncc: 1.2
> nescc: 1.2.2
> gcc: gcc (GCC) 4.0.2 20051125 (Red Hat 4.0.2-8)
> Copyright (C) 2005 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> Output of make:
> mig -o serialpacket.h -c-prefix=spacket c
> /home/asridhar/developement/sandbox/latest/tinyos-2.x//tos/lib/serial/Serial.h
> serial_packet
> gcc: unrecognized option '-c-prefix=spacket'
> warning: Cannot determine AM type for serial_packet
>  (Looking for definition of AM_SERIAL_PACKET)
> Unknown tool c
> make: *** [serialpacket.h] Error 2

I encounter the same problem some time ago [1] and I was using 1.2.4 at
that time. Switching to the latest CVS fixed the problem in my case. Using
anything newer than 1.2.4 should do the same.

[1] 
http://mail.millennium.berkeley.edu/pipermail/tinyos-help/2006-May/017020.html

--
Razvan ME

>
> On 7/4/06, Philip Levis <[EMAIL PROTECTED]> wrote:
> >
> >
> > On Jul 4, 2006, at 3:12 PM, Avinash Sridharan wrote:
> >
> > > Hi All,
> > >  In order to compile the latest c serial forwarder in tinyos-2.x
> > > what is the version of nesc(mig) that is required. I believe I have
> > > nesc 1.2.2 and hence this might be causing a problem with the
> > > compilation ?
> > >
> >
> > Can you send the error you see as well as the result of 'ncc --version'?
> >
> > Phil
> >
>
>
>
> --
> Phd Dept. of Electrical Engineering
> University of Southern California
> http://www-scf.usc.edu/~asridhar 
>

___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help


[Tinyos-help] porting tinyos on 8051 microcontroller

2006-07-05 Thread gagan gaba
Is it possible to port tinyos on 8051
microcontroller??
if yes then how it goes 
plzz reply i would be very thankful



__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help


RE: [Tinyos-help] async/sync events preemption

2006-07-05 Thread Frigging
Hi,

by the way I'm interesting about tinyos 2.x

you've had wrote:
"Interrupts, however, can preempt tasks. All code that an interrupt handler
calls must be async. The hardware takes care of pushing some context on the
stack, and the compiler takes care of spilling registers to memory. The
question of when interrupts can be handled or not (interrupt preemption,
etc.) depends on 2 things: the chip architecture and whether the code has
disabled interrupts or adjusted the interrupt priority level."

but this means that asyc function could preempt an other async function?
However if an interrupt handler can call only async function, maybe it's
possible (if the chip architecture and whether the code has not disabled
interrupts or adjusted the interrupt priority level) preempt an other async
function. I think so, because I read your paper "TinyOS Programming" at page
39, and I understand that since "In this example, c can (theoretically)
preempt a ...", for me this means that async function can preempt task and
async function. While sync function is running (no-blocking), are interrupts
disabled? or is there a interrupts queue?

In tinyos 2.x where is interrupt priority level handled ? 

I'm very stubborn .. ehm sorry :-)

Thanks in adavance

___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help


RE: [Tinyos-help] TinyOS 1.1.15 Timer help

2006-07-05 Thread Andres Aberasturi


Hi all,

Sorry, we have found the error. It was a hardware problem.

Thanks,

Andres



From: "Andres Aberasturi" <[EMAIL PROTECTED]>
To: tinyos-help@Millennium.Berkeley.EDU
Subject: [Tinyos-help] TinyOS 1.1.15 Timer help
Date: Wed, 05 Jul 2006 08:28:45 +0200


Hi all,

We are working with micaz motes, mts310 sensorboard and Crossbow 
contribution. We have been working with TinyOS 1.1.7, but some weeks ago we 
started to use TinyOS 1.1.15.


We have applications in TinyOS 1.1.7 which work with two timers:
AppM.Timer1 -> TimerC.Timer[unique("Timer")];
AppM.Timer2 -> TimerC.Timer[unique("Timer")];

Now, these applications do not work in TinyOS 1.1.15. Their timers do not 
work correctly. We do not know whether timer module is changed and we 
should implement it in other way.


Could anybody help us? Any clue will be wellcome.

Thanks in advance,

Andres

_
Moda para esta temporada. Ponte al día de todas las tendencias. 
http://www.msn.es/Mujer/moda/default.asp


___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help


_
Moda para esta temporada. Ponte al día de todas las tendencias. 
http://www.msn.es/Mujer/moda/default.asp


___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help