TinyOS | final project for my CST352-Operating Systems class

I added the new controllers to the the current gcc toochain.

I added the architectures to the my current toolchain. I have answered it here.

Adding a architecture to the base toolchain

I do not think your issue is with toscomm, as long as the library ends up being loaded successfully you should not be getting any issues. I always used to get the same exception that you are seeing being thrown over there everytime I used the serial but never bothered to fix it as it didn't really hamper the operation of the serial port.

In the end, I got rid of the exception by copying libtoscomm from the {TOS_ROOT}/tools/tinyos/java/serial/ directory to one of the directories that TinyOS is looking for libraries in. In your case you would put a copy of the libtoscomm file in one of the directories /usr/java/packages/lib/i386 , /lib or /usr/lib.

You can try doing that and seeing if that resolves the exception issue for you.

What I suspect might be causing your issue is that you do not have TestSerialAppC loaded onto you mote and connected to the serial port. Have you made sure the mote is connected to the serial port?

I loaded ran the application on a mote and got the output below, so the issue is not with TestSerialAppC

You must have skipped the step when you had to run the make command.

Navigate to the apps/tests/TestSerial folder and type make [platform] (such as make telosb, make iris e.t.c), the makefile that will be run will be the makefile in the TestSerial folder which is defined as follows:

TinyOS has an IP stack (6lowPan) called BLIP which supports UDP and TCP although I have never used BLIP personally. See the link HERE for more information. A good point to start would be to look at the UDP-echo application in apps folder of the TinyOS distribution.

You're only supposed to call startOneShot once on a timer - you should only call startOneShot again on the same timer after it has fired. I would suggest either using 3 separate timers for your one shots, or call startOneShot(5 seconds) on boot, then when it fires, call startOneShot again for 2 seconds, then a third time. Use a counter to keep track of how many times it has fired.

Just to explain a bit of background, the authors of TinyOS themselves have explained that TinyOS isn't really an operating system:

TinyOS has a component-based programming model, codified by the nesC language, a dialect of C. TinyOS is not an OS in the traditional sense; it is a programming framework for embedded systems and set of components that enable building an application-specific OS into each application. A typical application is about 15K in size, of which the base OS is about 400 bytes; the largest application, a database-like query system, is about 64K bytes.

TinyOS is a software build system designed to allow software engineers to more easily build software for really tiny devices (like this wireless sensor), which do not have a harddrive. Instead, the program is typically stored inside the microcontroller of the device - the device I linked to for example has 48k bytes of flash memory (small embedded devices like these often use flash memory to store their program). 48k of code isn't very much, so it's really important that when you're making software to load onto the device, it takes up as little space as possible.

So, the 'base footprint of 400 bytes' means that, on top of the code that you (the software engineer) write to do whatever your tiny device needs to do, the TinyOS framework (which supports and provides services for your code) only adds an extra 400 bytes (which is really amazing!) to your program code which will actually be loaded onto the device's flash memory. However, this isn't the only overhead - depending on the device, TinyOS may also include various different supporting drivers for whatever chips and components exist on that device.

See figure 6 in this paper for some examples of actual program sizes.

Because of this I have found that building the same application for different devices using TinyOS can yield very different results. For example if I build a really simple program for the MicaZ wireless sensor I get:

Just for the sake of thoroughness:

Data types come in many shapes and sizes. The two you are referring to are of types unsigned 8 bit integer and unsigned 16 bit integer.

An integer is a whole number that can be positive or negative; however, in the case of types an unsigned integer can only be positive as it does not designate space for a sign (i.e. a negative sign). 8 bit and 16 bit refer to the amount of space the integer takes up in memory. An unsigned 8 bit integer's values can be 0 - 255 while an unsigned 16 bit integer can hold values from 0 - 65,535 (Side note: If you are familiar with networking you may notice that 65,535 is the largest port number possible. This is due to the fact a port number is an unsigned 16 bit integer.)

Hope this helps.

The value is unspecified or this code may even not compile.

In TinyOS, there's a concept of combine functions, which are of signature type f(type, type) and their purpose is to reasonably combine two values of the same type. For error_t there's such a function defined: