Design of embedded operating system supporting network sensors

Publisher:快乐的旅程Latest update time:2012-04-05 Source: RFID中国网 Reading articles on mobile phones Scan QR code
Read articles on your mobile phone anytime, anywhere

introduction

Network sensors are resource-constrained embedded devices that integrate sensor technology, embedded computing technology, modern network and communication technology, and distributed information processing technology. They are an important application model of "ubiquitous computing" in the micro-embedded field.

In the past, research on network sensors has been limited by hardware platforms and has developed slowly. With the continuous advancement of semiconductor technology, communication technology, microelectronics technology, and micromechanical technology, low-power, low-cost, and multifunctional sensor network systems have developed rapidly, making it possible to make tiny, flexible, and low-power sensor nodes.

background

Application Features

Network sensor applications have their own characteristics, mainly in the following aspects: small size and low power consumption, concurrent intensive operations, limited physical parallelism and control levels, and diversified design and use. On the one hand, sensor resources are extremely limited, which brings great restrictions to the underlying embedded program design; on the other hand, the applications running on the sensor and the system kernel are usually closely integrated, and the number of tasks required during operation, execution time, execution results, and memory consumption can be well predicted.

In addition, there are many types of sensors, and different types of sensors are needed for different applications. In specific application scenarios such as military applications and space exploration, a large number of different types of sensors are required to work together to complete specific application events. Therefore, if the software system running on the sensor can have relatively good flexibility, configurability and reusability, it will be able to better meet application requirements.

Comparison of Existing Embedded OS

There are many embedded operating systems, among which Vxwork, WindowsCE, pSOS and Neculeus are representative. Their advantages are: powerful functions; rich API and embedded application software; good real-time performance, especially Vxwork; good stability. Disadvantages are: expensive; source code is not open, and a series of problems such as device support and application software porting are caused by it; in addition, for sensor devices, these embedded OS are too "large". uc/os and embedded Linux are currently gaining more and more widespread applications.

Their advantages are: high execution efficiency, small footprint, good scalability, free and open source. UC/OS has good real-time performance, while embedded Linux's real-time performance needs to be further improved. Disadvantages are: they are relatively general embedded operating systems and cannot fully meet the needs of sensor applications. For example, embedded Linux still requires hundreds of K of ROM and RAM space to work, and although the kernel of UC/OS can be reduced to a few K, it is still not concise enough for some sensor applications.

UC Berkeley designed and developed the embedded operating system TinyOS and system programming language nesC for wireless sensor network applications. Based on the analysis of existing embedded OS, especially TinyOS, we designed and implemented a micro embedded operating system γOS that supports network sensors, and developed the system programming
language AntC.

γOS Design

γOS is a micro embedded operating system targeting network sensor applications. Aiming at the aforementioned application characteristics of network sensors, the design of γOS has several features: it supports a sufficiently small hardware system to facilitate the arbitrary distribution of sensor devices in the detection environment; it supports sufficiently low system power consumption to ensure that the sensor devices have a sufficiently long life span; it supports the integration of sensor devices that can interact with the physical world to realize data collection and transmission; and it also takes into account moderately flexible reusability and configurability.

γOS must also address two outstanding issues in sensor networks:

1) Due to the concurrent intensiveness of network sensor operations, the concurrent and instant transmission of many different data streams must be guaranteed;
2) The system must provide an efficient modular management strategy, and specific hardware devices and specific application components must be closely integrated to reduce processing and storage overhead. To this end, the design focus of γOS is mainly on the following aspects: low-energy micro-kernel; micro-threaded system architecture; component-based functional design; and interfaces that support sensor communication.

Tiny core supporting low power consumption

In order to reduce energy consumption, γOS has designed a relatively simple kernel mechanism, which consists of two parts: system initialization code and a tiny core scheduling component. The system initialization code is platform-dependent; the core scheduling component implements a priority-based two-level scheduling mechanism, which consists of two scheduling queues: event queue and task queue. The event queue has a higher priority than the task queue, and each queue is based on the FIFO scheduling mechanism. [page]


Figure 1 γOS kernel scheduling diagram

In addition, in order to reduce energy consumption, based on the energy management algorithm of TinyOS, we designed and implemented energy control components: dynamic power management DPM component and dynamic voltage adjustment DVS component.

Microthreaded system architecture


Figure 2 Microthread system architecture

As shown in Figure 2, γOS uses components to implement a microthreaded system architecture based on an event-driven mode, using event triggers to wake up the corresponding functional components. Each functional component can be composed of the following parts: The event processing function is used to implement the processing of underlying hardware interrupts, such as MCU external interrupts, timer interrupts, etc. It can submit tasks to the core scheduling component, but does not wait for the execution of tasks. Events have high priority, can preempt task execution, and can be passed. It provides a concise method for abstracting the boundaries between software and hardware, making it very simple to support hardware interrupts.

Commands are used to perform operations on underlying components. They are non-blocking and must return the result of the command execution (success or failure) to the caller.

Tasks are used to represent a group of operations with relatively concentrated calculations in a component. Tasks are not preemptive, and are atomic and executed in a first-in-first-out manner, that is, one task must be completed before the next task can be executed. However, tasks can be preempted by event processing functions.

The component status is used to indicate the current working status of the component and can be referenced by its own functions or other components.

By utilizing the micro-threaded system architecture, γOS can effectively reduce the cost of context switching. At the same time, by introducing atomic statements to handle tasks and events, and even concurrent operations between events, it implements a micro-threaded asynchronous communication mechanism, effectively avoiding blocking, polling, and data resource competition.

Component-based functional design

In specific application scenarios, a large number of different types of sensors are required to work together to complete specific application events. Therefore, the software system running on the sensors has relatively good flexibility and configurability.

To this end, γOS provides support for component-based functional design. γOS can be decomposed into a core scheduling component and several functional components. The existing functional components mainly include: energy consumption control components such as dynamic power management DPM components and dynamic voltage adjustment DVS components, AntIP protocol (supporting micro embedded TCP/IP protocol) components, USB driver components, network card driver components and XML analyzer components, etc.

Different functional components are configured according to different applications to achieve specific goals. γOS supports both static configuration and dynamic loading. The static configuration component can include at least one core scheduling component, while other functional components can be pre-statically configured or dynamically loaded according to the corresponding application requirements.


Figure 3 Schematic diagram of γOS components

Interfaces supporting sensor communication

γOS implements the interface support for sensor communication through the AntIP component, mainly supporting peer-to-peer communication and multicast communication modes between sensor nodes, peer-to-peer communication mode between sensor nodes and PCs, and event-based asynchronous communication processing mode. [page]

AntIP is a micro embedded TCP/IP protocol stack suitable for 8/16-bit machines. Although it removes many uncommon functions in the full-featured protocol stack, it still retains the necessary protocol mechanisms for network communication, supports ARP, IP, ICMP, TCP, UDP and other protocols, and provides a simple application layer interface and device driver layer interface. The design of AntIP draws on the design ideas of uip.

Typical Applications


Figure 4 Schematic diagram of the hardware platform

γOS is aimed at network sensor applications and can run on a variety of target sensors. We use the γOS mechanism to design a typical network image sensor system for image data acquisition applications. The system is mainly composed of a main control module, a storage module, a USB host module, an Ethernet module, a camera module, and a serial port module (reserved interface). The chips used are Philips' P89C60X2 (80C51 chip), USB control chip SL811HS, RAM chip 62256, and NIC chip RTL8019AS.

The platform initialization code (AntC language) is as follows:
useSL811HS
useCamera
useRTL8019
classPlatform
{
publicstaticintInit()
{
RTL8019.Init();
if(SL811HS.UsbInit()==FALSE)
return-1;
if(Camera.CameraInit()==FALSE)
return-1;
if(Camera.CameraStart()==FALSE)
return-1;
AntIP.Init();
return1;
}
publicstaticvoidStart()
{
postAntIP.Run;
}
publicstaticvoidmain()
{
Init();
Start();
}
}

This part of the code initializes the network card module, USB module and camera module.

Conclusion

The code size and required data space size of each module of the network image sensor using γOS are shown in Table 1. It can be seen from the table that the core code size of γOS is basically close to the core code size of TinyOS.


Table 1 Module code size and required data space

In this article, we briefly explain the application characteristics of network sensors in ubiquitous computing environments, introduce the design and several characteristics of an embedded operating system γOS that targets network sensors, establish a typical application platform, and finally briefly give the performance of γOS on this platform.

Reference address:Design of embedded operating system supporting network sensors

Previous article:Analysis and discussion on RTX51 TINY
Next article:Design of Remote Temperature Monitoring System Based on AT89C52 Single Chip Microcomputer and TC35i

Latest Microcontroller Articles
  • Download from the Internet--ARM Getting Started Notes
    A brief introduction: From today on, the ARM notebook of the rookie is open, and it can be regarded as a place to store these notes. Why publish it? Maybe you are interested in it. In fact, the reason for these notes is ...
  • Learn ARM development(22)
    Turning off and on interrupts Interrupts are an efficient dialogue mechanism, but sometimes you don't want to interrupt the program while it is running. For example, when you are printing something, the program suddenly interrupts and another ...
  • Learn ARM development(21)
    First, declare the task pointer, because it will be used later. Task pointer volatile TASK_TCB* volatile g_pCurrentTask = NULL;volatile TASK_TCB* vol ...
  • Learn ARM development(20)
    With the previous Tick interrupt, the basic task switching conditions are ready. However, this "easterly" is also difficult to understand. Only through continuous practice can we understand it. ...
  • Learn ARM development(19)
    After many days of hard work, I finally got the interrupt working. But in order to allow RTOS to use timer interrupts, what kind of interrupts can be implemented in S3C44B0? There are two methods in S3C44B0. ...
  • Learn ARM development(14)
  • Learn ARM development(15)
  • Learn ARM development(16)
  • Learn ARM development(17)
Change More Related Popular Components

EEWorld
subscription
account

EEWorld
service
account

Automotive
development
circle

About Us Customer Service Contact Information Datasheet Sitemap LatestNews


Room 1530, 15th Floor, Building B, No.18 Zhongguancun Street, Haidian District, Beijing, Postal Code: 100190 China Telephone: 008610 8235 0740

Copyright © 2005-2024 EEWORLD.com.cn, Inc. All rights reserved 京ICP证060456号 京ICP备10001474号-1 电信业务审批[2006]字第258号函 京公网安备 11010802033920号