A TinyOS HowTo

http://www.mail-archive.com/tinyos-help%40millennium.berkeley.edu/ Online mailing list archive with a search option.

Don’t use “unique” - it sucks. It’s merely a text replacement based function, that does text replacement for every occurence of unique(”key”) in the nesc source file, and every replacement is unique. Thus, if you try something like

  for (...) {
      u = unique("key");
  }

I will get the same value in u every time, which is the one that is the replacement of the (only) occurence of unique(”key”) in this source file. We found this out by looking at the build/<any-platform or pc>/app.c, which is the file created by nesc frontend to gcc. app.c is then cross-compiled with appropriate flags, for the right platform.

It’s easy and reliable to implement your own equivalent of unique by just keeping a static int variable in the component and incrementing it every tiem to get the index. We tried this, and found that the nesc frontend does preserve it as a function (as expected) till app.c, after which it is the usual C-compilation.

The problems with “unique” are well known, and have been resolved in tinyos2.

With what we learnt about unique, we expected the SingleTimer component (and Blink) to work with the key “Timer” replaced by any other key, but it didn’t. We still don’t know why.

Hey guys, check out the MIG heading in http://www.tinyos.net/tinyos-1.x/doc/tutorial/lesson6.html. Great!

I read the 6th tutorial. I learnt the following: the tinyos (nesc) applications GenericBase and TOSBase have functionality to transmit/receive a packet on the wire-port (god knows what you call it: serial/usb/UART) serial port. The javax.comm package is then supposed to provide an api using which you can communicate with the wire-port serial port of your system (irrespective of what you have connected on wire-port: a sensor mote or a printer). The SerialForwarder is then a java application provided by tos developers, that communicates with the wire-port serial port (possibly virtual, as for tmote-sky), and makes available the wire-port (virtual) serial port to network sockets.

I suppose the picture is like:

Mote | TOSBase/GenericBase | Serial Port (mote) ↔ Serial Port (pc) | javax.comm | SerialForwarder | TCP Server Sockets

OR

Mote | TOSBase/GenericBase | USB Port (mote) ↔ USB Port (pc) ↔ ftdi_sio driver ↔ Virtual Serial Port | javax.comm | SerialForwarder | TCP Server Sockets

But then I looked at the SerialForwarder.java code and other codes in the net.tinyos.sf package. I didn’t find javax.comm being used anywhere. It was used in the old sf (in tinyos-1.0), but I didn’t see it’s use in tinyos-1.1. So I’m confused about:

1. where does javax.comm sit
2. what is scenario between usb and serial port

Please give answers.

EEPROMRead and EEPROMWrite are interfaces in tos/interfaces. The module EEPROM (that provides these interfaces) is present in tos/platform/mica, so it’s platform specific. But the interface has been put in the system-wide interface folder. The corresponding interface for PageEEPROM (apparently the thing for telos (not necessarily tmote-sky - yeah, the distinction may actually be important)) is present in tos/platform/telos, and not in the system-wide interface folder tos/interfaces. This seems inconsistent, but that’s how it is. PageEEPROM interface has similar functions, though not identical. It has some pages thingy also, which is not there in EEPROM. So much for the interfaces for mica and telos.

The implementation module and configuration component for PageEEPROM, PageEEPROMC.nc and PageEEPROMM.nc, respectively, reside in tos/lib/Flash/AT45DB/. On digging through moteiv site (see this pdf: http://www.moteiv.com/products/docs/an001-changes.pdf), I found that the flash on telos motes was AT45DB [telosb has STM25P80!]. So it fits in. BUT, yeah, a big BUT, tmote-sky motes have a new kind of flash memory. So I don’t really think the same AT45DB code will work. We need to figure it out. That’s what I’ve gathered from tut8, tos code and moteiv site. “Cheers!”, damn. : Ok, Hemanth gave a code for formatting, reading and writing to the flash on tmote-sky. We just have to copy and paste it wherever we want to use it.

All on telosb AT45DB flash [!!!! STM25P80] and blockstorage: http://www.mail-archive.com/tinyos-help@millennium.berkeley.edu/msg02364.html http://www.mail-archive.com/tinyos-help@millennium.berkeley.edu/msg05512.html

Some more:

http://www.mail-archive.com/tinyos-help@millennium.berkeley.edu/msg02117.html

Guys! TinyDB is already all present in the tos tree: $TOSDIR/tos/lib/TinyDB : all the tos/nesc components, $TOSDIR/tools/java/net/tinyos/tinydb : all the backend java applications to throw in queries and collect results. There’s the TinyDBApp application also in apps, but it’s platform specific code is only for mica . So couldn’t use it. But $TOSDIR/apps/TinyDBApp/README is a good read.

(23:08:17) manub686@gmail.com/Gaim: abe ek cheez bata
(23:08:26) manub686@gmail.com/Gaim: if A.stdc -> B.stdc
(23:08:36) manub686@gmail.com/Gaim: and B.stdc -> C.stdc,
(23:09:01) manub686@gmail.com/Gaim: then isn't A.stdc -> C.stdc redundant?
(23:09:36) manub686@gmail.com/Gaim: let me answer
(23:09:43) manub686@gmail.com/Gaim: bata mera ans sahi hai ki nahin
(23:09:52) manub686@gmail.com/Gaim: suppose i do A.stdc.init
(23:09:58) manub686@gmail.com/Gaim: then B, C both will be inited
(23:10:04) manub686@gmail.com/Gaim: but suppose from B,
(23:10:13) manub686@gmail.com/Gaim: i want to stop C,
(23:10:29) manub686@gmail.com/Gaim: then i would use the wiring B.stdc -> C,
(23:10:43) manub686@gmail.com/Gaim: which i won't be able to do if A.stdc -> C is the only wiring
(23:10:44) manub686@gmail.com/Gaim: right?
(23:12:20) pragup@gmail.com: in the second case b will also stop
(23:12:34) manub686@gmail.com/Gaim: right
(23:12:34) pragup@gmail.com: think of it like the parallel abd series connection in electricity
(23:12:53) manub686@gmail.com/Gaim: abd series?
(23:13:07) manub686@gmail.com/Gaim: yeah, i got it
(23:13:21) pragup@gmail.com: do u mean
(23:13:25) pragup@gmail.com: that
(23:13:33) pragup@gmail.com: thr is wire from a-b, b-c and a-c?
(23:13:37) pragup@gmail.com: aor is it only
(23:13:40) pragup@gmail.com: a-b,a-c?
(23:13:48) manub686@gmail.com/Gaim: no, i mean
(23:13:56) manub686@gmail.com/Gaim: even with a-b, b-c, 
(23:14:04) manub686@gmail.com/Gaim: a-c has value
(23:14:08) manub686@gmail.com/Gaim: if a-c was not there,
(23:14:31) manub686@gmail.com/Gaim: then a couldn't control c without controlling through b
(23:14:40) manub686@gmail.com/Gaim: which means it would have to do the same with b also
(23:14:57) pragup@gmail.com: yup
(23:15:09) pragup@gmail.com: a-b, b-c does bnot imply a-c
(23:15:21) manub686@gmail.com/Gaim: yes

- The code structure, directory tree, and functionality of code parts of BriMon.
- Testing any code for performance: data logging and offline retrival or online packet transmission to base node and then UART or some other mode, and how to program all of these.
- Makefiles? Makrules and all? And the flags that enable the include of platform specific directories? And, in particular, the part that “defines” (-D) the PLATFORM_xxx identifier?

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

Additional Hacks

I first tried with blackdown java, the java installation already on my gentoo system. javax.comm got installed with blackdown (manually), but the getenv script (JNI) in the tos tree didn’t work (the installation was only a shared object file copy to jre/bin, but it didn’t run). I then tried with IBM java, and it ran without any problems. I also read that there’s difficulty installing javax.comm with Sun java. So IBM java is smooth and tested.

I had difficulty locating the USB device node for my mote (not specific to tinyOS installation). I finally found the nodes to be /dev/tts/USB0 and /dev/tts/USB1 (with two motes) (dynamic: udev created. Removed when you unplug the device). Note that these are ftdi_sio driven nodes: serialized USB device nodes. My printer device node is at /dev/usb/lp0 - I believe /dev/usb because it’s a proper usb port, and lp0 because it’s driven by the printer driver). So /dev/tts signifies that the device node is a tty or a character device node, and USB0 says that it’s actually from a USB device, made into a serial port node. With this, on installing my base mote with TOSBase and giving it traffic by another mote with OscilloscopeRF, I was able to see output from that node using:

  od -x < /dev/tts/USB0.

With the device node identified and javax.comm in place, I expected the Listen tool to show some output. It didn’t. I tried

  MOTECOM=serial@/dev/tts/USB0:tmote java net.tinyos.tools.Listen

(from the directory $TOSDIR/tools/java) and it said:

  Error on serial@/dev/tts/USB1:57600: java.io.IOException: Invalid port. Known serial ports:
  - COM1
  - COM2
  - COM3
  .....
  - COM48

I understand javax.comm is mapping COM[i] to /dev/ttyS[i-1]. So ok, one of the serial ports /dev/ttyS[k] should be getting traffic from my mote. od -x with none of them worked. Actually, not that it didn’t give any output, it “intput/output error”! I still tried

  MOTECOM=serial@COM1:tmote java net.tinyos.tools.Listen

and it gave

  tcgetattr() failed on /dev/ttyS0(5)!
  Error on serial@COM1:57600: java.io.IOException: Couldn't configure COM1

After a lot of vain googling, I looked at /etc/udev/rules.d/xx-udev.rules. And that explained it all:

  # tty devices
  KERNEL=="ttyS[0-9]*",   NAME="tts/%n", SYMLINK+="%k", GROUP="tty"
  KERNEL=="ttyUSB[0-9]*", NAME="tts/USB%n", GROUP="tty", MODE="0660"

The kernel serial devices are getting noded to /dev/tts/[i], and also to /dev/ttyS[i], and /dev/ttyS[i] → /dev/tts/[i]. And javax.comm maps COM1 → /dev/tts/[i]. But the actual device is getting noded to /dev/tts/USB0, /dev/tts/USB1... (That explains the error message above, when COM1 was not a valid mote device). So I linked the base mote’s USB node, /dev/tts/USB0 (I put it second in sequence to my usb hub), to /dev/ttyS0. The same invokation worked:

  MOTECOM=serial@COM1:tmote java net.tinyos.tools.Listen

—-
The same happened between

  java net.tinyos.sf.SerialForwarder -comm serial@/dev/tts/USB0:tmote

and

  java net.tinyos.sf.SerialForwarder -comm serial@COM1:tmote

The latter worked, while the former threw errors asking for a COM[i] port.

Note that

  java net.tinyos.sf.SerialForwarder -comm serial@COM1:57600

didn’t work, even though the output of a successful invokation of “java net.tinyos.sf.SerialForwarder -comm serial@COM1:tmote” was

  Listening to serial@COM1:tmote
  Platform telos
  Listening for client connections on port 9001
  serial@COM1:57600: resynchronising

and of “MOTECOM=serial@COM1:tmote java net.tinyos.tools.Listen” was

  serial@COM1:57600: resynchronising

telling that the baudrate is 57600. It is because the application needs to know that it’s a tmote-sky, and not the default avrmote (mica, for example).

If you specify the correct baudrate directly, it is able to communicate, but tries to parse the packet as an avrpacket when it’s actually a tmote-sky packet. If you don’t even specify a correct baudrate and also not the correct platform, you may see absolutely no output, or a synchronization error.

http://coco.cs.uh.edu/research/Isis.htmlhttp://coco.cs.uh.edu/research/Isis.html

http://www.comnets.uni-bremen.de/typo3site/index.php?id=48

http://www.geeksville.com/~kevinh/linuxcomm.html

http://www.crhc.uiuc.edu/~mjmille2/howtos/installing-tinyos-for-telos-on-linux/

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

http://www.eecs.harvard.edu/~mainland/tinyos/

http://gentoo-wiki.com/HOWTO_Installing_3rd_Party_Ebuilds

In Blink directory, to simulate the Blink application:
$ make pc
$ ./build/pc/main.exe 1

