RE: [Tinyos-help] Serial Forwarder Problem

2006-08-25 Thread Darren Bishop
I am currently developing a mote testbed management software.

Here are some hints:

1. Use udev to detect when motes are attached or detached.
2. Through udev you can set up an instance of serial forwarder to listen to
that mote - local address is taken to mean the serial/COM port.
3. For each instance of sf, use a different TCP port; devise some mapping
scheme for consistency - if you have multiple machines, perhaps use some
unique part of the machine/host name. In other words, use a global naming
scheme.

If you are not on Linux i.e. you are using Windows, Google for a udev
equivalent, or poke around 'Control Panel'.

Best regards,
 
---
Darren Bishop

-Original Message-
From: José L. Ponce [mailto:[EMAIL PROTECTED] 
Sent: 24 August 2006 10:36
To: Michael Schippling
Cc: tinyos-help@millennium.berkeley.edu
Subject: Re: [Tinyos-help] Serial Forwarder Problem

Hello,

> All the messages to and from your 50 re-Motes go through one
> TOSBase mote on the MIB adapter to get to the host computer
> where SerialForwarder (or any other client program) is running.
> The messages are distinguished by a destination address (e.g.,
> the addr field in the TOS_Msg struct in ...tos/types/AM.h), and
> sometimes contain a source address so you can tell where they
> came from. To send a message to a specific mote you put it's
> moteID in the destination address.
>
> Was that the question?
> MS

For the case of using a single mote with TOSBase which forwards messages
it is clear. But, say we got two motes connected per USB to the computer.
We would need two instances of SerialForwarder, each associated to one of
the motes, and if a program on the computer wants to communicate with one
of the motes, it would have to know which SerialFowarder to connect to.

How would I have to do that?

And going a bit further. The ideal case would be to have a program which
automatically checks USB ports, gets the mote address of each mote
connected and creates a SerialForwarder association with each mote, so
that if a program wants to send a message to a mote, it only needs to know
its local address. I am sure something similar already exists. I would
like to know is it done.

Thanks,

- J.



-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.405 / Virus Database: 268.11.3/423 - Release Date: 18/08/2006
 


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


[Tinyos-help] Re: Debbuging Interface

2006-08-18 Thread Darren Bishop
Today was a day of discovery.

I am using tinyos-1.x and thus nesC1. I found the C attribute after reading 
the reference manual and in doing so got a concrete understanding of how nesC 
works on the whole.

The way I have implemented my logging API, it no longer matters who uses the 
UART and when; the API is just for convenience (yes I got lumbered with 
implementing infrastructure, tools, etc).

I looked as far deep as to see the byte transmission code, but retreated in 
fear of breaking the whole stack.

Currently I have a 'standalone' LoggingC component, LoggingM component, a 
Logging interface that can be used (coupled with 2 variadic macros, LOGF and 
LOGSF) or a lprintf function that takes a function pointer (NULL if feedback 
is not required) to a 'logDone' type function, and a format string and a 
variable argument list.

If anyone is interested in the code, don't hesitate to ask.
-- 
Warm regards,

Darren Bishop, MSc, BSc (Hons), MBCS

On Friday 18 August 2006 20:27, Philip Levis wrote:
> On Aug 18, 2006, at 1:55 AM, Darren BISHOP wrote:
> > Hi All,
> >
> > Ted: Can you give details on your debugging interface?
> >
> > Phil: I have implemented a C function with declaration 'extern
> > result_t lprintf(result_t *status, char *format, ...). The
> > definition is included by a LoggingM component that sends to UART
> > when on Tmote Sky or calls dbg when on TOSSIM.
> >
> > Is there anyway to access the UART i.e. send to it, from this C
> > function. At some point I will be able to assert that no other
> > component will be sending to UART other than through this
> > 'interface'; essentially I am trying to replicate dbg(...) when
> > running on mote hardware.
> >
> > As it is, my implementation maintains a circular log-buffer which
> > the LoggingM component must poll to learn when work needs to be
> > done, that is, send to UART. What timer-rate do you think is
> > reasonable in order to yield an acceptable trade-off (i.e.
> > performance hit due to context switching vs. promptness of
> > logging)? Should this be user-definable (perhaps in the form of a
> > compile-time option) where only the user will really know how much
> > (read: frequent) logging would be used, and also how dependent (pc-
> > side) processes are on timelyness; what's your opinion?
>
> TinyOS 1.x or 2.x?
>
> The most important thing is to *not* write a blocking interface. It
> sounds like you're already along that route, which is good.
>
> If the question is "how do you I get C code to call nesC code?" the
> answer is pretty simple. In a component who can call the functions
> you care about, you define your lprintf with the attributes "C" and
> "spontaneous". David Gay probably knows best whether the latter is
> truly required to be 100% safe, but I tend to forget such things and
> so always include it. This means it won't be munged in the nesC
> namespace. Then define a header file somewhere that declares the
> function.
>
> E.g.:
>
> module DebugMagic {
>uses interface SomeByteLevelUartInterface as Bytes; // depends on
> 1.x or 2.x
> }
> implementation {
>result_t lprintf(result_t* status, char* format, ...)
> __attribute__ ((C, spontaneous)) {
>  call Bytes.put(...);
>}
>// OR, depending on your nesc1 version,
>
>
>result_t lprintf(result_t* status, char* format, ...) @C()
> @spontaneous() {
>  call Bytes.put(...);
>}
> }
>
> If the question is about making sure nobody sends other stuff to the
> serial port, that's a bit harder in 1.x because there is no resource
> management. My best recommendation would be to include a version of
> GenericComm that does not include the UART. I think you want to wire
> to HPLUARTC.
>
> If in 2.x, then on the Telos you want to instantiate a Uart1C to
> acquire the UART resource. You'll need to turn off the
> SerialActiveMessageC stack (call stop()), as when it starts it
> acquires the resource and does not release it until it stops.
>
> Phil
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help


[Tinyos-help] Re: Debbuging Interface

2006-08-18 Thread Darren BISHOP




Also realised that
keywords like static or extern, do sod all as I discovered when
my app wouldn't compile due to redefinition errors.

Just wanted to share this in-case anyone else had special needs that
necessitated coding against the nesC/TinyOS programming model.

Darren

Darren BISHOP wrote:
Nevermind,
  
  
I am exploring using function pointers; it compiles, I guess as they
aren't used in command/event signatures.
  
  
Also discovered the C attribute - I am hoping this will allow access to
the modules namespace. If anyone is curious, read the 'nesC 1.1
Language Reference Manual', in particular nesC Applications and
Miscellaneous sections.
  
  
Best regards,
  
  
Darren
  
  
Darren BISHOP wrote:
  
  Hi All,


Ted: Can you give details on your debugging interface?


Phil: I have implemented a C function with declaration 'extern result_t
lprintf(result_t *status, char *format, ...). The definition is
included by a LoggingM component that sends to UART when on Tmote Sky
or calls dbg when on TOSSIM.


Is there anyway to access the UART i.e. send to it, from this C
function. At some point I will be able to assert that no other
component will be sending to UART other than through this 'interface';
essentially I am trying to replicate dbg(...) when running on mote
hardware.


As it is, my implementation maintains a circular log-buffer which the
LoggingM component must poll to learn when work needs to be done, that
is, send to UART. What timer-rate do you think is reasonable in order
to yield an acceptable trade-off (i.e. performance hit due to context
switching vs. promptness of logging)? Should this be user-definable
(perhaps in the form of a compile-time option) where only the user will
really know how much (read: frequent) logging would be used, and also
how dependent (pc-side) processes are on timelyness; what's your
opinion?


Best regards,


Darren B

  
  




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

[Tinyos-help] Re: Debbuging Interface

2006-08-18 Thread Darren BISHOP

Nevermind,

I am exploring using function pointers; it compiles, I guess as they 
aren't used in command/event signatures.


Also discovered the C attribute - I am hoping this will allow access to 
the modules namespace. If anyone is curious, read the 'nesC 1.1 Language 
Reference Manual', in particular nesC Applications and Miscellaneous 
sections.


Best regards,

Darren

Darren BISHOP wrote:

Hi All,

Ted: Can you give details on your debugging interface?

Phil: I have implemented a C function with declaration 'extern 
result_t lprintf(result_t *status, char *format, ...). The definition 
is included by a LoggingM component that sends to UART when on Tmote 
Sky or calls dbg when on TOSSIM.


Is there anyway to access the UART i.e. send to it, from this C 
function. At some point I will be able to assert that no other 
component will be sending to UART other than through this 'interface'; 
essentially I am trying to replicate dbg(...) when running on mote 
hardware.


As it is, my implementation maintains a circular log-buffer which the 
LoggingM component must poll to learn when work needs to be done, that 
is, send to UART. What timer-rate do you think is reasonable in order 
to yield an acceptable trade-off (i.e. performance hit due to context 
switching vs. promptness of logging)? Should this be user-definable 
(perhaps in the form of a compile-time option) where only the user 
will really know how much (read: frequent) logging would be used, and 
also how dependent (pc-side) processes are on timelyness; what's your 
opinion?


Best regards,

Darren B

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


[Tinyos-help] TOSSIM-CC2420

2006-08-18 Thread Darren BISHOP




Hi all,

Is there any community feedback on TOSSIM-CC2420? Is there a
description of how to use TestPC2420?

When I compile with make
pc sim,telos, I see a lots of warnings - is this
normal?

Darren



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

[Tinyos-help] Debbuging Interface

2006-08-18 Thread Darren BISHOP

Hi All,

Ted: Can you give details on your debugging interface?

Phil: I have implemented a C function with declaration 'extern result_t 
lprintf(result_t *status, char *format, ...). The definition is included 
by a LoggingM component that sends to UART when on Tmote Sky or calls 
dbg when on TOSSIM.


Is there anyway to access the UART i.e. send to it, from this C 
function. At some point I will be able to assert that no other component 
will be sending to UART other than through this 'interface'; essentially 
I am trying to replicate dbg(...) when running on mote hardware.


As it is, my implementation maintains a circular log-buffer which the 
LoggingM component must poll to learn when work needs to be done, that 
is, send to UART. What timer-rate do you think is reasonable in order to 
yield an acceptable trade-off (i.e. performance hit due to context 
switching vs. promptness of logging)? Should this be user-definable 
(perhaps in the form of a compile-time option) where only the user will 
really know how much (read: frequent) logging would be used, and also 
how dependent (pc-side) processes are on timelyness; what's your opinion?


Best regards,

Darren B

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


Re: [Tinyos-help] Re: "Uses" parameterized interfaces

2006-08-15 Thread Darren BISHOP

Try this:

module A {
   uses IF as IFB;
   uses IF as IFC;
}
implementation {
   bool iLikeAMore;
   ...
   task void some_task() {
   if (iLikeAMore)
   IFA.some_command();
   else
   IFB.some_command();
   }
}

configuration A {
}
implementation {
   components A, B, C;
   .
   .
   A.IFB -> B.IF;
   A.IFC -> C.IF;
   .
   .
}

You could also try 'using' a parameterized interface i.e. the opposite 
of providing one; combined with some enums, this might work:


configuration A {
}
implementation {
   components A, B, C;
   .
   .
   A.IF[B_IMPL] -> B;
   A.IF[C_IMPL] -> C;
   .
   .
}

This second suggestion is just an 'out-there' thought; prob best to 
stick with the first example as it is the recommend wiring.


Best regards,

Darren
Arijit Ghosh wrote:

No that will not work.

Each of the two components B and C "provides" the
interface IF. Lets assume IF has a command
some_command:

interface IF {
 command result_t some_command();
}

B and C provides their own implementation.
Ex. in B, I have

command result_t IF.some_command() {
/* Some implementation */
}

And in C:
command result_t IF.some_command() {
/* Some different implementatio */
}

Now A wants to use the IF interface provided by B and
C.
How do I do it?
  


"Do the best you can, with what you have, where you are." -- Roosevelt

__
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


[Fwd: Re: [Tinyos-help] Parameterized Interfaces]

2006-08-15 Thread Darren BISHOP

Hey all,

Just occurred to me that you can include the following command to any 
parameterized interface:


command uint8_t .getid[uint8_t id]() {
   return id;
}

Best regards,

Darren

 Original Message 

Shane, you are  dy marvelous.

--
Warm regards,

Darren Bishop, MSc, BSc (Hons), MBCS

On Monday 14 August 2006 03:24, Shane B. Eisenman wrote:

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 constant function. Therefore, i'm thinking
perhaps something like this would work:

   enum my_Interface_IDs {
 Interface_1_const = unique("Interface"),
 ...
   };

   configuration X {
 ...
   }

   implementation {
 components A, B;

 A -> B.Interface[Interface_1_const];
   }

Now you have a symbol 'Interface_1_const' assigned the value of the unique
id, you can reference at run time.

-shane


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

On Mon, 14 Aug 2006, Darren Bishop wrote:
> Hi, does anyone know how to obtain the parameter values from within the
> wired component e.g. in A where
>
> A -> B.Interface[unique("Interface")];
>
> Is there by any chance some variable name that when referenced from
> within any of A.Interface's commands/events will yield that unique value?
>
> --
> Warm regards,
>
> Darren Bishop, MSc, BSc (Hons), MBCS
> ___
> 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] nesdoc component graphs

2006-08-15 Thread Darren BISHOP

Thanks for your response David.

I have read up enough on the dot language (which wasn't much) to know it 
probably just takes describing the style of nodes differently, possibly 
to reflect that the 'unit' is an interface, configuration or module.


I/we are using tinyos-1.x; is it the same version of nesdoc that is 
used? If so, would you know where in the Python code the dot generation 
and rendering takes place?


Darren Bishop

David Gay wrote:

On 8/13/06, Darren Bishop <[EMAIL PROTECTED]> wrote:

Does anyone know how to produce component graphs standalone i.e. as
gif/jpg/svg images and also does anyone know how to change the style 
of them?


The latest version of nesdoc (it's in the tinyos 2 CVS, or in the
tinyos-tool for 2.x rpm), which does all this is written (mostly) in
python, but doesn't have a "give me the graph for this component only"
facility. That would probably be useful... (for the next version,
maybe...). Note that this python-based version is used for 2.x
programs only, except if you pass it a -new option (see man nesdoc).

If you want to change the graph's style, the easiest would be to
change the python code which generates the "dot" file which is passed
to the dot tool mentioned in the other answers. Or you could edit the
generated "dot" input files after the fact, and rerun dot - they are
left in the
 //chtml
directory.

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] motelist

2006-08-15 Thread Darren Bishop








