LiteOS,AUnix-likeOperatingSystemandProgramming.pdf资源-CSDN文库

LiteOS

开源操作小型系统

5星 · 超过95%的资源需积分: 10 164 浏览量 2008-12-06 17:44:31 上传评论 3 收藏 1.02MB PDF 举报

资源推荐

资源详情

资源评论

LiteOS, A Unix-like Operating System and Programming

Environment for Wireless Sensor Networks

Sensys Paper #89

Abstract

This paper presents LiteOS, a UNIX-like, multithreaded

operating system with object-oriented programming support

for wireless sensor networks. Aiming to build an easy-to-use

sensor network software platform, LiteOS offers a number

of features that are not available in existing sensor network

operating systems, including: (1) a built-in hierarchical ﬁle

system and a wireless shell for user interaction using UNIX-

like commands; (2) kernel support for dynamic loading and

native execution of multithreaded applications; and (3) an

object-oriented programming language that uses a subset of

C++ as its syntax with class library support. LiteOS com-

prises an evolvable kernel for application execution and a

compiler for application development, bridged by a suite of

expandable system calls. We evaluate it experimentally by

measuring the performance of common tasks using this op-

erating system, and demonstrate its programmability through

more than twenty application benchmarks.

1 Introduction

This paper introduces the ﬁrst UNIX-like operating sys-

tem, called LiteOS, that ﬁts on memory-constrained motes

such as MicaZ. This operating system is multithreaded and

comes bundled with a UNIX-like ﬁle system and a C++ com-

piler. The authors believe that such an operating system

could signiﬁcantly expand the circle of sensor network appli-

cation developers by providing a familiar programming envi-

ronment based on UNIX, threads, and C++. While TinyOS

and its extensions have signiﬁcantly improved programma-

bility of mote-class embedded devices via a robust, modular

environment, NesC and the event-based programming model

introduce a learning curve for most developers outside the

sensor networks circle. The purpose of LiteOS is to signiﬁ-

cantly reduce such a learning curve. This philosophy is the

operating system equivalent of network directions taken by

companies such as Arch Rock [1] (that superimpose a famil-

iar IP space on mote platforms to reduce the learning curve

of network programming and management).

The rapid advances of sensor networks in the past few

years created many exciting systems and applications. Op-

erating systems such as TinyOS [16], SOS [15], Man-

tis [5], Contiki [9], and t-Kernel [14] provided software plat-

forms. Middleware systems such as TinyDB [21] and En-

viroTrack [4] made fast development of specialized applica-

tions feasible. Deployed applications ranged from global cli-

mate monitoring to animal tracking [18], promising unprece-

dented sampling of the physical world. Widespread adoption

and commercialization of sensor networks is the next logical

step.

The most obvious challenge in sensor network develop-

ment has been to ﬁt within extremely constrained platform

resources. Previous work, such as TinyOS, therefore focused

on reducing overhead and increasing robustness. Since ini-

tial users were researchers, compatibility with common em-

bedded computing environments was not a major concern.

Moving forward, to decrease the barrier to widespread adop-

tion and commercialization, leveraging familiar abstractions

is advisable. One approach is to build user-friendly applica-

tions and GUIs such as SensorMap [25] and MoteView [7].

In this paper, we explore a complementary solution that tar-

gets the operating system and programming environment.

We build a familiar software platform by leveraging the

likely existing knowledge that common users (outside the

current sensor network community) already have: Unix,

threads, and C++. We introduce an interactive operating

system, called LiteOS, and a programming language, called

LiteC++. LiteOS supports a Unix-like environment for mul-

tithreaded user applications, and LiteC++ supports a subset

of C++ (with one keyword from Java) for application devel-

opment. They are referred to in general as the LiteOS plat-

form, when no ambiguity arises. Since our primary goal is

to increase adoption, we also optimize LiteOS for efﬁciency

and robustness.

LiteOS differs from both current sensor network operat-

ing systems and more conventional embedded operating sys-

tems. 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 C++ compiler, or

are only partially supported, such as dynamic loading sup-

port. Compared to the latter category (conventional embed-

ded operating systems), such as VxWorks [31], eCos [2], em-

bedded Linux, and Windows CE, LiteOS has a much smaller

code footprint, running on platforms such as MicaZ, with a

8MHz CPU, 128K bytes of program ﬂash, and 4K bytes of

RAM. Embedded operating systems, such as VxWorks, re-

quire more computation power (e.g., ARM-based or XScale-

based processors) and more RAM (at least tens of KBytes),

and thus cannot be easily ported to MicaZ-class hardware

platforms (such as MicaZ, Tmote, and Telos).

A possible counter-argument to our investment in a small-

footprint UNIX-like operating system is that, in the near

future, Moore’s law will make it possible for conventional

Linux and embedded operating systems to run on motes.

For example, the recent iMote2 [6] platform by CrossBow

features an XScale processor that supports embedded Linux.

Sun and Intel also demonstrated more powerful sensor net-

work hardware platforms [3, 24]. While it is true that more

resources will be available within the current mote form fac-

tor, Moore’s law can also be harvested by decreasing the

form factor while keeping resources constant. For exam-

ple, the current MicaZ form factor is far from adequate for

wearable computing applications. Wearable body networks

can have a signiﬁcant future impact on healthcare, leisure,

and social applications if sensor nodes could be made small

Figure 1. LiteOS Operating System Architecture

enough to be unobtrusively embedded in attire and personal

effects. These applications will drive the need for small-

footprint operating systems and middleware as computation

migrates to nodes that are smaller, cheaper, and more power-

efﬁcient. This paper serves as a proof of concept by push-

ing the envelope within the constraints of a current device;

namely, the MicaZ motes.

We have implemented LiteOS on the MicaZ platform.

The LiteOS kernel is 8300 lines of C code. The LiteOS shell

is 2200 lines of Java code (running on a PC). The kernel com-

piles into 30822 bytes of binary and consumes 1633 bytes of

RAM (for an eight-thread, eight ﬁle-handler setting). The

LiteC++ compiler is 12100 lines of C code (also running on

a PC) and 1200 lines of Perl code. We test the system using

21 application benchmarks written in LiteC++, which them-

selves constitute 1260 lines of code. Comments and blank

lines are not counted. Auxiliary tools, such as those writ-

ten for debugging and testing the system, and device drivers

adapted from other open-source research projects, mostly the

CC2420 radio driver adapted from TinyOS 1.1.x, are also

not counted. We are scheduled to release LiteOS as an open-

source project for the research community in 2007.

The rest of this paper is organized as follows. Sec-

tion 2 introduces the LiteOS operating system and describes

its design and implementation. Section 3 introduces the

LiteC++ programming environment through motivating ex-

amples, and present implementation details. Section 4 gives

an overview of the future directions of LiteOS and its impli-

cations. Section 5 concludes this paper.

2 The LiteOS Operating System

In this section, we present the LiteOS operating system.

We ﬁrst present a system overview and design choices, then

we describe its three subsystems. We include evaluation re-

sults in these subsections to increase readability.

2.1 Architectural Overview

Figure 1 shows the overall architecture of the LiteOS op-

erating system, partitioned into three subsystems: LiteShell,

LiteFS, and the kernel. Implemented on a base station, the

LiteShell subsystem interacts with sensor nodes only when

a user is present. Therefore, LiteShell and LiteFS are con-

nected with a dashed line in this ﬁgure.

LiteOS is designed to support single-node functionality.

It executes applications in a UNIX-like multithreaded envi-

ronment. It also provides a wireless node mounting mech-

Table 1. Shell Commands

Command List

File Commands ls, cd, cp, mv, rm, mkdir, touch, chmod, pwd, du

Process Commands ps, kill, install, uninstall

Group Commands foreach, $, |

Environment Commands history, who, man, echo

Security Commands login, logout, passwd

anism (to use a UNIX term) through a ﬁle system called

LiteFS. Much like connecting a USB drive, a LiteOS node

mounts itself wirelessly to the root ﬁlesystem of a nearby

base station. Moreover, analogously to connecting a USB

device (which implies that the device has to be less than a

USB-cable-length away), the wireless mount works only for

devices within wireless range. The mount mechanism comes

handy, for example, in the lab, when a developer might want

to interact temporarily with a set of nodes on a table-top be-

fore deployment. While not part of the current version, it is

not conceptually difﬁcult to extend this mechanism to a “re-

mote mount service” to allow a network mount. Ideally, a

network mount would allow mounting a device as long as a

network path existed either via the Internet or via multi-hop

wireless communication through the sensor network.

Once mounted, a LiteOS node looks like a ﬁle directory

from the base station. The shell, called LiteShell, supports

UNIX commands, such as copy and move, executed on such

directories. The external presentation of LiteShell is versa-

tile. While our current version resembles closely a UNIX

terminal in appearance, it can be wrapped in a graphical user

interface (GUI), appearing as a “sensor network drive” under

Windows or Linux.

The basic (stripped-down) version of LiteOS is geared

for trusted environments. This choice of default helps re-

duce system overhead when the trust assumptions are sat-

