LiteOS, A Unix-like Operating System and Programming Platform for by eel17334

VIEWS: 406 PAGES: 13

									           LiteOS, A Unix-like Operating System and Programming Platform
                             for Wireless Sensor Networks

                   Qing Cao, Tarek Abdelzaher                                  John Stankovic
                Department of Computer Science                          Department of Computer Science
            University of Illinois at Urbana-Champaign                       University of Virginia
                   {qcao2, zaher}@cs.uiuc.edu                             stankovic@cs.virginia.edu
                                                       Tian He
                                           Department of Computer Science
                                              University of Minnesota
                                                 tianhe@cs.umn.edu


                         Abstract                                based programming model introduce a learning curve for
                                                                 most developers outside the sensor networks circle. The
   This paper presents LiteOS, a UNIX-like, multithreaded
                                                                 purpose of LiteOS is to significantly reduce such a learn-
software platform for wireless sensor networks application
                                                                 ing curve. This philosophy is the operating system equiva-
development. Aiming to be an easy-to-use platform, LiteOS
                                                                 lent of network directions taken by companies such as Arch
offers a number of features that are not available in existing
                                                                 Rock [1] (that superimposes a familiar IP space on mote
sensor network operating systems, including: (1) a hierar-
                                                                 platforms to reduce the learning curve of network program-
chical file system and a wireless shell for user interaction
                                                                 ming and management).
using UNIX-like commands; (2) kernel support for dynamic
loading and native execution of multithreaded applications;         The rapid advances of sensor networks in the past few
and (3) online debugging, dynamic memory, and file system         years created many exciting systems and applications. Op-
assisted communication stacks. LiteOS also supports soft-        erating systems such as TinyOS [16], Contiki [9], SOS [15],
ware updates through a separation between the kernel and         Mantis [5], and t-Kernel [14] provided software platforms.
user applications, which are bridged through a suite of sys-     Middleware systems such as TinyDB [21] and Enviro-
tem calls. Besides the features that have been implemented,      Track [4] made fast development of specialized applica-
we also describe our perspective of LiteOS as an enabling        tions feasible. Deployed applications ranged from global
platform. We evaluate the platform experimentally by mea-        climate monitoring to animal tracking [18], promising un-
suring the performance of common tasks using this oper-          precedented sampling of the physical world. Widespread
ating system, and demonstrate its programmability through        adoption and commercialization of sensor networks is the
more than twenty example applications.                           next logical step.
                                                                    The most obvious challenge in sensor network devel-
                                                                 opment has been to fit within extremely constrained plat-
1   Introduction                                                 form resources. Previous work, such as TinyOS, there-
   This paper introduces a UNIX-like operating system,           fore focused on reducing overhead and increasing robust-
called LiteOS, that fits on memory-constrained motes such         ness. Since initial users were researchers, compatibility
as MicaZ. This operating system maps a sensor network            with common embedded computing environments was not
into a UNIX-like file system. It supports C programming           a major concern. Moving forward, to decrease the bar-
natively, and allows online debugging to locate application      rier to widespread adoption and commercialization, lever-
bugs. We believe that such an operating system could po-         aging familiar abstractions is advisable. One approach is
tentially expand the circle of sensor network application        to build user-friendly applications and GUIs such as Sen-
developers by providing a familiar programming environ-          sorMap [25] and MoteView [7]. In this paper, we explore
ment. While TinyOS and its extensions have significantly          a complementary solution that targets the operating system
improved programmability of mote-class embedded devices          and programming environment.
via a robust, modular environment, NesC and the event-             We build a familiar software platform by leveraging the
likely existing knowledge that common system program-
mers (outside the current sensor network community) al-
ready have: Unix, threads, and C. Since our primary goal is
to increase adoption, we also optimize LiteOS for efficiency
and robustness.
    LiteOS differs from both current sensor network oper-
ating systems and more conventional embedded operating
systems. Compared to the former category, such as TinyOS,
LiteOS provides a more familiar environment to the user. Its
features are either not available in existing sensor network
operating systems, such as the shell and the hierarchical file
system, or are only partially supported. Compared to the
latter category (conventional embedded operating systems),              Figure 1. LiteOS Operating System Architec-
such as VxWorks [30], eCos [2], embedded Linux, and                     ture
Windows CE, LiteOS has a much smaller code footprint,
running on platforms such as MicaZ, with a 8MHz CPU,
128K bytes of program flash, and 4K bytes of RAM. Em-                Section 5 discusses the potential of this platform. Section 6
bedded operating systems, such as VxWorks, require more             concludes this paper.
computation power (e.g., ARM-based or XScale-based pro-
cessors) and more RAM (at least tens of KBytes), and thus           2     The LiteOS Operating System
cannot be easily ported to MicaZ-class hardware platforms
(such as MicaZ, Tmote, and Telos).                                     In this section, we present the LiteOS operating system.
                                                                    We first present a system overview and design choices, then
    A possible counter-argument to our investment in a
                                                                    we describe its three subsystems. We include evaluation
small-footprint UNIX-like operating system is that, in the
                                                                    results in these subsections to increase readability.
near future, Moore’s law will make it possible for conven-
tional Linux and embedded operating systems to run on               2.1    Architectural Overview
motes. For example, the recent iMote2 [6] platform by
CrossBow features an XScale processor that supports em-                 Figure 1 shows the overall architecture of the LiteOS op-
bedded Linux. Sun and Intel also demonstrated more pow-             erating system, partitioned into three subsystems: LiteShell,
erful sensor network hardware platforms [3, 24]. While it is        LiteFS, and the kernel. Implemented on a base station, the
true that more resources will be available within the current       LiteShell subsystem interacts with sensor nodes only when
mote form factor, Moore’s law can also be harvested by de-          a user is present. Therefore, LiteShell and LiteFS are con-
creasing the form factor while keeping resources constant.          nected with a dashed line in this figure.
For example, the current MicaZ form factor is far from ade-             LiteOS is designed to support single-node functionality.
quate for wearable computing applications. Wearable body            It provides a wireless node mounting mechanism (to use a
networks can have a significant future impact on health-             UNIX term) through a file system called LiteFS. Much like
care, leisure, and social applications if sensor nodes could        connecting a USB drive, a LiteOS node mounts itself wire-
be made small enough to be unobtrusively embedded in at-            lessly to the root filesystem of a nearby base station. More-
tire and personal effects. These applications will drive the        over, analogously to connecting a USB device (which im-
need for small-footprint operating systems and middleware           plies that the device has to be less than a USB-cable-length
as computation migrates to nodes that are smaller, cheaper,         away), the wireless mount works only for devices within
and more power-efficient. This paper serves as a proof of            wireless range. The mount mechanism comes handy, for
concept by pushing the envelope within the constraints of a         example, in the lab, when a developer might want to inter-
current device; namely, the MicaZ motes.                            act temporarily with a set of nodes on a table-top before
    We have implemented LiteOS on the MicaZ platform.               deployment. While not part of the current version, it is not
The LiteOS software is available for download at the web-           conceptually difficult to extend this mechanism to a “remote
site http://www.liteos.net, including its manual, program-          mount service” to allow a network mount. Ideally, a net-
ming guide, application notes, and source code.                     work mount would allow mounting a device as long as a
    The rest of this paper is organized as follows. Section 2       network path existed either via the Internet or via multi-hop
introduces the LiteOS operating system and describes its            wireless communication through the sensor network.
design and implementation. Section 3 introduces its pro-                Once mounted, a LiteOS node looks like a file directory
gramming environment and application examples. Sec-                 from the base station. A sensor network, therefore, maps
tion 4 outlines more features that LiteOS currently supports.       into a higher level directory composed of node-mapped di-


                                                                2
                                                                              enforces a simple multilevel access control scheme. All
                Table 1. Shell Commands                                       users are classified into three levels, from 0 to 2, and 2 is
    Command List
    File Commands          ls, cd, cp, rm, mkdir, touch, pwd, du, chmod       the highest level. Each level is represented by three bits,
    Process Commands       ps, kill, exec
                           debug, list, print, set
                                                                              stored on sensor nodes. For instance, the usrdir directory
    Debugging Commands
                           breakpoint, continue, snapshot, restore            can be read or written by users with levels 2 and 3.
    Environment Commands   history, who, man, echo
    Device Commands        ./DEVICENAME
                                                                                  Once sensor nodes are mounted, a user uses the above
                                                                              commands to navigate the different directories (nodes) as if
                                                                              they are local. Some common tasks can be greatly simpli-
rectories. The shell, called LiteShell, supports UNIX com-
                                                                              fied. For example, by using the cp command, a user can
mands, such as copy, executed on such directories. The ex-
                                                                              either copy a file from the base to a node to achieve wire-
ternal presentation of LiteShell is versatile. While our cur-
                                                                              less download, or from a node to the base to retrieve data
rent version resembles closely a UNIX terminal in appear-
                                                                              results. The remaining file operation commands are intu-
ance, it can be wrapped in a graphical user interface (GUI),
                                                                              itive. Since LiteFS supports a hierarchical file system, it
appearing as a “sensor network drive” under Windows or
                                                                              provides mkdir, rm and cd commands.
Linux.
                                                                                  Process Operation Commands: LiteOS has a multi-
   The basic (stripped-down) version of LiteOS is geared
                                                                              threaded kernel to run applications as threads concurrently.
for trusted environments. This choice of default helps re-
                                                                              LiteShell provides three commands to control thread be-
duce system overhead when the trust assumptions are satis-
                                                                              havior: ps, exec, and kill. We illustrate these commands
fied. In more general scenarios, where security concerns are
                                                                              through an application called Blink, which blinks LEDs pe-
relevant, an authentication mechanism is needed between
                                                                              riodically. Suppose that this application has been compiled
the base station and mounted motes. Low-cost authentica-
                                                                              into a binary file called Blink.lhex1 , and is located under the
tion mechanisms for sensor networks have been discussed
                                                                              C drive of the user’s laptop. To install it on a node named
in prior literature and are thus not a focus of this paper [26].
                                                                              node101 (that maps to a directory with the same name) in
2.2     LiteShell Subsystem                                                   a sensor network named sn01, the user types the following
                                                                              commands:
    The LiteShell subsystem implements a Unix-style shell
for MicaZ-class sensor nodes. It supports an expandable                          $ pwd
                                                                                    Current directory is /sn01/node101/apps
suite of commands that mostly follow those of Unix, though                       $ cp /c/Blink.lhex Blink.lhex
some commands naturally take new semantics. This is why                               Copy complete
                                                                                 $ exec Blink.lhex
we call LiteOS Unix-like, though we acknowledge that its                              File Blink.ihex successfully started
kernel is significantly different from Unix. Currently, we                        $ ps
                                                                                      Name   State
have implemented the commands listed in Table 2. They                                 Blink Sleep
fall into five categories: file commands, process commands,
debugging commands, environment commands, and device                              As illustrated in this example, we first copy an applica-
commands.                                                                     tion, Blink.lhex, into the /apps directory, so that it is stored
    Note that, different from other subsystems of LiteOS, the                 in the LiteFS file system. We then use the exec command to
shell is implemented entirely on PC. It is a front-end that                   start this application. The implementation of exec is as fol-
interacts with the user. Such an asymmetric design choice                     lows. The processor architecture of Atmega128 follows the
allows us to easily extend the shell with other advanced fea-                 Harvard architecture, which provides a separate program
tures, such as authentication and security.                                   space (flash) from its data space (RAM). Only instructions
    File Operation Commands: File commands generally                          that have been programmed into the program space can be
maintain their Unix meanings, e.g., the ls command lists di-                  executed. Hence, LiteOS reprograms part of the flash to run
rectory contents. It supports a -l option to display detailed                 the application.
file information, such as type, size, and protection. To re-                       Once the Blink application is started, the user may view
duce system overhead, LiteOS does not provide any time                        its thread information using the ps command. Finally, the
synchronization service, which is not needed by every ap-                     kill command is used to terminate threads.
plication. Hence, there is no time information listed. A ls -l                    Debugging Commands: We now describe the de-
command returns the following:                                                bugging commands. Eight commands are provided, in-
                                                                              cluding those for setting up the debugging environment
  $ ls -l
      Name    Type         Size      Protection                               (debug), watching and setting variables (list, print, and
      usrfile file         100       rwxrwxrwx                                set), adding/removing breakpoints (breakpoint and con-
      usrdir dir           ---       rwxrwx---
                                                                              tinue), and application checkpoints (snapshot and restore).
   In this example, there are two files in the current direc-                      1 LiteOS uses a revised version of the Intel hex format, called lhex, to

tory (a directory is also a file): usrfile and usrdir. LiteOS                   store binary applications. lhex stands for LiteOS Hex.


                                                                          3
Note that all debugging commands keep information on the
front-end, i.e., the PC side. In fact, there is no debug-
ging state stored on the mote, which means that there is
no limit on the maximum number of variables (or the size
of variables) being watched, or how many breakpoints can
be added. We now briefly explain these commands. De-
tailed documentation of these commands can be found in                        Figure 2. LiteShell Implementation
the LiteOS manual.
    The user first invokes the debug command to initiate the
                                                                           Table 2. Shell Commands Classification
environment. This command takes the source code direc-                         Command List
tory of the application as its parameter. For example, if sup-                 Local Commands     pwd, echo, who, man, history
                                                                                                  cp, rm, mkdir, touch, chmod
plied with the kernel source code location, it allows debug-                   Network Commands
                                                                                                  du, ps, kill, exec, ls
ging the kernel itself. Once invoked, this command parses
the source code as well as the generated assembly to gather
                                                                       ./light 50 100
necessary information, such as memory locations of vari-
ables.                                                                   Implementation of LiteShell: Figure 2 illustrates the
    The remaining commands are intuitive. The command                implementation of LiteShell. Its command processor in-
list displays the current variables and their sizes. Com-            terprets user commands into internal forms, communicates
mands print and set watch and change variable values.                with the sensor network, and replies to the user. To reduce
Commands breakpoint and continue add and remove                      overhead, sensor nodes are stateless. All state information
breakpoints. Once a breakpoint is added, the command ps              regarding user operations, such as the current working di-
tells whether a thread has reached the breakpoint.                   rectory, is maintained by the shell, while the sensor nodes
    We now explain the commands snapshot and restore.                only respond to interpreted commands using a simple ACK-
Snapshot allows adding a checkpoint to an active thread,             based communication model.
by exporting all its memory information, including vari-                 As an additional note, not every command can always be
able values, stack, and program counter, to an external file.         successfully completed. For example, when the user installs
Restore, on the other hand, allows importing such mem-               an application, if the remaining program space and RAM
ory information from a previously generated file, essentially         of a node are not sufficient for a binary to be loaded, the
restoring a thread to a previous state. Combined use of these        node responds with an error message. We build LiteShell to
two commands allow replaying part of an application by               robustly handle such scenarios.
rewinding it, and is particularly useful for tracking unex-              LiteShell Performance Evaluation: We now evaluate
pected bugs.                                                         the response time of LiteShell. In the following experi-
    Environment Commands: The next four commands                     ments, we classify representative shell commands into two
support environment management: history for displaying               categories: those executed locally, and those communicat-
previously used commands, who for showing the current                ing with nodes, as listed in Table 2.
user, man for command references, and echo for display-                  We observed that commands in the first category are
ing strings. The semantics of these commands are similar             typically finished within one millisecond. Therefore, it is
to their Unix counterparts.                                          the second category of commands that affects users’ expe-
    Device Commands: The LiteOS shell provides an easy               rience. We measured the average response time of these
way to interact with the sensors. Every time the file sys-            commands by using a script to execute each command 100
tem is initialized, a directory dev is created, which contains       times, and recorded the average response time of each com-
files that map to actual device drivers. On MicaZ, the dev            mand. The results are shown in Figure 3(a).
directory contains the following files:                                   As measured in this experiment, the average response
  $ls
                                                                     time of these command is typically less than half a second.
  led, light, temp, magnet, accel, radio                             While we can further optimize their performance by fine-
                                                                     tuning the communication protocol, the current response
   In this directory, led refers to the LED device. There are        time is already quite acceptable. For example, our inter-
four sensors, light, temperature, magnetic, and accelerator,         active performance is generally better than common experi-
respectively. Finally, there is the radio device, which sends        ences in Web browsing.
and receives packets. An example of reading 100 data sam-                One special command that deserves further experiments
ples from the light sensor at a frequency of 50 milliseconds         is the cp command, whose response time depends on the
is written as follows, where the first parameter is the fre-          size of the file to be transferred over the air. We experi-
quency and the second parameter is the number of readings.           mented with different file sizes, and list the results in Fig-


                                                                 4
                                                      500
                                                                      Average Response Time
                         Average Response Time (ms)

                                                      450                                                                                                                                            Table 3. LiteFS API List
                                                      400                                                                                                                         API Usage                  API Interface
                                                      350                                                                                                                         Open file                   FILE* fopen(const char *pathname, const char *mode);
                                                                                                                                                                                  Close file                  int fclose(FILE *fp);
                                                      300
                                                                                                                                                                                  Seek file                   int fseek (FILE *fp, int offset, int position);
                                                      250
                                                                                                                                                                                  Test file/directory         int fexist(char *pathname);
                                                      200                                                                                                                         Create directory file       int fcreatedir(char *pathname);
                                                      150                                                                                                                         Delete file/directory       int fdelete(char *pathname);
                                                      100                                                                                                                         Read from file              int fread(FILE *fp, void *buffer, int nBytes);
                                                       50                                                                                                                         Write to file               int fwrite(FILE *fp, void *buffer, int nBytes);
                                                          0
                                                                                                                                                                                  Move file/directory         int fmove(char *source, char *target);
                                                                                                                                                                                  Copy file/directory         int fcopy(char *source, char *target);
                                                                    ls/4   ls/8        rm   mkdir touch                               du      exec       ps      kill
                                                                                                                                                                                  Format file system          void formatSystem();
                                                                                            Command Name                                                                          Change current directory   void fchangedir(char *path);
                                                                                                                                                                                  Get current directory      void fcurrentdir(char *buffer, int size);
        a) Command Response Time (ls/4 means listing a directory with four children nodes;                                                                                        Check EEPROM Usage         int fcheckEEPROM();
                    ls/8 means listing a directory with eight children nodes)                                                                                                     Check Flash Usage          int fcheckFlash();
                                                                                                                                                                                  Search by name             void fsearch(char *addrlist, int *size, char *string);
                                                                                                                               4000                                               Get file/directory info     void finfonode(char *buffer, int addr);
                          100000
                                                                Copy Command Latency                                                       Copy Command Latency
                                  90000                                                                                        3500
                                                                (Base station to Node)                                                     (Node to Base station)
   Copy Command Latency (ms)




                                                                                                   Copy Command Latency (ms)




                                  80000
                                                                                                                               3000
                                  70000

                                  60000
                                                                                                                               2500                                              shelf MicaZ nodes can directly use LiteOS. The APIs of
                                  50000                                                                                        2000                                              LiteFS are listed in Table 3.
                                  40000
                                                                                                                               1500                                                  While most of these APIs resemble those defined in
                                  30000

                                  20000
                                                                                                                               1000                                              “stdio.h” in C, some of them are customized for sensor
                                  10000                                                                                        500                                               networks. For instance, two functions, fcheckEEPROM
                                                      0
                                                              256    512   1K     2K   4K   8K
                                                                                                                                 0                                               and fcheckFlash, are unique in that they return the avail-
                                                                           File Size                                                  256     512   1K    2K    4K      8K
                                                                                                                                                    File Size                    able space of EEPROM and the serial flash, respectively.
                                    b) Copy Command Response Time                                                              c) Copy Command Response Time                     Another feature of LiteFS is that it supports simple search-
                                       (Base station to Sensor node)                                                              (Sensor node to Base station)
                                                                                                                                                                                 by-filename using the fsearch API, where all files whose
                                                                                                                                                                                 names match a query string are returned. These APIs can
   Figure 3. Average Command Response Time                                                                                                                                       be exploited in two ways; either by using shell commands
   of LiteShell                                                                                                                                                                  interactively, or by using application development APIs.
                                                                                                                                                                                     Design Choices: MicaZ nodes have two non-volatile
ure 3(b) and 3(c). As illustrated, the time to receive data                                                                                                                      storage space: EEPROM (4K bytes) and the serial flash
files is much shorter than the time to send data files, par-                                                                                                                       (512K bytes). While EEPROM can be updated at the byte
tially because in the later case, the base station has to deliver                                                                                                                level, the serial flash has to be updated at the page level,
packets first to a node connected through UART, which in                                                                                                                          with each page occupying 264 bytes. They also differ in ac-
turn broadcasts such packets over the radio. Sending pack-                                                                                                                       cess time. For EEPROM, reading one byte takes 1 CPU cy-
ets via UART turns out to be slower, which explains the                                                                                                                          cle (and the CPU halts for 4 cycles after that), while writing
performance differences. One way to solve this problem is                                                                                                                        one byte takes 8848 cycles. For the serial flash, reading and
to connect a CC2420 radio directly to the base station to                                                                                                                        writing are controlled at the page level using two 264-byte
improve performance.                                                                                                                                                             SRAM buffers. Reading a page into this buffer takes less
                                                                                                                                                                                 than 250 microseconds, but writing a page takes 14-20ms.
2.3                                                   LiteFS Subsystem                                                                                                               Given these hardware characteristics, we conclude that
    LiteFS Interfaces: We now describe the LiteFS subsys-                                                                                                                        the serial flash is suitable for sequential data update, while
tem. The interfaces of LiteFS resemble Unix closely, pro-                                                                                                                        EEPROM is more appropriate for data updates at a smaller
viding support for both file and directory operations. LiteFS                                                                                                                     granularity. We use EEPROM to keep LiteFS directory in-
is not the first effort to provide a file system for sensor net-                                                                                                                   formation. An advantage of this design is that in the fu-
works. Previous well-known efforts include both MicaZ-                                                                                                                           ture, if the 512K flash is replaced by other flash with much
class implementations, such as MatchBox [11] and ELF [8],                                                                                                                        larger capacity, the design of LiteFS can be easily modified
and flash-based systems, where additional flash is plugged                                                                                                                         to support new flash memory by only changing flash-related
to sensor nodes, such as Capsule [22]. We do not adopt                                                                                                                           functions, while reusing its directory operation implemen-
the former because their interfaces do not match our goals:                                                                                                                      tations.
Matchbox and ELF do not support hierarchical file organi-                                                                                                                             Implementation of LiteFS: Figure 4 shows the archi-
zations, only providing basic abstractions for file operations                                                                                                                    tecture of LiteFS, which is partitioned into three parts. It (i)
such as reading and writing. On the other hand, we do not                                                                                                                        uses RAM to keep opened files and the allocation informa-
require external flash attachment so that users with off-the-                                                                                                                     tion of EEPROM and the serial flash, (ii) uses EEPROM to


                                                                                                                                                                             5
    RAM                          EEPROM                   Flash
                                                                                                       35000
                                                                                                               Read Throughput/Sequential
                                                                                                                                                                                                       8000
                                                                                                                                                                                                                  Write Throughput/Sequential
                                                                                                       30000   Read Throughput/Random                                                                  7000
                                                                                                                                                                                                                  Write Throughput/Random
                                                      256 storage blocks




                                                                           Throughput (bytes/second)
                                                                                                                                                                                                       6000
                      65 control blocks




                                                                                                                                                                           Throughput (bytes/second)
                                                                                                       25000

   File Handle                            F                 2K                                         20000
                                                                                                                                                                                                       5000

      (x 8)                           D                                                                                                                                                                4000
                                                                                                       15000
                                                                                                                                                                                                       3000

    EEPROM
                                          F                 2K                                         10000
                                                                                                                                                                                                       2000

    Bit Vector
                     Root             D                                                                5000
                                                                                                                                                                                                       1000

                                          F                 2K                                            0                                                                                              0
                                                                                                               1       2        4           8     16       32   64   128
       Flash                          D                                                                                               Block Size (Bytes)
                                                                                                                                                                                                              1        2       4        8       16
                                                                                                                                                                                                                                    Block Size (Bytes)
                                                                                                                                                                                                                                                         32   64   128

                                                                                                                                    (a) Read Throughput of LiteFS                                                             (b) Write Throughput of LiteFS
    Bit Vector                            F                2K
                                                                                                                                    Figure 5. LiteFS Throughput

                 Figure 4. LiteFS Architecture
                                                                           one file with 128K bytes, and experimented with different
                                                                           block sizes. LiteFS allows modifying the middle of a file
keep hierarchical directory information, and (iii) uses the                with the help of the fseek API. Therefore, we performed
serial flash to store files. Just like Unix, files in LiteFS                  both sequential and random reads and writes.
represent different entities, such as data, application bina-                 We observe a reading throughput up to 30 KBytes/s,
ries, and device drivers. A variety of device driver files, in-             much higher than the writing throughput. Another obser-
cluding radio, sensor, and LED, are supported. Their read-                 vation is that when the block size is small, the random
/write operations are mapped to real hardware operations,                  writing throughput degrades exponentially. The reason is
e.g., writing a message to the radio file (either through the               that it is very likely for a page-erase operation to occur
shell by a user or through a system call by an application)                for every writing operation, because the file pointer has
maps to broadcasting this message.                                         been modified to a random position. This is a special type
   In RAM, LiteFS has room for eight (flexible) file han-                    of thrashing, where the cache of the serial flash (264-byte
dles, with each handle occupying eight bytes. Hence, at                    SRAM) experiences excessive misses. Because of this phe-
most eight files can be opened simultaneously. LiteFS uses                  nomenon, the random throughput of LiteFS is lower, com-
two bit vectors to keep track of EEPROM/flash allocation,                   pared to throughput results reported in the ELF file sys-
one with 8 bytes for EEPROM, the other with 32 bytes for                   tem [8], which followed a different setting to test random
the serial flash. A total of 104 bytes of RAM are used to                   throughput, where the file pointer was modified only once
support these bit vectors.                                                 and no thrashing occurred.
   In EEPROM, each file is represented as a 32-byte con-                    2.4                                     LiteOS Kernel Subsystem
trol block. LiteFS currently uses 2080 bytes (flexible) of
the 4096 bytes available in EEPROM to store hierarchi-                         Threads and Events: Threads provide basic parallelism
cal directories, while the remaining EEPROM is available                   in modern computers. In sensor networks, there are de-
for other needs. These 2080 bytes are partitioned into 65                  sign tradeoffs between using threads and events. Both ap-
blocks. The first block is the root block, which is initialized             proaches have been implemented in previous research ef-
every time the file system is formatted. The other 64 blocks                forts. TinyOS, SOS, and Contiki 2 are representatives of us-
are left for application needs.                                            ing events, while Mantis and TinyThreads choose threads.
   There are four types of control blocks, file, directory, bi-                 The kernel subsystem of LiteOS takes the thread ap-
nary application, and device driver. We follow three design                proach. We implement two different scheduling policies:
choices in these data structures. First, the maximal length                priority-based scheduling, where the thread with the highest
of a file name is 12 bytes. Therefore, the Eight Dot Three                  priority always gets dispatched, and round-robin schedul-
naming system is supported. Second, a single control block                 ing, where each thread gets a slice of CPU, whose length
addresses at most ten flash pages. Each page holds 2K bytes                 is decided by its priority. By default, eight threads are sup-
of data (or 8 physical flash pages). If a file occupies more                 ported. Unlike TinyThread, which implements cooperative
than 20K bytes, LiteFS allocates another control block for                 scheduling, the LiteOS kernel takes back the CPU every
this file, and stores the address of the new block in the next              0.1 seconds. Of course, the correct execution of this de-
field of the old one. Third, all control blocks reside in EEP-              sign choice relies on an assumption that user threads are not
ROM rather than in RAM.                                                    malicious, and will not disable interrupts to enter an infinite
   LiteFS Performance: Due to space limitations, we fo-                    loop.
cus on throughput performance of LiteFS, as shown in Fig-                      In response to user commands, the kernel allows dy-
ure 5. In this experiment, we wrote a simple application that                   2 Contiki supports a special type of lightweight threads called pro-
repeatedly called the fread and fwrite APIs, and measured                  tothreads [10], which are different from conventional threads. Hence, we
the time to complete I/O operations. By default, we used                   still consider Contiki as event-based.


                                                                      6
               Program Space                           LiteOS Kernel          Process 1              Process 2
               Allocation                              Memory Map             Memory Map             Memory Map            out virtual memory include TinyOS (using XNP), SOS, and
    $0000
              Program Memory                          Data Memory            Data Memory            Data Memory            Contiki. In XNP, a boot loader provides loading service
                                     $0000-$001F
              Interrupt Vectors                        32 Registers           32 Registers           32 Registers
                                     $0020-$005F                                                                           by reprogramming part of the flash and jumping to its en-
                                                      64 I/O Registers       64 I/O Registers       64 I/O Registers
                                     $0060-$00FF
                                                      160 Ext I/O Reg.       160 Ext I/O Reg.       160 Ext I/O Reg.       try point to dispatch it. While this approach is practical,
                                           $0100
                LiteOS Kernel
                                                      Memory Sections                                                      it cannot load more than one application, due to potential
                                                      for LiteOS Kernel
                                                      (.data .bss .noinit)                                                 conflicts in memory accesses. SOS, on the other hand, pro-
                                                                             Memory Sections                               poses to use modules. Its key idea is that if modules only
                                                                             for Process 1
                                                                             (.data .bss .noinit)                          use relative addresses rather than absolute addresses, they
                Process 1 Binary                                             Stack space for
                                                                             Thread 1A                                     are relocatable. However, compiling such relocatable code
                                                                             Stack space for
                                                                             Thread 1B
                                                                                                                           has size limitations: the compiler for the AVR platform (Mi-
                Process 2 Binary                                             Stack space for                               caZ) only supports binaries up to 4K bytes. Such limitations
                                                                             Process 1
                                                                                                    Memory Sections        cause scalability problems for large applications. Contiki
                                                                                                    for Process 2
                                                                                                    (.data .bss .noinit)   takes yet another approach, where it parses ELF files to
                                                                                                    Stack space for
                                                                                                    Thread 2A              patch all unsolved symbolic links, and to perform binary re-
                                                                                                    Stack space for
                                                                                                    Thread 2B
                                                                                                                           location with the help of a symbol table in its kernel. How-
                                                                                                    Stack space for        ever, it remains to be seen whether this approach can be
                                                                                                    Process 2
                                                                                                                           easily ported to multi-threading environments.
              Self-programming
              support located in                      Stack space for        Stack space for        Stack space for            Goals: Our primary goal is to support dynamic loading
              the boot-loader                         LiteOS Kernel          LiteOS Kernel          LiteOS Kernel
              (part of LiteOS      $10FF (4K bytes)
                                                                                                                           and native execution of multiple multithreaded applications
              kernel)
    $FFFF
(64K words)
                                                                                                                           with small overhead. Our second goal is to achieve software
                                                                                                                           compatibility. The LiteOS kernel is likely to evolve, pro-
              Figure 6. LiteOS Memory Organization                                                                         viding new functionalities and performance optimizations.
                                                                                                                           Just like we can still run old applications on new versions of
                                                                                                                           mainstream PC operating systems, we do not want recom-
namic loading of user threads. To facilitate this, it maintains
                                                                                                                           pilations of old user applications with every small revision
a map of system resource allocation, including both its pro-
                                                                                                                           to the LiteOS kernel.
gram flash and RAM. To dispatch a thread, it copies thread
information into a free control block. When a thread termi-                                                                    Approach Overview: LiteOS provides two approaches
nates, it frees allocated resources for this thread, by marking                                                            for dynamic loading of user applications. These approaches
both the occupied program flash and RAM as available. It                                                                    allow multiple threads to be concurrently executed without
also forcefully closes previously opened file pointers by this                                                              memory access conflict. Figure 6 illustrates such an ex-
thread, if there are any, in case this thread forgets.                                                                     ample, where six threads (besides the kernel) are executed.
   While resource management in LiteOS is relatively sim-                                                                  Note that the memory sections of different threads do not
ple to implement, there are two major challenges that di-                                                                  overlap, and threads are executed natively.
rectly affect user experiences using LiteOS threads. The                                                                       In the first loading approach, we assume that the source
first is to support dynamic loading and un-loading of user                                                                  code is available. Every time the user needs to load the
applications, and their native execution, with a very low                                                                  binary to a different location, the source code is re-compiled
overhead. The second is to provide a clear boundary be-                                                                    with different memory settings. This approach introduces
tween the kernel and user applications, and to maintain                                                                    no extra overhead, and generates smaller binary images.
compatibility during system updates. These are described                                                                       In the second approach, we do not assume the source
next together with related work.                                                                                           code is available for the user. This approach remotely
   Previous work: Dynamic loading is taken for granted in                                                                  echoes the differential patching idea [28, 17] in application
almost every modern operating system. Conventionally, dy-                                                                  distributions over networks. In that idea, to update an ap-
namic loading is closely related to virtual memory. While                                                                  plication, the user compiles a list of differences between
virtual memory support in MicaZ-class sensor networks has                                                                  the old and new versions of the application, and only sends
been implemented [20, 14], we observe that such efforts                                                                    such differences as an update, so that communication cost
unanimously slow down program execution, because of the                                                                    can be reduced. However, this idea does not directly work
lack of hardware support for page tables and the limited                                                                   in LiteOS, because it still requires the availability of source
computation power of the CPU. While the direction of sup-                                                                  code.
porting dynamic loading with the help of virtual memory                                                                        Different from differential patching, we directly encode
may still be possible, several previous efforts have tried al-                                                             relocation information into application binaries, by fitting
ternative approaches to implement dynamic loading in sen-                                                                  differential patches with mathematical models, and dis-
sor networks.                                                                                                              tributing these models together with binary images. With
   Representative efforts to provide dynamic loading with-                                                                 such models, the kernel is able to rewrite part of the binary


                                                                                                                     7
image for relocation.                                                                   Mathematical Models of Address Translation: We use
    Our development of mathematical models for differen-                            an example to illustrate how we model address translation,
tial patches are driven by practical observations. The mod-                         where we sample the light sensor for 100 times, at a fre-
els we construct, which are linear, are based on analyzing                          quency of once per second, and write readings into a local
binary images generated by the specific compiling envi-                              file in LiteFS, so that the user may extract such data using
ronment of GCC, which supports whole-program optimiza-                              LiteShell. Using the GCC compiler, this application com-
tions. By being customized, these models are easier to be                           piles to 358 instructions consuming 790 bytes of binary.
implemented on MicaZ motes with very low overhead. For                              We compiled it with three M settings, 0x500, 0x504, and
compilers other than GCC, or older versions of GCC, the                             0x600, and compared the compiled code in the assembly
model details, such as the types of instructions that need to                       level. We found a total of 12 different instructions out of
be translated, are likely to change. However, generalizing                          these 358 instructions. Semantically, they are grouped into
the models to support other compiling environments is out                           three difference clusters, shown in Figure 7.
of the scope of this paper.                                                             We list a total of 14 instructions, including two instruc-
    Observations on Differential Patches of Binary Im-                              tions ( 5 and 10 ) that are not differential, but are useful for
age: We start presenting the details of our approach by                             our following explanations. Our primary observation over
observations on binary image instructions. When the ker-                            these differential patterns is that the values taken by imme-
nel loads a binary to different memory locations, the poten-                        diate operands in each differential instruction are closely
tial factors that affect the image can be written as a vector                       related to the values of M. For instance, the immediate
(S, M, T), where S is the start address of the binary exe-                          operands in instructions 3 and 2 collectively represent a
cutable in the program flash, M the start address of allocated                       16-bit number with a value of M, while instruction 1 takes
memory, and T the stack top. All three parameters can be                            the value of M shifted eight bits in the right direction.
set in GCC and other common compilers. Observe that the                                 Before illustrating what we can do, we start with what
difference between T and M is the actual memory space                               we cannot do. Generally, it is almost impossible for us to
allocated for this executable, whose minimum requirement                            predict what code the compiler will produce, or the seman-
can be statically decided using a technique called stack anal-                      tic relationships between instructions. Such kind of implicit
ysis (as long as the application has no recursive functions).                       relationships only emerge with application specific analy-
Several such tools are available [27, 23]. Therefore, we as-                        sis, but are far beyond the capability of mathematical mod-
sume that the stack top has been statically decided.                                eling. Because of these difficulties, we take an application
                                                                                    independent approach. We analyze the differences between
    Because (S, M, T) is volatile, we have to find a way to
                                                                                    compiled images under different memory settings, generate
encode its impact. Experimentally, we observe that as the
                                                                                    linear models to fit such differences, and test the models
vector changes, it only affects the immediate operands of
                                                                                    with training data. The models are based on the observation
a few instructions. More specifically, of the 114 instruc-
                                                                                    that for differential instructions, their values under different
tions provided by the Atmega128 processor (on MicaZ),
                                                                                    (S, M, T) vectors demonstrate a set of linear displacements.
under the GCC compiling environment, only the follow-
                                                                                    This follows directly from the format of machine code for
ing six instructions are affected: LDI, LDS, STS, JMP,
                                                                                    various addressing modes. In the previous example, except
CALL, CPI. The detailed meanings of these instructions
                                                                                    non-differential instructions 5 and 10 , f can be written as
can be found in the datasheet of Atmega128. We call them
                                                                                    follows:
differential instructions.
                                                                                                    V = ((aM + b) >> L) << R                     (1)

    Section     Address         = 0x500           = 0x504            = 0x600           In this equation, a, b, L and R are undecided variables,
    _do_copy    ① 19098   ldi r17, 0x05     ldi r17, 0x05     ldi r17, 0x06         >> is the right-shifting operation, and << is the opposite.
    _data       ② 1909a   ldi r26, 0x00     ldi r26, 0x04     ldi r26, 0x00
                ③ 1909c   ldi r27, 0x05     ldi r27, 0x05     ldi r27, 0x06
                                                                                    To solve a, b, L and R, we usually need four different com-
                ④ 190ac   cpi r26, 0x0C     cpi r26, 0x10     cpi r26, 0x0C         piler settings. After solving these variables for the previous
                ⑤ 190ae   cpc r27, r17      cpc r27, r17      cpc r27, r17
                                                                                    example, the f function of 1 is determined as M >> 8
    _do_clear   ⑥ 190b2   ldi r17, 0x05     ldi r17, 0x05     ldi r17, 0x06
    _bss        ⑦ 190b4   ldi r26, 0x0C     ldi r26, 0x10     ldi r26, 0x0C         (a = 1, b = 0, L = 8, and R = 0).
                ⑧ 190b6   ldi r27, 0x05     ldi r27, 0x05     ldi r27, 0x06            While our discussions so far are only about M, the same
                ⑨ 190bc   cpi r26, 0x14     cpi r26, 0x18     cpi r26, 0x14
                ⑩ 190be   cpc r27, r17      cpc r27, r17      cpc r27, r17          approach applies to S and T, though we observe different
    main        ⑪ 190d2   ldi   r22, 0x00   ldi   r22, 0x04   ldi   r22, 0x00       variations of the f expressions. The final form of f is typi-
                ⑫ 190d4   ldi   r23, 0x05   ldi   r23, 0x05   ldi   r23, 0x06
                ⑬ 190d6   ldi   r24, 0x02   ldi   r24, 0x06   ldi   r24, 0x02
                                                                                    cally a superposition of different linear equations for S, M,
                ⑭ 190d8   ldi   r25, 0x05   ldi   r25, 0x05   ldi   r25, 0x06       and T, and is sufficiently simple to be encoded into binary
                                                                                    images. Due to space limitations, we do not elaborate on
                                                                                    S and T displacement models. To ensure that our approach
    Figure 7. Binary Image Difference Example                                       works correctly, we always generate training binary images,


                                                                                8
