If you wish to simulate a whole network and connect to it through sossrv as if it were a real physical network being accessed through a base station, you can do the following:

First, create a simulated NIC node:

cd sos-1.x/config/nic
make sim
SOSROOT=../../ ./nic_app.exe --socket 1034

Where 1034 is some listening port. Then, start sossrv (in another terminal instance):

To send a message to another module, all you need to do is call the post_net function:

post_net(sos_pid_t did, 
         sos_pid_t sid,
         uint8_t type, 
         uint8_t len, 
         void *data, 
         uint16_t flag, 
         uint16_t daddr)

Where all parameters should be familiar (if not, check out this page), except for the one called flag. This allows you to tell SOS some extra details about what to do with the message. One use, for example, is to tell SOS to free the memory used by data after the message is sent (set it to SOS_MSG_RELEASE for that). The default value is 0.

The SOS simulator (SOSSIM) allows you to use your PC to simulate an entire sensor network. This is done by navigating to your configuration directory, running make sim and then executing the resulting exe file. Currently, SOS can only simulate the mica2 and xyz platforms (reference).

The SOS server is a program that runs on your PC and provides a bridge between computer applications and sensor network nodes. That is, it forwards messages from the network to any program that connects to its TCP socket (port 7915), and vice-versa.

It communicates to the nodes by physically connecting to one of them (usually called the base node) through the computer's serial port. This base node can then send messages to the PC much the same way it does to other nodes, except instead of using the post_net command, one should use post_uart -- all parameters are the same.

Here's a few things that are missing in this tutorial:

1. provide links to platform-specific steps for installing onto a node
2. talk about debugging

Configuration

Now you know how to compile a configuration, but what exactly is inside the configuration code? To find out, open the following files your favorite text editor: Makefile and blink_app.c

The first one, Makefile, tells the compiler where to find the source code that it will need (in this case, blink.c and loader.c, the main files for the "blink" and "loader" modules). You will also see that it includes another file, called Makerules. This one is much more complicated, and all you need to know about it is that it tells the compiler to compile the SOS kernel and all the platform-specific drivers.

If you look at the SOS directory, you'll see the following subfolders:

config
contrib
devices
include
doc
kernel
drivers
modules
platform
processor
tools

The main ones you will be dealing with are config and modules. This is where the standard SOS configurations and modules reside.

Your own custom modules and configs should go outside the SOS directory. For example, if SOS is in

Since you are still learning SOS and will probably be debugging your modules most of the time, you should always use configurations. Although it is admittedly annoying having to make a configuration for every module you want to write, this gives you more control over what is being executed on the node as well as the ability to use global variables and other goodies.

Without further ado, here's how you compile a configuration. First, cd into the folder of the configuration you wish to compile (in this case, we'll compile the "blink" program, which does nothing other than blink an LED periodically):

Cygwin installation

For this tutorial we assume that you are running Windows. Before you install SOS, you should first download and install Cygwin. Cygwin provides a Unix-like environment in Windows. For more information, go to the Wikipedia page for it. To install it, go to the Cygwin website, click on "Install or update now!" and save the setup program somewhere on your hard-drive (make sure you know where it is).
Once it is done downloading, run setup.exe and follow the on-screen instructions. The default options should all be fine until you come to the package selection page. Make sure you select the following packages (a few of them are required and others are just useful):

Modules and Configs

In SOS jargon, the name module is used to specify something similar to "programs" on your PC. These can be installed on the sensor nodes without the need to reinstall the SOS kernel (the core of the OS). Meanwhile, the name configuration specifies a prepackaged solution consisting of a kernel and a collection of modules. This is akin to having a CD that contains your operating system and all the programs you need, but without the ability to add or remove anything after the OS installation. This way, you would have a system that is very integrated and easier to debug, which is why we recommend that you use configurations when you write a new application. Once your application is up and running you can start thinking about making it into a stand-alone module, so that it can be dynamically loaded on a network.

This is a small SOS how-to that aims to make it easier for someone to start programming in SOS as soon as possible. For more in-depth information, please look at the official SOS tutorial.

If you have questions, use the form below to search the SOS mailing list.

Search

Removing debug code for release version

There's a flag (called CC_DEBUG) you can set on the command line when compiling your SOS projects that allows you to choose the debug parameters you'd like to use. If you don't enter the flag, the parameter defaults to -g, which compiles extra code to enable step-by-step debugging. When you are ready to deploy your network, you should always recompile without the -g flag, because the binaries get leaner and run faster. To do so, you need to assign the CC_DEBUG parameter an empty string, like this: