[Tinyos-help] a question about includes clock

[吴洪]

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 *******************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.millennium.berkeley.edu/pipermail/tinyos-help/attachments/20070709/9ccbefb9/attachment-0001.html