isﬁed. In more general scenarios, where security concerns

are relevant, an authentication mechanism is needed between

the base station and mounted motes. Low-cost authentica-

tion mechanisms for sensor networks have been discussed in

prior literature and are thus not a focus of this paper [26].

2.2 LiteShell Subsystem

The LiteShell subsystem implements a Unix-style shell

for MicaZ-class sensor nodes. It supports an expandable

suite of commands, including both standard Unix ones, such

as ls and cp, and several new ones, such as foreach. Cur-

rently, 23 commands, as listed in Table 2, are implemented.

They fall into ﬁve categories: ﬁle commands, process com-

mands, group commands, environment commands, and se-

curity commands.

File Operation Commands: File commands generally

maintain their Unix meanings, e.g., the ls command lists di-

rectory contents. Typing man ls in the shell returns the fol-

lowing:

$ man ls

LiteOS User Command: LS

SYNOPSIS:

List information about the files alphabetically.

OPTIONS:

-l: list full file information

-u: disable shell data cache

-a: do not hide entries

The -l option displays detailed ﬁle information, such as type,

size, and protection. To reduce system overhead, LiteOS

does not provide any time synchronization service, which

is not needed by every application. Hence, there is no time

information listed. A ls -l command returns the following:

$ ls -l

Name Type Size Protection

usrfile file 100 rwxrwxrwx

usrdir dir --- rwxrwx---

In this example, there are two ﬁles in the current directory

(a directory is also a ﬁle): usrﬁle and usrdir. LiteOS en-

forces a simple multilevel access control scheme. All users

are classiﬁed into three levels, from 0 to 2, and 2 is the high-

est level. Each level is represented by three bits, stored on

sensor nodes. For instance, the usrdir directory can be read

or written by users with levels 2 and 3. The chmod command

can be used to change ﬁle permissions.

Once sensor nodes are mounted, a user uses the above

commands to navigate the different directories (nodes) as if

they are local. The base station PC also has directories, such

as drives C and D. Some common tasks can be greatly sim-

pliﬁed. For example, by using the cp command, a user can

either copy a ﬁle from the base to a node to achieve wire-

less download, or from a node to the base to retrieve data re-

sults

. The remaining ﬁle operation commands are intuitive.

Since LiteFS supports a hierarchical ﬁle system, it provides

mkdir, rm and cd commands.

Process Operation Commands: LiteOS has a multi-

threaded kernel to run multiple applications concurrently.

When an application is ﬁrst loaded, it is executed as a thread

that can spawn new threads. LiteShell provides four com-

mands to control thread behavior: install, uninstall, ps, and

kill. We illustrate these commands through an application

called Blink, which blinks LEDs periodically. Suppose that

this application has been compiled into a binary ﬁle called

Blink.lhex

, and is located under the C drive of the base sta-

tion. To install it on a node named node101 (that maps to

a directory with the same name) in a sensor network named

sn01, the user types the following commands:

$ cp /c/Blink.lhex /sn01/node101/apps/Blink.lhex

Copy complete

$ cd /sn01/node101

$ install ./apps/Blink.lhex

File Blink.ihex installed under bin directory

$ ./bin/Blink.lhex

Blink.lhex started

$ ps

Name PID

Blink 1

As illustrated in this example, LiteOS installs applications

into a directory called bin by default. The user starts an ap-

plication by explicitly typing its name, and views current

threads by using the ps command. Compared to Unix, the

use of install may be debatable: in Unix, an application can

be directly started by invoking its name, without a separate

installation phase. While that design simpliﬁes user opera-

tions, we provide the install command based on the special

The implementation of copy requires that this ﬁle is not con-

currently opened by applications for writing. Otherwise, the copy

operation will return a failure.

LiteOS uses a revised version of the Intel hex format, called

lhex, to store binary applications. lhex stands for LitOS Hex.

hardware of MicaZ: the MCU of MicaZ, Atmega128, fol-

lows the Harvard architecture, which provides a separate pro-

gram space (ﬂash) from its data space (RAM). Only instruc-

tions that have been programmed into the program space can

be executed. Hence, LiteOS has to reprogram part of the

ﬂash in the application installation phase by using the SPM

instruction of Atmega128. In addition, the installation pro-

cedure also involves a binary translation phase that dynam-

ically rewrites parts of the binary, to avoid memory access

conﬂicts of multiple applications. These translation details

are described in Section 2.4. Above all, the installation pro-

cedure on MicaZ is more complicated and costly. If no sepa-

rate install command is supported, when an application is re-

peatedly invoked, it needs to be installed multiple times. To

reduce the installation cost, we allow the user to explicitly

control which programs are going to reside in the program

ﬂash.

After an application is installed, it starts running when in-

voked by the user, as illustrated earlier. Because Blink has

only one thread, the ps command returns one single thread.

Finally, the kill command terminates threads, and the unin-

stall command removes an application from the program

space. (The application binary is not really erased; only its

occupied program space is marked available.)

Loop Command, Pipes, and Regular Expressions:

Even though LiteOS is a node-based operating system, we

ﬁnd it convenient to support certain group operations. For

example, prior to deployment, all nodes are usually kept to-

gether for programming and testing. Operations in this phase

are usually group-based by nature, such as “install an ap-

plication on all nodes”. We have implemented two such

group mechanisms, the foreach command and the $ vari-

able. When used together with regular expressions and pipes,

these two commands loop over a set of nodes (directories) to

perform group operations. We illustrate their usage through

two examples.

Suppose that we have ten nodes labeled 201, 202, up to

210. We have installed and started an application Track-

ing.lhex on each of them (located in the directory bin, and

having a PID of 1), and have copied another application Re-

port.lhex to each node (in the directory apps). To retask

each node with the Report.lhex application, the user types

the following command:

$ echo [201-210] | foreach $ \

{kill 1; uninstall $/bin/Tracking.lhex;\

install $/apps/Report.lhex; $/bin/Report.lhex}

In this example, the echo command generates a list of direc-

tories using a regular expression. Instead of being displayed

by the terminal, these directories are provided to the vari-

able $ through a pipe (spaces between strings are used as

separators), which is in turn used by the foreach command.

As its name suggests, foreach loops over these directories,

terminates and uninstalls the Tracking application, and in-

stalls/invokes the Report application.

In the next example, the $ variable is concatenated with

other strings to generate customized commands. The sce-

nario is as follows. Suppose that the report application

writes data results into a local ﬁle called data.txt on each

node (in its root directory). To retrieve such data, the user

types the cp command as follows:

剩余13页未读，继续阅读

评论收藏

内容反馈

scarlettguojia

2015-04-01

学习轻量级O/S 很好的资料
mjq0011

2015-10-29

好东西，顶！！只是一直找不到源码！
lx0031

2016-05-04

好东西，资源提交很快!
ashine9

2015-07-13

看过了，很有参考价值。
ahui1

2015-06-16

是个号东东，学习学习

sharolgao

粉丝: 15
资源: 16

LiteOS, A Unix-like Operating System and Programming.pdf

最新资源

LiteOS, A Unix-like Operating System and Programming.pdf

华为liteOS操作系统说明手册，写的很详细

鸿蒙内核Liteos-a开发手册.zip

HarmonyOS内核liteos-a开发手册

kernel_liteos_a_note:百万汉字注解，百篇博客分析;精读内核原始码，中文注解分析；深挖地基工程，大脑永久记忆；故事说内核，问答式导读；生活式比喻，表格化说明，图形化展示

A novel harmony search algorithm with gaussian mutation for multi-objective optimization

物联网操作系统LiteOS内核开发与实践-PPT课件.zip

harmonyos英文怎么读-Harmony-OS:来自Huaaaaaaaaaaaaaaaaaaaaaaaaawei的HarmonyOS

Linux Unix System Programming.pdf

The.Design.Of.The.Unix.Operating.System.pdf

Shell.Programming.in.Unix.Linux.and.OS.X.4th.Ed

Addison.Wesley.Advanced.Programming.in.the.UNIX.Environment.Second.Edition.chm

UNIX环境高级编程第二版.chm 英文版 Advanced Programming in the UNIX® Environment: Second Edition

iOS and OS X Network Programming Cookbook

Shell Programming in Unix, Linux and OS X, 4th Edition.pdf

mrbs-1.4.11.zip

Learning GNU C

unix环境高级编程[第二版]

UNIX环境高级编程（第二版）英文chm

Learning the vi and Vim Editors, Seventh Edition

193_4ECH.PDF

No.Starch.Absolute.OpenBSD.2nd.Edition.Apr.2013

wxPython Application Development Cookbook 2016无水印pdf 0分

a project model for the FreeBSD Project.7z

Securing PHP Web Applications.pdf

Python Cookbook英文版

qword：基于“保持简单并使之正常工作”的理念的x86_64操作系统

Qt 5实现串口调试助手 （源工程文件、0积分下载）

【SystemVerilog】路科验证V2学习笔记（全600页）.pdf

最新资源

Qt 5实现串口调试助手（源工程文件、0积分下载）