There are other scenarios that can also lead to this. See a related thread
here:
http://blog.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/month=20051201
(Search for "relocation" on that page)
-shane
http://www.comet.columbia.edu/~shane
one way is the shell command 'usermod', but most linux distros provide a
GUI for user mgmt.
by running chmod 777 you made the device file r/w/x accessible by
everybody (including yourself) rather than adding yourself to the group
that had/s permission to access the file (which is what usermod
jose,
you certainly //could// modify a mote-side component in the UART stack to
implement a control message that returns the TOS_LOCAL_ADDRESS of a mote
connected to particular MIB600, and then modify serial forwarder to
implement the PC-side of that same query mechanism.
however, the simple
a similar error occurs with Moteiv Invents. you may want to adapt the fix
they suggest:
http://www.moteiv.com/community/Tmote_Invent_Programming_Troubleshooting
-shane
On Mon, 21 Aug 2006, [GB2312] wrote:
I have gotten the Blink application to compile however, there seem to
be errors wh
hi Darren,
i guess this isn't exactly what you were looking for, but you might be
able to get the information you want by keeping track of it yourself from
the beginning. i should say up front that i've never tried what i'm about
to suggest, so no guarantees.
unique() is a compile time const
consider the following two web pages dedicated to the subject:
1. http://thomer.com/tinyos/ (for ATMega 103/128 platforms)
2. http://www.chadmetcalf.com/tinyos-1x-on-ubuntu/ (for MSP430 platforms)
best,
shane
On Sat, 12 Aug 2006, bhushan bhatt wrote:
Hi Guys,
I plan to install tinyos on
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
Aside from defining the external interfaces of a component, nesC
*interfaces* provide a nice way to logically group related functions
within a module even when it would suffice to implement a local function.
However, some such functions might be very small, e.g., just act on a few
variables and ret