serving as verifications of the mathematical models.                  12], the view is such that an application is driven by events,
    System Calls and Software Compatibility: To dis-                 which can optionally post long-term tasks to a FIFO sched-
tribute applications using the LiteOS HEX format, one im-            uler. For example, a simple Blink application is driven by
portant problem is software compatibility. To reduce redun-          a timer fire event, whose event handler blinks the LED.
dancy, LiteOS provides system resources, such as LiteFS,             A more complicated application typically needs state ma-
drivers, and thread services for user applications. If the           chines, because TinyOS does not directly support execu-
LiteOS kernel is modified, the addresses of its internal data         tion contexts. For instance, in writing reliable commu-
structures will change. If not handled carefully, such up-           nication stacks, the developer sometimes wants to do the
dated kernels no longer support binaries compiled for older          following: after sending a packet, a node waits for a pe-
versions of LiteOS. While this problem can be detected eas-          riod Ttimeout (after which the previous packet is considered
ily (through version numbers), we are interested in how to           lost), or stop waiting if an acknowledgement is received.
avoid such incompatibilities.                                        In the programming model of TinyOS, such a task is de-
    We introduce lightweight system calls to address com-            composed into two events: a timeout event, and a radio re-
patibility. Because the MicaZ CPU does not support soft              ceive event. Because the order of these two events is not
interrupts or traps, our implementation is based on revised          predictable, a developer introduces two states in the state
callgates, a special type of function pointers. These call-          machine, and handles their possible transitions. If the num-
gates are the only access points through which user applica-         ber of states grows large, handling state transitions usually
tions access system resources. Therefore, they implement             becomes complicated. Such difficulties motivated several
a strict separation between the kernel and user applications.        research efforts to simplify application development, such
As long as the system calls remain supported by future ver-          as the OSM model [19] and Abstract Regions [29].
sions of LiteOS, user binaries do not need to be recompiled.             In contrast to the event based programming model
    At the system kernel side, each system call gate takes           adopted by TinyOS, LiteOS introduces threads to maintain
4 bytes, with 1024 bytes of program space allocated for              execution contexts. For example, in the previous “Hello,
at most 256 system calls. Compared to directly invoking              World” example, every time the function Radio send is
kernel functions, each system call adds 5 instructions (10           called, the thread suspends until the radio operation fin-
CPU cycles), a sufficiently low overhead to be supported on           ishes. Threads, however, do not completely eliminate the
MicaZ. At the user side, interactions with system calls are          use of events. Observe that there are actually two types of
provided as libraries. The details of call gates are therefore       events: those triggered by user applications, and those trig-
hidden from user applications.                                       gered by external factors. For instance, a sendDone event
                                                                     always follows a packet sending operation, and is therefore
3     The Programming Environment                                    application-triggered. A radio receive event, however, is
   In this section, we briefly describe the programming en-           triggered by external events, and is not predictable. Unlike
vironment of LiteOS. This section is organized as follows.           previous work, which does not differentiate between these
We first present a concrete programming example, followed             two types of events, LiteOS treats them separately. Gener-
by the programming model. Finally, we present perfor-                ally, the first type of events is implicitly handled by using
mance comparisons using example applications.                        threads, where events like sendDone are no longer visible.
                                                                     It is the second type of events that deserves special atten-
3.1     The “Hello, World” Example                                   tion.
   As a concrete example of how to program in LiteOS, we                 We illustrate how the second type of events is handled
use the classical “Hello, World” example. The source code            using the radio receive event as an example. LiteOS pro-
of this application is shown as follows. Lines starting with         vides two solutions to handle this event. The first is to
#include are not listed.                                             create a new thread using the createThread system call,
                                                                     which blocks until the message arrives3 . Return to the pre-
    int main()
    {                                                                vious reliable communication example. Suppose that the
    while (1) {                                                      application thread creates a child thread to listen to possible
        radioSend_string("Hello, world!\n");
        greenToggle();                                               acknowledgements. If such a message is received before
        sleepThread(100); //Sleep for 100 milliseconds               T timeout, the child thread wakes up its parent thread using
    }
        return 0;                                                    the wakeupThread method. Otherwise, if its parent thread
    }                                                                wakes up without receiving an acknowledgement, this child
                                                                     thread is terminated by its parent thread using the termi-
3.2     Programming Model                                            nateThread method.
   We use programming model to refer to a developer’s                    3 LiteOS classifies radio messages using ports, where the kernel deliv-

view of a programming environment. In TinyOS/NesC [13,               ers messages to threads listening on matching ports.


                                                                 9
    Application               Functionality                                               wakeup = TRUE;
    Simple applications       Blink, BlinkTask, CntToLeds, CntToLedsAndRfm,               wakeupThread(currentThread);
    (demonstrations of        CntToRfm, CountRadio , GlowLeds, GlowRadio,                 _atomic_end();
    simple APIs, total: 11)   ReverseUSART, RfmToLeds, SenseToLeds                    }
    Pong                      Two nodes exchange messages
    Sense                     Sense the environment and report                         Generally, different from the TinyOS model, the LiteOS
    SenseTask                 Sense the environment and report, using tasks        programming model comprises threads and callback func-
    GenericBase               Base station to receive messages                     tions. Threads allow maintaining execution contexts, while
    Oscilloscope              Displaysdata on PC
                                                                                   callback functions provide an inexpensive way to handle ex-
    OscilloscopeRF            Displaysdata on PC, through the radio
                                                                                   ternal events. A potential risk of this model is race con-
    SenseLightToLog           Read sensors and store the value in flash
    SenseToRfm                Read sensors and report through the radio
                                                                                   ditions. Due to space limitations, we only give a sketchy
    SimpleCmd                 Basic command interpretation                         description on how we avoid this problem. Observe that
    Surge                     Basic multi-hop routing program                      in LiteOS, race conditions only exist between variables in
                                                                                   user applications, because the variables in the kernel are not
            Figure 8. Benchmark Applications                                       directly accessible by user applications. Hence, a program-
                                                                                   mer must ensure that every variable that is accessed asyn-
                                                                                   chronously by multiple threads is protected by atomic oper-
   While this thread-based approach is usually sufficient for
                                                                                   ations. Otherwise, if a thread that is modifying this variable
handling the second type of events, it introduces the over-
                                                                                   gets preempted, and another thread modifies this variable
head of creating and terminating threads. This is typically
                                                                                   again, race conditions occur. One improvement is to auto-
not a problem because it wastes a few hundred CPU cycles,
                                                                                   matically detect potential race conditions in the compiler, as
less than 0.1ms. For computationally intensive applications,
                                                                                   the NesC compiler does.
however, user applications want to reduce overhead. LiteOS
adopts another primitive for this purpose: callback func-                          3.3       Performance Evaluation
tions.
                                                                                       We have implemented a suite of libraries for user pro-
   A callback function registers to a second type event,
                                                                                   gramming in LiteOS. To evaluate its performance, we select
which could range from radio events to detections of targets,
                                                                                   21 benchmark applications shown in Figure 8. To compare
and is invoked when such an event occurs. For instance, the
                                                                                   LiteOS and TinyOS, our choices of benchmarks are limited
function registerRadioEvent tells that a message has been
                                                                                   to those available in standard TinyOS distributions (version
received. Its prototype is defined as follows:
                                                                                   1.1.x).
    void registerRadioEvent(uint8_t port, uint8_t *msg,                                We used three metrics in the following experiments:
    uint8_t length, void (*callback)(void));
                                                                                   code length as measured in lines of code after removing
                                                                                   all comments and blank lines, compiled number of bytes,
   This interface requires the user thread to provide a buffer
                                                                                   where we use default settings for both LiteOS and TinyOS,
space for receiving incoming messages. After the kernel
                                                                                   and static RAM consumption of user applications 4 . We
copies the message to this buffer, it invokes the callback
                                                                                   didn’t include the LiteOS kernel in the comparison because
function. Based on this mechanism, the previous reliable
                                                                                   the functionalities it provides, such as its support for the
communication example can be implemented as follows:
                                                                                   shell and file system, are not available in the TinyOS ver-
   Part I: Application
                                                                                   sion of benchmark applications. To make fair comparisons,
  //Main thread, assuming we want to listen at MYPORT, and                         we only included user side applications, where TinyOS sys-
  //allocates a buffer to receive incoming packets
   bool wakeup = FALSE;                                                            tem modules are not included for the analysis (we used the
   uint8_t currentThread;                                                          module memory usage script in the contrib directory of
  //Set up the current thread number
   currentThread = getCurrentThreadIndex();                                        TinyOS to extract such modules).
  //Register the event                                                                 When writing benchmark applications under LiteOS,
   registerRadioEvent(MYPORT, msg, length, packetReceived);
  //Sleep                                                                          we implemented exactly the same functionalities as their
  sleepThread(T_timeout);                                                          TinyOS counterparts that were measured. One excep-
  //Has waken up and remove the register function
   unregisterRadioEvent(MYPORT);                                                   tion is the Surge application, where we only implemented
  //Am I waken up by a packet?                                                     the multi-hop spanning tree and data retrieval, while the
  //Yes, by a packet
   if (wakeup == TRUE) {...}                                                       message queuing and command broadcast functionality in
  //No, no acknowledgement yet, wake up due to timeout                             the TinyOS version of Surge have not been implemented.
   else {...}
                                                                                   Therefore, we compared the LiteOS version to a partial
   Part II: Callback function                                                         4 We  don’t compare stack usage because the stack consumption of
  void packetReceived()                                                            TinyOS is attributed to both system services and user applications. It is
  {                                                                                hard to measure stack consumption for user applications alone in TinyOS
    _atomic_start();                                                               applications.


                                                                              10
                                                  3

                                                                                                        Number of Threads (LiteOS)
                                                                                                                                              LiteOS images include system calls, their code sizes are
                             Number of Threads




                                                  2                                                                                           comparable to TinyOS, indicating that the LiteOS program-
                                                  1
                                                                                                                                              ming model does not introduce too much overhead.
                                                                                                                                                 Figure 9(d) shows the static memory usage comparison.
                                                  0
                                                                                                                                              Observe that several applications consume more memory in
                                                                                                                                              LiteOS than in TinyOS, because their LiteOS versions are
                                                                              Number of Threads
                                                                                                                                              multithreaded. In fact, there is a strong correlation between
                                                             a) Number of Threads for LiteOS Applications
                                                 300
                                                                                                                                              the number of threads and the consumed RAM, by com-
                                                                                                              Source code LOC (LiteOS)

                                                 250                                                          Source code LOC (TinyOS)
                                                                                                                                              paring figures (a) and (d), because extra threads consume
                                                                                                                                              additional RAM for their own stacks. While it is possible
                     Source Code Lines of Code




                                                 200


                                                 150
                                                                                                                                              to reduce the number of threads for some applications us-
                                                 100
                                                                                                                                              ing callback functions, we choose not to optimize this way
                                                      50
                                                                                                                                              because we want to show that, based on the benchmarks,
                                                      0
                                                                                                                                              the worst case RAM consumption of multithreaded applica-
                                                                                                                                              tions is still acceptable: even the GenericBase application
                                                                                Application Name                                              with three threads consumes fewer than 200 bytes of RAM.
                                                                  b) Source Code Length Comparison
                                           1800
                                                                                                       Compiled Code Size (LiteOS)
                                                                                                                                              4     Other Features of LiteOS
                                           1600                                                        Compiled Code Size (TinyOS)
                                           1400
                                                                                                                                                 In this section, we describe several additional features
Compiled Code Size (bytes)




                                           1200                                                                                               of the LiteOS platform. Due to space, we describe them
                                           1000
                                                                                                                                              briefly. Detailed documentation of these features is avail-
                                                 800

                                                 600                                                                                          able at www.liteos.net.
                                                 400

                                                 200
                                                                                                                                              4.1    File Assisted Communication Stacks
                                                      0
                                                                                                                                                 The design of flexible and powerful communication
                                                                                Application Name                                              stacks has been a critical challenge to sensor network ap-
                                                                  c) Compiled Code Size Comparison                                            plications. In LiteOS, we treat communication stacks, such
                                                 200
                                                                                                   Static Memory Consumption (LiteOS)
                                                                                                                                              as routing and MAC protocols, as threads. Hence, differ-
                                                 180
                                                                                                   Static Memory Consumption (TinyOS)
                                                                                                                                              ent communication protocols can be exchanged easily, and
              Memory Consumption (bytes)




                                                 160
                                                 140
                                                 120
                                                                                                                                              dynamically loaded just like any user application.
                                                 100                                                                                             To use a protocol, an application organizes the header of
                                                 80
                                                 60
                                                                                                                                              packets in such a way that the communication protocol can
                                                 40                                                                                           correctly parse. Packets are then sent to the port which the
                                                 20
                                                      0                                                                                       protocol is listening on. For example, a flooding protocol
                                                                                                                                              uses a different listening port compared to a multi-hop rout-
                                                                              Application Name                                                ing protocol. In this following example, our multi-hop rout-
                                                              d) Static Memory Consumption Comparison
                                                                                                                                              ing protocol listens on port 10, and the application sends a
                                                           Figure 9. Benchmark Evaluation                                                     packet of 16 bytes through this protocol using the following
                                                                                                                                              code sample:
                                                                                                                                                  //10 is the port number, 0 means local node protocol
Surge application in TinyOS for fair comparison. Figure 9                                                                                         //16 is the message length, and msg is the message pointer
                                                                                                                                                   radioSend(10, 0, 16, msg);
shows the comparison results. Figure 9(a) shows the num-
ber of threads for each LiteOS application, while TinyOS                                                                                          Our implementation of this multi-hop protocol (geo-
applications are all single-threaded. Given that LiteOS re-                                                                                   graphic forwarding) maintains a neighbor table of 12 en-
moves event handlers, wiring, and interfaces, it is not sur-                                                                                  tries, and contains around 300 lines of code. Its binary im-
prising that, as shown in 9(b), the source code size for                                                                                      age consumes 1436 bytes of program flash, and 260 bytes
LiteOS applications are typically smaller than their TinyOS                                                                                   of RAM, including stack. Its overhead is so low that it can
counterparts. While such a reduction may not necessarily                                                                                      co-exist with other protocols, such as flooding. The source
means that programming in LiteOS is easier, it is at least                                                                                    code of this protocol is available in LiteOS 0.3.
promising for reducing the development cost of sensor net-
work applications.                                                                                                                            4.2    Dynamic Memory
   Figure 9(c) shows the compiled code size (consump-                                                                                           LiteOS supports dynamic memory at the kernel level.
tion of program flash) comparison. Observe that while the                                                                                      The dynamic memory is provided as library APIs (malloc


                                                                                                                                         11
function and free function) to user applications through sys-         as the title suggests. However, we believe that it is precisely
tem calls. The dynamic memory grows in the opposite di-               its affinity to UNIX that could make LiteOS easier to adopt
rection as the LiteOS stack, and resides completely in the            by mainstream systems programmers. One goal of LiteOS
unused memory between the end of the kernel variables,                is to hopefully offer an easy transition path for those be-
and the start of user application memory blocks. Therefore,           ginning sensor networks programmers who are experienced
the size of dynamic memory can be adjusted after deploy-              in other embedded systems programming, but not proficient
ment according to user applications’ needs.                           with event-based programming, wiring, and state-machine
                                                                      abstractions of program execution. LiteOS and the previous
4.3     Event Logging                                                 sensor network operating systems, such as TinyOS, there-
    Visibility has been considered key challenge for wireless         fore, fill complementary needs. We hope that this diversity
sensor network applications. Deployed on the extremely                brings us one step closer to making sensor network pro-
resource-constrained mote platform, such applications may             gramming attainable to system programmers without steep
fail unexpectedly, or exhibit behavior different from their           learning curves.
intended goals. To help understand why such problems
occur, we design and implement an event trace logger in               6      Conclusions
LiteOS, which allows us to partially reconstruct application
                                                                         In this paper, we presented a software development plat-
behavior after execution, such as which path it took for an IF
                                                                      form called LiteOS, and conducted its performance eval-
statement, its invocation history of the kernel system calls,
                                                                      uation. We also presented performance results of several
and the dynamics of its behavior across nodes.
                                                                      benchmark applications. We are hopeful that the familiar
    Briefly speaking, the event logging service of LiteOS is
                                                                      abstractions exported by LiteOS will make it valuable as a
implemented as follows. We keep an internal buffer (its size
                                                                      new research platform, and appealing to a larger category
decided by the user) to record the most recent application
                                                                      of embedded systems programmers.
events. We only log one application at a time. Therefore,
we only need one byte for most events, up to 256 different            References
types, including all the system calls, certain kernel events
such as context switches and driver invocations, and ap-               [1]   Arch rock corporation. http://www.archrock.com.
plication specific events inserted by the user. Every time              [2]   ecos system. http://ecos.sourceware.org/.
                                                                       [3]   Sun spot project. http://www.sunspotworld.com/.
an event triggers, a corresponding byte is written into the            [4]   T. Abdelazaher et al. Envirotrack: Towards an environmental computing
buffer. When the buffer is full, we write its content into a                 paradigm for distributed sensor networks. In IEEE ICDCS, 2004.
                                                                       [5]   S. Bhatti et al. Mantis os: An embedded multithreaded operating system for
file stored in the external flash. Such recorded traces are                    wireless micro sensor platforms. In ACM/Kluwer Mobile Networks and Appli-
obtained after the deployment and are translated into a rec-                 cations (MONET), Special Issue on Wireless Sensor Networks, 2005.
                                                                       [6]   CrossBow. Imote2 platform. http://www.xbow.com.
ognizable sequence of events. Therefore, the sensor node is            [7]   CrossBow. Moteview software. http://www.xbow.com.
no longer a black box. Instead, we now have valuable in-               [8]   H. Dai, M. Neufeld, and R. Han. Elf: an efficient log-structured flash file system
                                                                             for micro sensor nodes. In ACM SenSys, 2004.
sight on why an application fails, and what we should do to            [9]   A. Dunkels, B. Gronvall, and T. Voigt. Contiki - a lightweight and flexible
correct unexpected software glitches.                                        operating system for tiny networked sensors. In Proceedings of Emnets-I, 2004.
                                                                      [10]   A. Dunkels, O. Schmidt, T. Voigt, and M. Ali. Protothreads: Simplifying event-
                                                                             driven programming of memory-constrained embedded systems. In ACM Sen-
5     Perspective                                                            sys, 2006.
                                                                      [11]   D. Gay. Design of matchbox, the simple filing system for motes. Available at
    In retrospect, several design choices become evident af-                 http://www.tinyos.net/tinyos-1.x/doc/matchbox-design.pdf.
ter finishing a prototype version of LiteOS. One advantage             [12]   D. Gay, P. Levis, and D. Culler. Software design patterns for tinyos. In Pro-
                                                                             ceedings of the ACM LCTES, 2005.
of LiteOS is that it supports interactive use. We believe an          [13]   D. Gay, P. Levis, R. von Behren, M. Welsh, E. Brewer, and D. Culler. The
interactive system (e.g., one that offers an interactive shell               nesC Language: A Holistic Approach to Networked Embedded Systems. In
                                                                             Proceedings of PLDI, 2000.
to users and programmers) leads to improved productivity              [14]   L. Gu and J. A. Stankovic. t-kernel: Providing reliable os support to wireless
at development time. Our experiences using LiteOS con-                       sensor networks. In ACM SenSys, November 2006.
                                                                      [15]   C.-C. Han, R. Kumar, R. Shea, E. Kohler, and M. Srivastava. A dynamic oper-
firm this thesis. How will LiteOS affect the way we interact                  ating system for sensor nodes. In Proceedings of Mobisys, 2005.
with sensor networks? With a graphical shell, it can serve            [16]   J. Hill, R. Szewczyk, A. Woo, S. Hollar, D. Culler, and K. Pister. System
                                                                             architecture directions for network sensors. In Proceedings of ASPLOS-IX,
as a sensor network drive that can be mounted to a PC and                    2000.
controlled over Web browsers. Sensor networks can then                [17]   J. Jeong and D. Culler. Incremental network programming for wireless sensors.
                                                                             In IEEE SECON, 2004.
become just another common peripheral.                                [18]   P. Juang, H. Oki, Y. Wang, M. Martonosi, L. Peh, and D. Rubenstein. Energy-
    Apart from promoting interactive use, there is a concep-                 Efficient Computing for Wildlife Tracking: Design Tradeoffs and Early Expe-
                                                                             riences with ZebraNet. In Proceedings of ASPLOS-X, October 2002.
tual question on the need for LiteOS. In sensor networks, at          [19]                        o
                                                                             O. Kasten and K. R¨ mer. Beyond event handlers: Programming wireless sen-
least five other operating systems have already been imple-                   sors with attributed state machines. In ACM IPSN, 2005.
                                                                      [20]   A. Lachenmann, P. J. Marron, and K. Rothermel. Efficient flash-based vir-
mented. Why do we need yet another one? We acknowl-                          tual memory for sensor networks. In Technical Report 2006/07, Universitat
edge that the design of LiteOS is partially inspired by Unix,                Stuttgart, Faculty of Computer Science, 2006.



                                                                 12
[21] S. R. Madden, M. J. Franklin, J. M. Hellerstein, and W. Hong. The Design of an
     Acquisitional Query Processor for Sensor Networks. In ACM SIGMOD, 2003.
[22] G. Mathur, P. Desnoyers, D. Ganesan, and P. Shenoy. Capsule: An energy-
     optimized object storage system for memory-constrained sensor devices. In
     ACM Sensys, November 2006.
[23] W. P. McCartney and N. Sridhar. Abstractions for safe concurrent programming
     in networked embedded systems. In ACM Sensys, 2006.
[24] L. Nachman, R. Kling, R. Adler, J. Huang, and V. Hummel. The intel mote
     platform: a bluetooth-based sensor network for industrial monitoring. In Pro-
     ceedings of IPSN, 2005.
[25] S. Nath, J. Liu, and F. Zhao. Challenges in building a portal for sensors world-
     wide. In First Workshop on World-Sensor-Web: Mobile Device Centric Sensory
     Networks and Applications (WSW), 2006.
[26] A. Perrig, R. Szewczyk, V. Wen, D. Culler, and D. Tygar. Spins: Security
     protocols for sensor networks. In Proceedings of Mobicom, 2001.
[27] J. Regehr, A. Reid, and K. Webb. Eliminating stack overflow by abstract inter-
     pretation. In Proceedings of EMSOFT, October 2003.
[28] N. Reijers and K. Langendoen. Effcient code distribution in wireless sensor net-
     works. In In Proceedings of the 2nd ACM international conference on Wireless
     sensor networks and applications, 2003.
[29] M. Welsh and G. Mainland. Programming sensor networks using abstract re-
     gions. In Proceedings of NSDI, pages 29–42, 2004.
[30] WindRiver. Vxworks operating system. http://www.windriver.com.




                                                                                        13

								
To top