In Blink directory, to load the application onto the mote:
$ make telosb install.1 bsl,/dev/tts/USB0
/dev/tts/USB0 is the device node as indicated by, say, motelist (if you have installed that helper script). You can always find out what your device node is.

http://www.cs.berkeley.edu/~pal/pubs/tinyos-nsdi04/ – A good read on various networking abstractions in TinyOs. Useful while implementation.

http://www.eecs.harvard.edu/~mdw/papers/nesc-pldi-2003.pdf – All about programming in NesC.

http://www.eecs.harvard.edu/~mdw/papers/motelab-spots05.pdf

http://nesct.sourceforge.net/index.html
This tool claims to be better than ToSSIM in terms of usability and speed of development
Screenshot: http://www.omnetpp.org/external/images/screensh.png

http://home.iitk.ac.in/~manub/share/rincon.tar.bz2

• extract tar in $TOSROOT/contrib/
• follow the README

cvs -z3 -d:pserver:anonymous@tinyos.cvs.sourceforge.net:/cvsroot/tinyos export -D 2006-08-15 tinyos-1.x/contrib/rincon

This command works (with direct connection). Tested. This was performed on 2006-08-11.

http://www.mail-archive.com/tinyos-help@millennium.berkeley.edu/msg03804.html

check out tinyos-1.x/tos/platform/telos/AM.h for the structure of the AM message. Most of the bytes are part of the MAC header. Bytes Your example uint8_t length; 0×04 - there are only 4 bytes in the data

uint8_t fcfhi;    //0x01 - see IEEE802.15.4 if you really need to know
uint8_t fcflo;    //0x08 - ditto
uint8_t dsn;     // Basically assigns a number to the message for accounting
uint16_t destpan;  //Destination Address (PAN) identifier
uint16_t addr;       //Destination (0xFFFF Broadcasts to all motes)
uint8_t type;        // 0x04 AM_TYPE message type
uint8_t group;      //0x7D   Group Number (125)
int8_t data[TOSH_DATA_LENGTH];  //Data, in your example, you have a 16-bit counter as well as a 16-bit field that gives the TOS_LOCAL_ADDRESS

Hope this helps, Matt

http://www.octavetech.com/pubs/TB5-01%20Deciphering%20TinyOS%20Serial%20Packets.pdf

http://www.moteiv.com/support/tmote-message-format.html [best]

arunsr:

The problem you are trying to address is called serialization. Python has a generic method called ‘pickle’ to do this. You can read more at: http://en.wikipedia.org/wiki/Serialization

One simple way to serialize is to just write out your struct to a string using sprintf (delimit using some character you won’t find in your data), and use sscanf at the receiving end. For small structs, the data size shouldn’t bother you too much.

For a more hard-core approach, you can look at the Boost library (never used it, but I’ve met people who are religious about it): http://www.boost.org/libs/serialization/doc/index.html

aruniyer:

Boost Library is actually pretty good and much faster (used it once on a small network program some years back). However, i do prefer the slower java anyways :P which does serialization in easiest of ways possible.

If you are using python, better use the cPickle lib (faster version of pickle lib).

manub:

Here is a sample program I wrote:

//-----------------------------------------------------------
#include <stdio.h>

typedef struct {
        unsigned char a;
        unsigned short b;
        unsigned int c;
} MyType;

typedef struct {
        unsigned char data[7];
} Raw;

int main() {
        MyType* x = (MyType *)malloc(sizeof(MyType));
        x->a = 0x11; x->b = 0x3333; x->c = 0x22222222;
        Raw* r = (Raw *)x;
        int i;
        for (i = 0; i < 8; i++)
          printf("%.2X ", r->data[i]);
        printf("\n");
}
//-----------------------------------------------------------

arunsr:

I think the point of serialization is precisely to address machine-dependence problems like the padding you see, endianness, etc.

However, if you really want send it a byte at a time, (gosh, this is ugly) maybe you could detect the pad bytes (write 0xff.. to all members, and read the struct contents byte-wise. All zero values are pad bytes). Now you can construct a bit mask or some such to know what bytes in the struct are usable. Note that this doesn’t handle endianness.