[Tinyos-help] a question about includes clock
Michael Schippling
schip at santafe.edu
Mon Jul 9 09:38:46 PDT 2007
The easy way is to add a -v to the ncc compile line.
That will make it print out all file accesses so you
can see the order of inclusion. In general the platform
directory that you specify, e.g., mica2 will take
precedence but ncc has a built-in search order.
Depending on the ncc version I seem to remember that
there is a .platform file that contains the order.
MS
Îâºé wrote:
> HI,
> There is includes clock in interface clock.nc. However when i tried to
> locate the clock.h ,i found several clock.h(in
> interfaces,platform/mica,platform/micaz).My question is: how do i kow
> which is the one used in interface clock.nc
>
>
>
>
> ÔÚ2007-07-09£¬tinyos-help-request at Millennium.Berkeley.EDU дµÀ£º
>
> Send Tinyos-help mailing list submissions to
> tinyos-help at Millennium.Berkeley.EDU
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
>
> or, via email, send a message with subject or body 'help' to
> tinyos-help-request at Millennium.Berkeley.EDU
>
> You can reach the person managing the list at
> tinyos-help-owner at Millennium.Berkeley.EDU
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Tinyos-help digest..."
>
>
> Today's Topics:
>
> 1. Re: Localization implementation (Michael Schippling)
> 2. Atm128 External Interrupt on any change (Mark Kranz)
> 3. HplAtm128UartP Baudrate configuration (Mark Kranz)
> 4. tinyos-2.0.1-5 serial receiving problem
> (=?ks_c_5601-1987?B?waSw6Ljt?=)
> 5. Re: Localization implementation (Urs Hunkeler)
> 6. Re: relationship between RSSI and distance
> (Van der Haegen Mathieu)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 08 Jul 2007 17:33:57 -0600
> From: Michael Schippling <schip at santafe.edu>
> Subject: [Tinyos-help] Re: Localization implementation
> To: Tarek Mohamed Salah El-Din Mansour
> <tarek.mansour at student.guc.edu.eg>
> Cc: TINYOS Help <tinyos-help at millennium.berkeley.edu>
> Message-ID: <46917465.6090205 at santafe.edu>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> I'm going to cc this back to the help list
> where you should send questions...
>
> If you want to use IntToRfm to send RSSI, I guess you would
> use the received message strength as the output( value ).
>
> Never use hard coded numbers if you can avoid it. I think
> you want to keep the TOS_LOCAL_ADDRESS (which is set to
> the install.NN ID number) where it is. TOS_BCAST_ADDR in
> the below code is where you are sending messages TO, in
> this case everyone. If you want to send() to a specific
> mote, then use it's ID value instead of BCAST.
>
> The receiving mote can get the source ID from IntMsg.src.
> If you are unclear on how to receive messages look at the
> RfmToLeds and SimpleCmd apps.
>
> The comparison you show will tell you if RSSI1 is greater
> than RSSI2, but the numbers are sorta advisory...if you've
> been following the flurry of strength-to-distance questions
> on the list, and looked at some of the ref'ed papers you'll
> see that there's a lot of variability when trying to do this.
>
> MS
>
> Tarek Mohamed Salah El-Din Mansour wrote:
> >
> > Hi Mr. Schippling,
> >
> > I want to ask you a couple of questions if possible;
> >
> > -If i the strength in a variable like "RSSI1", which part of the
> > following "IntToRfmM" code should be modified?
> > -If i have a MOTE that i want to send to it and i already gave it a node
> > ID 14 by "make mica2 install.14", should i write "14" instead of
> > "TOS_BCAST_ADDR"?
> > -If i have a MOTE that should receive 3 msgs from 3 different MOTES
> > where "RSSI1" will be the data in this case, how can the MOTE detect the
> > MOTE ID that is sending and extract the data from it?
> > -If after extracting the "RSSI" msg from the 3 MOTES and i want to
> > compare between them, will it be like (if "RSSI1">"RSSI2") or what?
> > ------------------------------------------------------------
> > command result_t IntOutput.output(uint16_t value)
> > {
> > IntMsg *message = (IntMsg *)data.data;
> >
> > if (!pending)
> > {
> > pending = TRUE;
> >
> > message->val = value;
> > atomic {
> > message->src = TOS_LOCAL_ADDRESS;
> > }
> > if (call Send.send(TOS_BCAST_ADDR, sizeof(IntMsg), &data))
> > return SUCCESS;
> >
> > pending = FALSE;
> > }
> > return FAIL;
> > }
> >
> > event result_t Send.sendDone(TOS_MsgPtr msg, result_t success)
> > {
> > if (pending && msg == &data)
> > {
> > pending = FALSE;
> > signal IntOutput.outputComplete(success);
> > }
> > return SUCCESS;
> > }
> > ---------------------------------------------------------------------------
> >
> > Best Regards,
> > Tito
> >
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 9 Jul 2007 10:49:46 +0800
> From: "Mark Kranz" <mkranz at gmail.com>
> Subject: [Tinyos-help] Atm128 External Interrupt on any change
> To: "tinyos-help at Millennium.Berkeley.EDU"
> <tinyos-help at millennium.berkeley.edu>
> Message-ID:
> <8ac30d8a0707081949n4aa06a4au2bd0241641675767 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> I'm trying to generate an interrupt on any logical change on the
> atmega 128, (Port E, Pin 6 - INT6). According to the ATmega128
> datasheet (pg 90):
>
> ISCn1 ISCn0 Description
> 0 0 The low level of INTn generates an interrupt request.
> 0 1 Any logical change on INTn generates an interrupt request
> 1 0 The falling edge between two samples of INTn generates an
> interrupt request.
> 1 1 The rising edge between two samples of INTn generates an
> interrupt request.
>
> Thus, we need something like:
> EICRB |= (1 << ISC60);
> EICRB &= ~(1 << ISC61);
>
> Currently, the GpioInterrupt interface (and the underlying
> HplAtm128InterruptPinP implementation) is only capable of handling the
> 00, 10, and 11 cases. I assume this is because interrupt pins 0..3
> only support high-low and low-high transitions - so the interface is
> kept general to handle *all* interrupt pins.
>
> Are there any plans to introduce support for multiple transition types
> at the GpioInterrupt level? Or shall I just stick with directly
> writing to the register (messy)?
>
> cheers
>
> -Mark
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 9 Jul 2007 11:00:17 +0800
> From: "Mark Kranz" <mkranz at gmail.com>
> Subject: [Tinyos-help] HplAtm128UartP Baudrate configuration
> To: "tinyos-help at Millennium.Berkeley.EDU"
> <tinyos-help at millennium.berkeley.edu>
> Message-ID:
> <8ac30d8a0707082000r5c4cd528q7e50643575d9e29b at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hi all,
>
> The way that UART baudrates is configured on atm128 chips makes it
> impossible to use different baud-rates on different UARTs (eg UART0
> and UART1).
>
> ubrr0 = call Atm128Calibrate.baudrateRegister(PLATFORM_BAUDRATE);
> ...
> ubrr1 = call Atm128Calibrate.baudrateRegister(PLATFORM_BAUDRATE);
>
> At the moment, the only way to override this is to shadow
> HplAtm128UartP in our platform's implementation, change the function
> arguments UART0_BAUDRATE and UART1_BAUDRATE, then #define them in the
> platform's hardware header or makefile settings.
>
> Can anyone think of a better way to do this? Does anyone else have a
> genuine need for different baud-rates on different UARTs?
>
> cheers
>
> -Mark
>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 9 Jul 2007 15:04:29 +0900
> From: =?ks_c_5601-1987?B?waSw6Ljt?= <jgm2000 at ibitworld.com>
> Subject: [Tinyos-help] tinyos-2.0.1-5 serial receiving problem
> To: <tinyos-help at Millennium.Berkeley.EDU>
> Message-ID: <20070709060430.SUNC15895.mxmss0 at jgm2000>
> Content-Type: text/plain; charset="ks_c_5601-1987"
>
> Hi all
>
> I had the test that it sends and receives between BaseStation and embedded
> board.
>
>
>
> My test is the same as follows
>
>
>
> Sensor node --> BaseStation --> embedded board
>
>
>
> I had the tests with two tinyos-2.x version
>
> First, tinyos-2.x version of BaseStation is 2.0.1-3
>
> When we test with 2.0.1-3, embedded board receives the correct value as
> below :
>
> Correct value : 7e 45 00 ff ff 00 05 37 22 0c 69 05 00 00 00 00 00 8f fd
> ff 00 ff fe 00 00 05 33 33 00 00 00 00 00 02 50 d5 42 88 ff fd ff ff fe 00
> 00 05 ff 02 00 00 00 00 00 00 00 00 00 00 00 00 00 02 3a 85 00 80 32 00 00
> 00 00 09 35 7e
>
>
>
> Second, tinyos-2.x version of BaseStation is 2.0.1-5
>
> When we test with 2.0.1-5, embedded board receives the wrong value as belos
> :
>
> Wrong value : fe 85 00 ff ff 00 05 77 42 0c ec 05 00 00 00 00 00 0f fd
> ff 00 ff fe 00 00 05 73 73 00 00 00 00 00 02 a0 b5 82 18 ff fd ff ff fe 00
> 00 05 ff 02 00 00 00 00 00 00 00 00 00 00 00 00 00 02 7a 05 00 00 72 00 00
> 00 00 04 71 fe
>
> If you check over the values, you would recognize some weird regulation.
>
> 7e --> fe
>
> 45 --> 85
>
> 37 --> 77
>
> 22 --> 42
>
> 42 --> 82
>
> I think 4 bit of one byte change through some masking or shift.
>
> I don??t know exactly.
>
>
>
> Don??t serial communication of tinyos-2.0.1-5 have the any problem?
>
> My embedded board is arm9 and linux kernel-2.4.18
>
> I would speak again that when we had a test with tinyos-2.0.1-3 of
> BaseStation, we received the correct value.
>
>
>
> If you know this problem, let me know.
>
> Thank you in advance.
>
>
>
>
>
>
>
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://mail.millennium.berkeley.edu/pipermail/tinyos-help/attachments/20070709/1af28cd6/attachment.html
>
> ------------------------------
>
> Message: 5
> Date: Mon, 09 Jul 2007 08:10:34 +0200
> From: Urs Hunkeler <uhu at gmx.ch>
> Subject: [Tinyos-help] Re: Localization implementation
> To: tinyos-help at Millennium.Berkeley.EDU
> Message-ID: <4691D15A.9050005 at gmx.ch>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Did anybody ever try to send several messages between two nodes with
> varying transmission power to better estimate the distance between the
> motes? If the motes were relatively close, measuring the RSSI for a
> message which was sent with much less power should be more helpful than
> always keeping the same transmission power for all messages...
>
> Cheers,
> Urs
>
>
> ------------------------------
>
> Message: 6
> Date: Mon, 9 Jul 2007 11:53:46 +0200
> From: "Van der Haegen Mathieu" <dwarfy.lenain at gmail.com>
> Subject: Re: [Tinyos-help] relationship between RSSI and distance
> To: "Philip Levis" <pal at cs.stanford.edu>
> Cc: tinyos-help at millennium.berkeley.edu
> Message-ID:
> <ae51c0f90707090253g4690ecb2h9f584c646e511883 at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi !
>
> Yes we are in really short distances ( 1-7 m if I remember correctly)
> And yes it seemed a bit strange to us
> So we did 2 others experiments recording LQI and RSSI in 2 differents
> environnements (inside and outside) on a range of ~ 1 to 50 m.
> And the RSSI seemed better in this experiment.
>
> Mathieu
>
>
>
> On 7/6/07, Philip Levis <pal at cs.stanford.edu> wrote:
> >
> > On Jul 6, 2007, at 4:09 AM, Van der Haegen Mathieu wrote:
> >
> > > I'd like to add that RSSI doesn't seem really correlated with
> > > distance in the experiments we did with our sensors nodes in an
> > > inside environnement with distances going from 1 to 10 meters.
> > >
> > > Lqi seem to be more correlated with distance in the same experiment
> > >
> > > I can send you our paper about this if you are interested
> > >
> >
> > This seems strange, unless you were in a very short distance range;
> > the CC2420's LQI is the soft chip decision coefficients, and so is
> > directly a result of the SNR (and therefore the RSSI). Your assertion
> > would only make sense if your links were all in the grey region of
> > intermediate link quality, in which LQI varies.
> >
> > Phil
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://mail.millennium.berkeley.edu/pipermail/tinyos-help/attachments/20070709/4305418f/attachment.htm
>
> ------------------------------
>
> _______________________________________________
> Tinyos-help mailing list
> Tinyos-help at Millennium.Berkeley.EDU
> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
>
> End of Tinyos-help Digest, Vol 51, Issue 38
> *******************************************
>
>
>
> 150 Íò ÈË Í¬ ʱ ÔÚ Íæ µÄ Íø ÓΣ¬Äã ²» ÊÔ ÊÔ Â𠣿
> <http://event.mail.163.com/chanel/xyq.htm?from=163_NO1>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Tinyos-help mailing list
> Tinyos-help at Millennium.Berkeley.EDU
> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
More information about the Tinyos-help
mailing list