These should help. As far as I know TelosB
is Moteiv hardware; I expect this is just a discrepancy in the devices description
(in the driver).

 

http://cents.cs.berkeley.edu/tinywiki/index.php/Tmote_Windows_install

 

http://www.moteiv.com/community/Tmote_Windows_install

 

Goodluck.

 



Best regards,

 

---

Darren Bishop











From: Abu [mailto:[EMAIL PROTECTED] 
Sent: 14 August 2006 23:47
To:
tinyos-help@Millennium.Berkeley.EDU
Subject: [Tinyos-help] motelist



 

Hi,

I'm getting the following error when I type in the motelist command in cygwin.
motelist : Command not found

I am using the TelosB mote and I have installed the ftdi driver as
specified...
In the hardware device manager there is a new entry called USB serial
converter. Location 0 (Crossbow Telos Rev.B)

Does this mean that the COM port is COM 0, I don't know how to determine that
either...

Is there a help or getting started guide for tinyOS and cygwin that I can use
to help me with this issues...

Commands such as lsmod don't work in cygwin... 


Thanks,
Abu Amprayil








--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.405 / Virus Database: 268.10.9/417 - Release Date: 11/08/2006
 
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] Parameterized Interfaces

2006-08-13 Thread Darren Bishop
Shane, you are  dy marvelous.

-- 
Warm regards,

Darren Bishop, MSc, BSc (Hons), MBCS

On Monday 14 August 2006 03:24, Shane B. Eisenman wrote:
> 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 constant function. Therefore, i'm thinking
> perhaps something like this would work:
>
>enum my_Interface_IDs {
>  Interface_1_const = unique("Interface"),
>  ...
>};
>
>configuration X {
>  ...
>}
>
>implementation {
>  components A, B;
>
>  A -> B.Interface[Interface_1_const];
>}
>
> Now you have a symbol 'Interface_1_const' assigned the value of the unique
> id, you can reference at run time.
>
> -shane
>
> 
> http://www.comet.columbia.edu/~shane
>
> On Mon, 14 Aug 2006, Darren Bishop wrote:
> > Hi, does anyone know how to obtain the parameter values from within the
> > wired component e.g. in A where
> >
> > A -> B.Interface[unique("Interface")];
> >
> > Is there by any chance some variable name that when referenced from
> > within any of A.Interface's commands/events will yield that unique value?
> >
> > --
> > Warm regards,
> >
> > Darren Bishop, MSc, BSc (Hons), MBCS
> > ___
> > 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] Parameterized Interfaces

2006-08-13 Thread Darren Bishop
Hi, does anyone know how to obtain the parameter values from within the wired 
component e.g. in A where

A -> B.Interface[unique("Interface")];

Is there by any chance some variable name that when referenced from within any 
of A.Interface's commands/events will yield that unique value?

-- 
Warm regards,

Darren Bishop, MSc, BSc (Hons), MBCS
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help


Re: [Tinyos-help] hai , can anybody get me a solution..............:)

2006-08-13 Thread Darren BISHOP
primalfear: DO YOU THINK I AM LYING? TinyOS is written in nesC so you 
must write your code in nesC - or else write you own Cpp2nesC 
preprocessor/converter, but lets face it, learning nesC would be quicker.


No-one is going to tell you what you want to hear. If your situation is 
that urgent you should listen to the advice you are given.


All: Does anyone have any better advice? I think the OP needs to hear 
unanimously from the community that the solution he wants is not possible.


Please correct me otherwise.

Best regards

Darren

primalfear 69 wrote:
 
hai,
 
  my basic aim is to write a c\c++ program and burn it  into the 
target mote(mica2) using the tinyos platform
 
1. for this i have written a program in c++ and compiled it using the 
make command..i got the exe file and .o file.but i am not 
getting the hex file.so what should i do to get the hex file. 
or which is the final output file to be burnt??
 
alternatively, i wrote the same c++ program in eclipse,i tried to 
build it up..even then i got the same exe file ,binaries and the 
.o file but not able to get any hex file .:(
 
so could anyone get me a  solution . its urgent.  :((
 
primalfear


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


[Tinyos-help] nesdoc component graphs

2006-08-13 Thread Darren Bishop
Does anyone know how to produce component graphs standalone i.e. as 
gif/jpg/svg images and also does anyone know how to change the style of them?

-- 
Warm regards,

Darren Bishop, MSc, BSc (Hons), MBCS
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help


Re: [Tinyos-help] Passing Arguments at compile time

2006-08-12 Thread Darren Bishop
I have explained how to set source and destination nodes.

What you now need to do is use conditional branching in your makefile:

ifdef SRC
PFLAGS += -DSRC_NODE=$(SRC)
else
PFLAGS += -DSRC_NODE=0
endif

Invoke make like so:

prompt$ SRC=2 make pc

-- 
Warm regards,

Darren Bishop, MSc, BSc (Hons), MBCS

On Saturday 12 August 2006 09:33, saadia khan wrote:
> Thankyou for answering.
> I know about adding these flags in the makefile. What I exactly need to
> know is that how to set the ids of source and destination nodes at the
> compile time or runtime as arguments e.g., at command prompt something like
> following:
>
> //for compiling a pc simulation
> make SRC_NODE=33 DEST_NODE=12  pc
> // or for runtime
> main.exe num_nodes=50 src=24 dest=38
>
> i am asking for compile time because as you know, each mote is seperately
> compiled and run, but in case of simulation, its all done in one exe.
> Thankyou again,
>
> S khan
>
>
>
>
>
>
> - Original Message 
> From: Darren Bishop <[EMAIL PROTECTED]>
> To: saadia khan <[EMAIL PROTECTED]>; tos help
>  Sent: Saturday, August 12, 2006
> 12:41:18 PM
> Subject: RE: [Tinyos-help] Passing Arguments at compile time
>
>   All you need to do is define and use a compile-time flag eg:
>
>
>In your application directory e.g. apps/Blink equivalent, open Makefile
> and add:
>
>PFLAGS+= –DSRC_NODE=2
>PFLAGS+= –DDEST_NODE=49
>
>These are pre-processor flags. In your code simply test there value:
>
>If (SRC_NODE == TOS_LOCAL_ADDRESS) {
>;// do something interesting
>}
>
>Likewise for DEST_NODE.
>
>I am writing a site-survey experiment myself at the moment. It is
> scripted using Python and I have implemented Command Interpreter
> components, which effectively communicate with the Python script over UART.
> Using this I can set which node is the transmitter at runtime. There is a
> component suite called Command (or near enough…) which provides this
> functionality (obviously I discovered it too late and haven’t delved into –
> a retro-fit maybe a possibilty); review the source to see if it fits your
> needs
>
>  Best regards,
>
>---
>Darren Bishop
>
>
>   From: saadia khan [mailto:[EMAIL PROTECTED]
>  Sent: 12 August 2006 08:04
>  To: tos help
>  Subject: [Tinyos-help] Passing Arguments at compile time
>
>
>Hi all,
>
>  I'm currently implementing a routing protocol in tinyos as a TOSSIM
> simulation. If want to set a node as source node and another as a
> destination node. What i need to know is that whether i should do this at
> compile time or run time, because for simulation i think it doesn't matter
> if i take the arguments at runtime or compile time, but since i want this
> implementation to be flexible enough to accomodate the motes later on (i'm
> not using them right now), so what is the right way to do this? Secondly,
> if it has to be at compile time then, what is the correct procedure to do
> that? i figured it out that i'll have to deal with the makefiles but need
> guidance in this case.
>
>  Thank you
>  S Khan

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


RE: [Tinyos-help] Passing Arguments at compile time

2006-08-12 Thread Darren Bishop








All you need to do is define and use a
compile-time flag eg:

 

 

In your application directory e.g.
apps/Blink equivalent, open Makefile and add:

 

PFLAGS+= –DSRC_NODE=2

PFLAGS+= –DDEST_NODE=49

 

These are pre-processor flags. In your
code simply test there value:

 

If (SRC_NODE == TOS_LOCAL_ADDRESS) {

    ;// do something
interesting

}

 

Likewise for DEST_NODE.

 

I am writing a site-survey experiment
myself at the moment. It is scripted using Python and I have implemented Command
Interpreter components, which effectively communicate with the Python script
over UART. Using this I can set which node is the transmitter at runtime. There
is a component suite called Command (or near enough…) which provides this
functionality (obviously I discovered it too late and haven’t delved into
– a retro-fit maybe a possibilty); review the source to see if it fits
your needs 

 



Best regards,

 

---

Darren Bishop











From:
saadia khan [mailto:[EMAIL PROTECTED] 
Sent: 12 August 2006 08:04
To: tos help
Subject: [Tinyos-help] Passing
Arguments at compile time



 





Hi all,

I'm currently implementing a routing protocol in tinyos as a TOSSIM simulation.
If want to set a node as source node and another as a destination node. What i
need to know is that whether i should do this at compile time or run time,
because for simulation i think it doesn't matter if i take the arguments at
runtime or compile time, but since i want this implementation to be flexible
enough to accomodate the motes later on (i'm not using them right now), so what
is the right way to do this? 
Secondly, if it has to be at compile time then, what is the correct procedure
to do that? i figured it out that i'll have to deal with the makefiles but need
guidance in this case.

Thank you
S Khan










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

[Tinyos-help] RE: how to program the MICA2

2006-08-12 Thread Darren Bishop








Sorry, in my last e-mail I meant you have
to use gdb, not dbg – although, you will find it useful dbg(…)
calls in you code.

 

The tools you have to go away and research
are:

 

TinyOS – tutorials and source code
would be good start

TOSSIM – there are white papers for
this

ncc – man pages

gdb – man pages

mica2 – refer to the vendor
documentation

 

You are not going to learn this stuff
over-night and there are no silver-bullets nor substitutes for reading the literature.

 

Please email the mail list in future. If
you email me directly I will not reply

 



Best regards,

 

---

Darren Bishop











From:
primalfear 69 [mailto:[EMAIL PROTECTED] 
Sent: 12 August 2006 06:14
To: Darren BISHOP
Subject: Re: how to program the
MICA2



 



hello darren.





thanks for that but then it wud be really good if i get a bit more
elaborated version of u r previous mail...:D.





hope for that soon..





 





thanks again





 





Regards





Primalfear

 





On 8/11/06, Darren
BISHOP <[EMAIL PROTECTED]>
wrote: 





Compile it as tossim i.e. use the make pc option and then run it
through dbg

Regards







primalfear 69 wrote: 



hi,





 





  thanku verymuch for ur
reply..can u say me how to debug a nesc program





 





Regards,





Primalfear

 





On 8/9/06, Darren
BISHOP <[EMAIL PROTECTED]
> wrote: 

From your other e-mail, I think you mis-understood what your
colleague/friend/adviser said. You can use the CDT Eclipse plugin to 
write TinyOS code - this is because nesC is derived from C. CDT
accommodates both C and C++ programmers but this does not mean you can
write C++ to be used on TinyOS.

What your source did not know is that there are a few Eclipse plugins 
available designed for nesC coding specifically. Google 'Eclipse TinyOS'
to find them.

You will still need to learn nesC as the programming model is
significantly different to C and C++.

I do not know how to upload code to Mica2 motes; we use Moteiv Telosb 
motes here connected by usb. I would run a command like the following:

make telosb install.0 bsl,/dev/hen/motes/USB0

Try changing telosb to mica2

Kind regards,

Darren

primalfear 69 wrote: 
> hello darren
>
> forgot to add in my previous mail if i want to burn sample
> programs given in tinyos (like BLINK etc)... i have builded it
> using make command. i have got for all the platforms. i have one srec 
> file and an exe file... could you now get me how to burn the
> code into MICA2. is there any  IDE for that.?? i have
both the
> programming board and mica board with me in order to test. 
>
> Regards
> Primalfear



 







 






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

Re: [Tinyos-help] set distance between motes in tinyviz

2006-08-05 Thread Darren Bishop
Unfortunately I cannot use TiinyOS-2.0. Maybe Nilay can.

Nilay: Nonetheless, what you are trying to do is possible and I/we have done 
it. I must admit, after just running it again, it does not seem intuitive 
what it is doing: using the same setup as describe earlier but with scale 1, 
a node did not always hear the broadcast of one of its (upto) 4 neighbours; I 
thought being unit disc i.e. 0-loss-rate, that tehy would always hear their 
neighbours.

I do not know what more advice to give this - maybe someone else can offer 
input

-- 
Warm regards,

Darren Bishop, MSc, BSc (Hons), MBCS

On Saturday 05 August 2006 10:31, [EMAIL PROTECTED] wrote:
> I think that if you need a more accurate kind of simulation, you should
> think about using TinyOS 2.0 and Tossim. As a matter of fact the new Tossim
> version gives you the possibility of defining Radio Gains among nodes
> instead of using an empirical model or a radius model as in TinyViz.
> Moreover if you need a particular kind of simulation, you can change the
> GainRadioModel defining your own.
>
> Stefano.
>
>
>
>
>
>
>
> -- Initial Header ---
>
> >From  : [EMAIL PROTECTED]
>
> To  : "Nilay" [EMAIL PROTECTED],"tinyOShelp"
> tinyos-help@Millennium.Berkeley.EDU Cc  :
> Date  : Sat, 5 Aug 2006 08:53:17 +0100
> Subject : Re: [Tinyos-help] set distance between motes in tinyviz
>
> > That plugin is a bit buggy.
> >
> > I have just played with it.
> >
> > i) setup a grid of 100 nodes
> > ii) set the radio model to to fixed radius 10
> > ii) set the scalingfactor to 2
> >
> > At this point all nodes are isolated. For some reason the radius is
> > divided by the scale factor; radius 10 / factor 2 = new-radius 5, hence
> > why all nodes are isolated, given they are 10 apart.
> >
> > The buggyness is in the need to hit ENTER then click update when you
> > change the scale; also be patient as I think responsiveness degrades as
> > the network size increases.
> >
> > --
> > Warm regards,
> >
> > Darren Bishop, MSc, BSc (Hons), MBCS
> >
> > On Friday 04 August 2006 21:29, Nilay wrote:
> > > Thanks Darren,
> > > but that doesnt help too.
> > > I set up the 50 motes in a grid fashion, the distant of each is by 12.5
> > > units (when u enable the grid lines). Chose a radio model with radius
> > > 10.0 but still the either mote can reach any other mote which is way
> > > more than 10.0 units. Can u suggest something more (a plugin usage
> > > manual link)or a working example.
> > >
> > > Thanks,
> > > Nilay
> > >
> > > On Tue, 01 Aug 2006 Darren BISHOP wrote :
> > > >Hey Nilay,
> > > >
> > > >In TinyViz goto the 'Plugins' menu and enable the 'Radio model'
> > > > plugin. Select the corresponding control panel (on the right) and
> > > > choose the radio range e.g. 'Fixed radius (10.0)'. You can then scale
> > > > this by setting the 'Distance scaling factor'; I believe you must use
> > > > the reciprocal of the factor by which you wish to scale.
> > > >
> > > >Hope this helps.
> > > >
> > > >Darren
> > > >
> > > >Nilay Chheda wrote:
> > > >>  Thanks Darren,
> > > >>The real thing I want to do is to limit the radio range to some
> > > >> nodes. I am simulating around 50 nodes and want to form a tree using
> > > >> them. The problem here is that the root (mote 0) broadcast and
> > > >> allocates the even furthest node (consider nodes are placed in a
> > > >> grid fashion)as its child. So I want to limit the radio range to a
> > > >> certain known distance so as to form the next level of the tree. As
> > > >> you said I can use the RadioModel plugin but how do I set the
> > > >> distance so that I can actually get the relation between the radio
> > > >> range and distance parameters. In other other words, set a numerical
> > > >> distance between two nodes to get the numerical radio range. I hope
> > > >> thats not too confusing.
> > > >>
> > > >>Thanks,
> > > >>Nilay
> >
> > ___
> > 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] set distance between motes in tinyviz

2006-08-05 Thread Darren Bishop
That plugin is a bit buggy.

I have just played with it.

i) setup a grid of 100 nodes
ii) set the radio model to to fixed radius 10
ii) set the scalingfactor to 2

At this point all nodes are isolated. For some reason the radius is divided by 
the scale factor; radius 10 / factor 2 = new-radius 5, hence why all nodes 
are isolated, given they are 10 apart.

The buggyness is in the need to hit ENTER then click update when you change 
the scale; also be patient as I think responsiveness degrades as the network 
size increases.

-- 
Warm regards,

Darren Bishop, MSc, BSc (Hons), MBCS

On Friday 04 August 2006 21:29, Nilay wrote:
> Thanks Darren,
> but that doesnt help too.
> I set up the 50 motes in a grid fashion, the distant of each is by 12.5
> units (when u enable the grid lines). Chose a radio model with radius 10.0
> but still the either mote can reach any other mote which is way more than
> 10.0 units. Can u suggest something more (a plugin usage manual link)or a
> working example.
>
> Thanks,
> Nilay
>
> On Tue, 01 Aug 2006 Darren BISHOP wrote :
> >Hey Nilay,
> >
> >In TinyViz goto the 'Plugins' menu and enable the 'Radio model' plugin.
> > Select the corresponding control panel (on the right) and choose the
> > radio range e.g. 'Fixed radius (10.0)'. You can then scale this by
> > setting the 'Distance scaling factor'; I believe you must use the
> > reciprocal of the factor by which you wish to scale.
> >
> >Hope this helps.
> >
> >Darren
> >
> >Nilay Chheda wrote:
> >>  Thanks Darren,
> >>The real thing I want to do is to limit the radio range to some nodes.
> >>I am simulating around 50 nodes and want to form a tree using them.
> >>The problem here is that the root (mote 0) broadcast and allocates the
> >> even furthest node (consider nodes are placed in a grid fashion)as its
> >> child. So I want to limit the radio range to a certain known distance so
> >> as to form the next level of the tree. As you said I can use the
> >> RadioModel plugin but how do I set the distance so that I can actually
> >> get the relation between the radio range and distance parameters. In
> >> other other words, set a numerical distance between two nodes to get 
> >> the numerical radio range. I hope thats not too confusing.
> >>
> >>Thanks,
> >>Nilay
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help


Re: [Tinyos-help] motelist

2006-08-03 Thread Darren BISHOP
Please excuse my asking a really obvious question, but have you actually 
installed the FTDI drivers?


Can you see the key mentioned via regedit?

Best regards

Darren

Sudha Krishna wrote:

Hi,


I am getting the following error when I execute the  "motelist" command:

error, could not open key HKLM\SYSTEM\CurrentControlSet\Enum\FTDIBUS


This question may have come up before, but my search through the
archive did not yield any result.  How can I fix the above error? I am
using tinyos version 1.1.15.



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


Re: Re: Re: [Tinyos-help] set distance between motes in tinyviz

2006-08-01 Thread Darren BISHOP

Hey Nilay,

In TinyViz goto the 'Plugins' menu and enable the 'Radio model' plugin. 
Select the corresponding control panel (on the right) and choose the 
radio range e.g. 'Fixed radius (10.0)'. You can then scale this by 
setting the 'Distance scaling factor'; I believe you must use the 
reciprocal of the factor by which you wish to scale.


Hope this helps.

Darren

Nilay Chheda wrote:
 
Thanks Darren,

The real thing I want to do is to limit the radio range to some nodes.
I am simulating around 50 nodes and want to form a tree using them.
The problem here is that the root (mote 0) broadcast and allocates the 
even furthest node (consider nodes are placed in a grid fashion)as its 
child. So I want to limit the radio range to a certain known distance 
so as to form the next level of the tree.
As you said I can use the RadioModel plugin but how do I set the 
distance so that I can actually get the relation between the radio 
range and distance parameters.
In other other words, set a numerical distance between two nodes to 
get  the numerical radio range.

I hope thats not too confusing.

Thanks,
Nilay



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


Re: [Tinyos-help] HowTo use Acknowledge

2006-08-01 Thread Darren BISHOP

Hi Ale,

On telosb there is the CC2420Control interface which you can use to 
switch on acknowledgments; this is not synonymous to reliable 
communication, but it gives you a primitive to implement such. I am told 
it depends on the version of your hardware whether it is on by default.


I do not know for sure, but I would assume the Micaz worked the same way.

Best regards,

Darren

Ale wrote:

Hi,

Micaz and telos have implemented reliable communication?

If yes, is there an (example) application that use the acknowledge, or
tutorial that explain how to use it? 

Otherwise, how could I allow reliable communication? 
I thought to use TDM so that only mote at once can transimit.


Thanks in advance



  


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


Re: [Tinyos-help] inject commands at runtime in tinyviz

2006-07-31 Thread Darren Bishop
You can talk to the simulated mote with id 0 through serial forwarder and 
using tossim-serial@.

I am not sure but it seems you can send to ANY mote's radio by using 
[EMAIL PROTECTED]; I have not tested this and have actually just noticed 
the feature.

Alternatively, you can set a mote's ADC channel in TinyViz and program the 
mote to read and react to certain values.

-- 
Warm regards,

Darren Bishop, MSc, BSc (Hons), MBCS

On Monday 31 July 2006 03:02, Nilay Chheda wrote:
> Hi,
> I am running my simulations on TOSSIM ( tinyviz ). Is there any way I can
> inject commands into the network of motes at runtime.
>
> Thanks
> Nilay
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help


Re: [Tinyos-help] set distance between motes in tinyviz

2006-07-31 Thread Darren Bishop
Hi Nilay,

To set location you need to use the LocationPlugin. If you want to set radio 
ranges, you must use the RadioModelPlugin and/or the RadioModelGuiPlguin. You 
can set the unit disk range or use a emperical loss model.

I doubt this is exactly what you wanted but I think it should shed some light.

-- 
Warm regards,

Darren Bishop, MSc, BSc (Hons), MBCS

On Monday 31 July 2006 03:01, Nilay Chheda wrote:
> Hi,
> I am usiing tinyviz for my simulations. i need to set distance between the
> motes in tinyviz ("directed graph" plugin) so that motes do not  send
> messages to long distances as they do now.
> Also, currently tinyviz does show some red/gree/blue lines along with some
> numbers but i am unable to understand.
> Could anyone help me out in this.
>
> Thanks
>
> Nilay
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help


Re: [Tinyos-help] Help request: How to write to Telosb/TmoeSky ?

2006-07-30 Thread Darren Bishop
Hi Michael,

I think you are still not getting the problem I was having; I do really 
appreciate your help and responses. I am re-posting just to make the 
situation clear for future readers.

I was not trying to broadcast the packet I was sending over the serial port 
i.e. to use the mote as a relay. I simply wanted to send the packet to that 
mote on that serial port and for it to react e.g. flash some leds.

The best analogy I can give is as follows:

You have a host PC, A,with IP address 192.168.0.2/24 from which you want to 
send a packet to host B with address 192.168.0.3/24.
What I believe I was doing, by sending to 0x7e (UART), was sending to 
localhost or 127.0.0.1 on host A; the correct thing to do is to send to 
either 192.168.0.3 (host B) or 192.168.0.255 i.e broadcast to the local 
network, in which case host B would process the packet.

Given the port is connected to only one mote, it is safe enough to just use 
the broadcast address, in which the mote will process the packet. Clearly 
packets that come off the radio or the serial port obviously go through the 
same processing.

Thanks again.

-- 
Warm regards,

Darren Bishop, MSc, BSc (Hons), MBCS

On Sunday 30 July 2006 20:38, Michael Schippling wrote:
> OK, if I understand the issue, you were sending a message from the host
> to a (or all) mote and you used the UART addr as the destination in the
> message, which makes a certain kind (but not the TOS kind of) sense.
> That message was never sent, because it was addressed to the UART and
> didn't need to be forwarded over the radio. The addressing model is
> not entirely symmetrical in this case, and I think this is common to
> all TOS platforms. There is no way to specify a radio address from the
> host if you have to use that field to get the message over the serial
> line to the base station.
>
> Sorry for my mis-reading of your original help request...
> Glad you figured this one out and are now ready for some new sleep loss.
> MS
>
> Darren Bishop wrote:
> > Hello Michael, Lei, All,
> >
> > I have solved the problem. I had been doing everything write except for
> > the address I was specifying. I had read in a Tinyos-help thread started
> > by Lei Tang (post by Julia) that you had to specify the  UART address as
> > destination. This does not work for me (maybe due to telosb platform) and
> > it is the one reason I have been loosing sleep for 2 weeks; you can
> > specify either the broadcast address or the motes address. I have tested
> > this both in C going via serial forwarder and in my direct python
> > application.
> >
> > Lei: I could not tell if you ever solved your problem: like the advice I
> > was getting from my supervisor, you may have moved on to a different
> > task, to come back to this later.
> > In my experience the crc does matter. I am using GenericComm and my
> > component is not signalled if I deliberatly mangle the crc pc-side before
> > sending. Look at Crc.java or serialsource.c for implementations of the
> > crc algorithm. You maybe using a component/interface too low-level to
> > benefit from the crc i.e. the check fails but you're working at a level
> > where processing occurs regardless. Use GenericComm.
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help


Re: [Tinyos-help] Help request: How to write to Telosb/TmoeSky ?

2006-07-30 Thread Darren Bishop
Hello Michael, Lei, All,

I have solved the problem. I had been doing everything write except for the 
address I was specifying. I had read in a Tinyos-help thread started by Lei 
Tang (post by Julia) that you had to specify the  UART address as 
destination. This does not work for me (maybe due to telosb platform) and it 
is the one reason I have been loosing sleep for 2 weeks; you can specify 
either the broadcast address or the motes address. I have tested this both in 
C going via serial forwarder and in my direct python application.

Lei: I could not tell if you ever solved your problem: like the advice I was 
getting from my supervisor, you may have moved on to a different task, to 
come back to this later.
In my experience the crc does matter. I am using GenericComm and my component 
is not signalled if I deliberatly mangle the crc pc-side before sending. Look 
at Crc.java or serialsource.c for implementations of the crc algorithm.
You maybe using a component/interface too low-level to benefit from the crc 
i.e. the check fails but you're working at a level where processing occurs 
regardless. Use GenericComm.

-- 
Warm regards,

Darren Bishop, MSc, BSc (Hons), MBCS

On Sunday 30 July 2006 06:57, Michael Schippling wrote:
> Looks to me like your CommandMsg stuff is here, in lsb order:
>
> Pkt: 7e 42 06 01 08 14 ff ff 7d 5e 00 14 7d 5d 03 00 00 80 0a 00 ba eb 7e
> ^ ^ ^
> cmd   mask  arg
>
> The 7e's are message sync bytes, and the 7d5e and 7d5d are escaped values
> which map to 7e and 7d (I think...). In any case have a look at the
> OcataveTech page for interpretation of the message stream:
> http://www.octavetech.com/pubs/TB5-01%20Deciphering%20TinyOS%20Serial%20Pac
>kets.pdf
>
> was that the question?
> MS
>
> Darren Bishop wrote:
> > Could someone please help me with writing to Moteiv telosb motes? I am
> > working with Python, but I do not expect this will matter much due to the
> > tight coupling with C.
> >
> > The following struct describes what I am trying to send:
> >
> > struct CommandMsg {
> > uint16_t cmd;   // = 3
> > uint16_t mask;  // = 1<<15
> > uint16_t arg;   // = 10
> > };
> >
> > The data I send goes through the following transformations:
> >
> > Data: 03 00 00 80 0a 00
> > Message: 14 7d 03 00 00 80 0a 00
> > Packet: 7e 42 06 01 08 14 ff ff 7d 5e 00 14 7d 5d 03 00 00 80 0a 00 ba eb
> > 7e
> >
> > I recall reading that motes are LSB byte order, and hence the ordering I
> > use.
> >
> > Can someone please process these threee 16-bit integers and show me how
> > it is done ?
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help


Re: [Tinyos-help] Help request: How to write to Telosb/TmoeSky ?

2006-07-30 Thread Darren Bishop
Firstly thanks for replying - I appreciate it.

Secondly, no it was not the question. I have already read the reference you 
posted and it did explain a few things that has enabled me to get this far.

The transformations I described are affected by my code; remember I am 
attempting to write to the mote, so we are looking at:

Pkt: 7e 42 06 01 08 14 ff ff 7d 5e 00 14 7d 5d 03[14] 00 00[16] 80 0a[18] 00 
ba[20] eb 7e

cmd == pkt[14,15]
mask == pkt[16,17]
arg == pkt[18,19]
(crc == pkt[20,21])

All the extra bytes near the start of the packet are there for the TelosB 
CC2420 radio i.e. it has a different message header to the Micas. Note that 
the mote differentiates between a radio packet and a UART packet by the 
destination address.

So what I am really asking is for someone to construct a packet ready for the 
wire targeting the telosb platform, with 20 as the AM type, 0x7e as the 
destination, 0x7d as the group id, three 16-bit numbers (3, 1<< 15, 10), plus 
the crc calculation
-- 
Warm regards,

Darren Bishop, MSc, BSc (Hons), MBCS

On Sunday 30 July 2006 06:57, Michael Schippling wrote:
> Looks to me like your CommandMsg stuff is here, in lsb order:
>
> Pkt: 7e 42 06 01 08 14 ff ff 7d 5e 00 14 7d 5d 03 00 00 80 0a 00 ba eb 7e
> ^ ^ ^
> cmd   mask  arg
>
> The 7e's are message sync bytes, and the 7d5e and 7d5d are escaped values
> which map to 7e and 7d (I think...). In any case have a look at the
> OcataveTech page for interpretation of the message stream:
> http://www.octavetech.com/pubs/TB5-01%20Deciphering%20TinyOS%20Serial%20Pac
>kets.pdf
>
> was that the question?
> MS
>
> Darren Bishop wrote:
> > Could someone please help me with writing to Moteiv telosb motes? I am
> > working with Python, but I do not expect this will matter much due to the
> > tight coupling with C.
> >
> > The following struct describes what I am trying to send:
> >
> > struct CommandMsg {
> > uint16_t cmd;   // = 3
> > uint16_t mask;  // = 1<<15
> > uint16_t arg;   // = 10
> > };
> >
> > The data I send goes through the following transformations:
> >
> > Data: 03 00 00 80 0a 00
> > Message: 14 7d 03 00 00 80 0a 00
> > Packet: 7e 42 06 01 08 14 ff ff 7d 5e 00 14 7d 5d 03 00 00 80 0a 00 ba eb
> > 7e
> >
> > I recall reading that motes are LSB byte order, and hence the ordering I
> > use.
> >
> > Can someone please process these threee 16-bit integers and show me how
> > it is done ?
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help


[Tinyos-help] Help request: How to write to Telosb/TmoeSky ?

2006-07-29 Thread Darren Bishop
Could someone please help me with writing to Moteiv telosb motes? I am working 
with Python, but I do not expect this will matter much due to the tight 
coupling with C.

The following struct describes what I am trying to send:

struct CommandMsg {
uint16_t cmd;   // = 3
uint16_t mask;  // = 1<<15
uint16_t arg;   // = 10
};

The data I send goes through the following transformations:

Data: 03 00 00 80 0a 00
Message: 14 7d 03 00 00 80 0a 00
Packet: 7e 42 06 01 08 14 ff ff 7d 5e 00 14 7d 5d 03 00 00 80 0a 00 ba eb 7e

I recall reading that motes are LSB byte order, and hence the ordering I use.

Can someone please process these threee 16-bit integers and show me how it is 
done ?
-- 
Warm regards,

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


[Tinyos-help] Help writing to telosb over UART in Python

2006-07-25 Thread Darren Bishop
I am writing a Pyhton software to manage our mote testbed; I must use Python 
to integrate into the 'larger' system and I must use TinyOS-1.x.

I am having trouble writing to the motes over UART. I can read from them 
perfectly i.e. I have implemented the HDLC-like framing and CRC calculation 
and all is well. For example, I read the following from a telosb mote running 
the Oscilloscope image:
rxpkt: 7e 42 0e 00 00 00 00 00 7d 5e 00 1b 7d 5d 00 00 8d 00 00 0d 9c dc 43 01 
00 f6 00 08 66 3f 7e

[As an aisde, can anyone explain why the payload length is moved to rxpkt[2], 
and where bytes rxpkt[3-7] come from?]

My goal here is to implement a 'command interpreter' on the mote, where 
commands are sent from the PC.

The content of CommandMsg.h is as follows:

enum {
COMMAND = 1 << 15,
STATUS = 0 << 15,
INTERNAL = 1 << 14,
EXTERNAL = 0 << 14
};

struct CommandMsg
{
uint16_t cmd;
uint16_t mask;
uint16_t arg;
};

enum {
AM_COMMANDMSG = 20
};

The byte array (Python: array.array('B')) of data I want to send goes through 
the following transformations:

Data: 0b 00 00 00 a3 08 (11, 0, 2211)
Message: 7e 00 1b 7d 0b 00 00 00 a3 08
Packet: 7e 42 06 00 00 00 00 00 7d 5e 00 14 7d 5d 0b 00 00 00 a3 08 f9 f0 7e

The final packet format reflects what I read of the wire i.e. Packet[2] is the 
data length followed by 5 pad bytes.

I open the port with the following Python code (assume necessary modules are 
imported):

def open(self):
self.__fd = os.open(self.__port, os.O_RDWR|os.O_NOCTTY)
iflag, oflag, cflag, lflag, ispeed, ospeed, cc = \
termios.tcgetattr(self.__fd)
cflag = termios.CS8 | termios.CLOCAL | termios.CREAD
iflag = termios.IGNPAR | termios.IGNBRK
oflag = 0 # saw this in serialsource.c
ispeed = termios.__dict__['B'+str(self.__baudrate)]
ospeed = termios.__dict__['B'+str(self.__baudrate)]

termios.tcflush(self.__fd, termios.TCIFLUSH);
termios.tcsetattr(self.__fd, termios.TCSANOW, \
[iflag, oflag, cflag,  lflag, ispeed, ospeed, cc]);


When I write the packet, the little green LED by the mote-USB connector (not 
the main 3-LEDS) flashes, but I do not get the desired result i.e. the main 
red-LED does not switch on (as it is 'commanded' to).

Has anyone achieved writing to a (telosb?) mote in C or Python? Have I set the 
wrong output flags (oflag) on the serial port maybe? Have I got the frame 
format wrong?

Your help is appreciated.

-- 
Warm regards,

Darren Bishop, MSc, BSc (Hons), MBCS
___
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help