You are on page 1of 55


In high end applications, sometimes devices may malfunction or totally fail due to long duration of usage or any technical problem which give fatal results. An embedded monitoring system is necessary for continuously collecting data from onsite and later analyzing that and eventually taking proper measures to solve the problem. The systems that are in use today use non real time operating systems based on mono-task mechanism that hardly satisfies the current requirements. This work will focus on use of µC/OS II in ARM7 controller that performs multitasking and time scheduling. The µC/OS II features are discussed. Finally it provides reliable, stable real time embedded monitoring system using µC/OS II as application software and LPC2148 as the processor.

An embedded system is a special-purpose computer system designed to perform one or few dedicated functions, often with real-time computing constraint. Embedded systems are self contained programs that are embedded within a piece of hardware whereas a regular computer has many different applications and software that can be applied to various tasks. These systems are usually set to a specific task that cannot be altered without physically manipulating the circuitry. The majority of computer system in use today is embedded in other machinery, such as telephones, clocks, applications and vehicles. An embedded system may have minimal requirement for memory and program length. An embedded product uses either a microcontroller or microprocessors to do one task at a time .in an embedded system, there is only one application software that is typically burned into ROM. Example, printer, keyboard, video game player, etc…


1.1. Real Time Embedded System Real-time systems can be defined as those systems that respond to external events in a timely fashion, the response time is guaranteed.

Fig 1: A simple view of real-time systems External events can have synchronous or asynchronous characteristics. Responding to external events includes recognizing when an event occurs, performing the required processing as a result of the event, and outputting the necessary results within a given time constraint. Timing constraints include finish time, or both start time and finish time. A good way to understand the relationship between real-time systems and embedded systems is to view them as two intersecting circles, as shown in figure. It can be seen that not all embedded systems exhibit real-time behaviours nor are all real-time systems embedded. However, the two systems are not mutually exclusive, and the area in which they overlap creates the combination of systems known as real-time embedded systems.

Fig 2: Real-time embedded systems


1.2.1 Peripherals Embedded system communicates with the outside world via peripherals, such as Serial communication interfaces (SCI): RS-232, RS-422, RS-485 etc, Synchronous serial communication interfaces: 12C, JTAG, SPI, SSC, AND ESSI, Universal serial bus (USB), Networks: Ethernet, Controller Area Network, LAN Works etc, Timers: PLL(s) capture/compare and Time Processing Units, Discrete I/O: General Purpose Input/output (GPIO), (ADC/DAC).

A real-time operating system (RTOS) is key to many embedded systems and provides a

software platform upon which to build applications. Not all embedded systems, however, are designed with an RTOS. Some embedded systems with relatively simple hardware or a small amount of software application code might not require an RTOS. Many embedded systems, however, with moderate-tolarge software applications require some form of scheduling and these systems require an RTOS. A real-time operating system (RTOS) is a program that schedules execution in a timely manner, manages system resources, and provides a consistent foundation for developing application code. Commercial RTOS are μC/OS-II, VxWorks, pSOS System, Nucleus, Windows CE. For example, in some applications, an RTOS comprises only a kernel, which is the core supervisory software that provides minimal logic, scheduling, and resource-management algorithms. Most RTOS kernels contain the following components:


Fig 3: Block diagram of application with RTOS Scheduler-is contained within each kernel and follows a set of algorithms that determines which task executes when. Objects-are special kernel constructs that help developers create applications for real-time embedded systems. Common kernel objects include tasks, semaphores, and message queues. Services-are operations that the kernel performs on an object or, generally operations such as timing, interrupt handling, and resource management. Common components in an RTOS kernel include objects, scheduler, and some services. This diagram is highly simplified; not all RTOS kernels confine to this exact set of objects, scheduling algorithms, and services.


Fig 4: Components of RTOS 2.1 RTOS vs. General purpose OS The key difference between general operating systems and real time operating systems is the need for deterministic timing behaviour in the real time operating systems. General-computing non-realtime operating systems are often quite non-deterministic. Their services can inject random delays into application software and thus cause slow responsiveness of an application at unexpected times. 2.2 RTOS Classification RTOS specifies a known maximum time for each of the operations that it performs. Based upon the degree of tolerance in meeting deadlines, RTOS are classified into following categories. 1. Hard Real-Time Systems 2. Soft Real-Time Systems


2.2.1 Hard Real-Time Systems Hard real-time means that the system (i.e., the entire system including OS, middleware, application, HW, communications, etc.) must be designed to guarantee that response requirements are met. It cannot afford missing even a single dead line. Examples: Electronic Engines, Automotive and Flight Control Systems, Medical Systems, Industrial Control Systems, Robotics. 2.2.2 Soft-Real Time Systems Soft real-time systems are exactly the same as hard real-time in its infrastructure requirements, but it is not necessary for system success that every time constraint be met. It allows occasional missing of deadlines. Example: Telecommunication Systems, Internet Video, ATM.

Fig 5: The Real Time Spectrum 2.3 RTOS Advantages RTOS has software that manages the time of a microprocessor or microcontroller. It ensures that the most important code runs first. It allows multitasking, performs more than one thing at the same


time and application is broken down into multiple tasks, each handling one aspect of the application. It provides valuable services to application such as time delays, resource sharing, inter-task communication and synchronization.

MicroC/OS-II (commonly termed µC/OS-II or uC/OS-II), is a low-cost priority-based preemptive real time multitasking operating system kernel for microprocessors, written mainly in the C programming language. It is mainly intended for use in embedded systems. 3.1 Choosing µC/OS-II It is chosen because of the following features.            Written in ANSI C Source code provided Consistent coding style Pre-emptive Deterministic Royalty-free Licensed on a per-end-product basis Extensive Documentation and Support Meets requirements of Safety-Critical Systems Large user base Used in hundreds of products all over the world


3.2 µC/OS-II features Portable Most of µC/OS-II is written in highly portable ANSI C, with target microprocessor specific code written in assembly language. Assembly language is kept to a minimum to take µC/OS-II easy to port to other processors. Like Micro C/OS, Micro C/OS-II can be ported to a large number of microprocessors as long as the microprocessors provides a stack pointer and the CPU register can be pushed onto and popped from the stack. Also, the C compiler should provide either in-line assembly or language extension that allows you to enable and disable interrupt from C. µC/OS-II can run on most 8-, 16-,32 or even 64- bit microprocessors or microcontrollers and DSPs. ROMable µC/OS-II was designed for embedded application. This means that if you have the proper tool chain (i.e. C compiler, assembler and linker/locater), you can embedd Micro C/OS-II as part of a product. Scalable µC/OS-II is designed such a way so that only the services needed in the application can be used. This means that a product can use just a few µC/OS-II services. Another product may require the full set of features. This allows to reduce the amount of memory (both RAM and ROM) needed by µC/OS-II on a per product basis. Scalability is accomplished with the use of conditional complication. Preemptive µC/OS-II is a fully preemptive real time kernel. This means that Micro C/OS-II always runs the highest priority task that is ready.


Multitasking µC/OS-II can manage up to 64 tasks. Each task has a unique priority assigned to it, which mean that µC/OS-II cannot do round robin. There are thus 64 priority levels. Deterministic Execution time of all µC/OS-II functions and services are deterministic. This means that one can always know how much time µC/OS-II will take to execute a function or a service. Furthermore except for one service, execution time all C/OS-II services do not depend on the number of tasks running in the application. Robust and Reliable μC/OS-II is based on μC/OS which has been used in hundreds of commercial applications. μC/OS-II uses the same core and most of the same functions as μC/OS yet offers more features. 3.3 MicroC/OS-II Concepts Multitasking Multitasking is the process of scheduling and switching the CPU between several tasks; a single CPU switches its attention between several sequential tasks. Multitasking maximize the utilization of the CPU and also provides for modular construction of applications. One of the most important aspects of multitasking is that it allows the application programmer to manage complexity inherent in real-time application. Application programs are typically easier to design and maintain if multitasking is used. Task A task is a simple program that thinks it has the CPU all to itself. Each Task has its own stack space and priority based on its importance. Task is assigned a unique priority. A Real-Time application


consists of several tasks executing concurrently. Task has its own set of CPU registers (backup in its stack) .Task is the basic unit for scheduling. Task status is stored in Task Control Block (TCB). Task States Each task typically is an infinite loop that can be in any one of five states: DORMANT, READY, RUNNING, and WAITING (for an event), and ISR (interrupted). Dormant State It is the state corresponds to a task that resides in memory but has not been made available to the multitasking kernel. Deleting task stored in dormant state. Ready State A task is ready when it can execute but its priority is less than the currently running task. Simply say task is ready, but CPU is not available. Running State The task under execution will be in running state.


Fig 6: Task States Waiting State A task is waiting when it require the occurrence of an event (waiting for an I/O operation to complete , a shared resource to be available ,a timing pulse to occur, time to expire, etc….) .Here CPU is ready, but task is not ready. ISR State: A task is in the ISR state when an interrupt has occurred and the CPU is in the process of servicing the interrupt. Context Switch (or Task Switch) When a multitasking kernel decides to run a different task, it simply saves the current task’s context (CPU register) in the current task’s context storage area-its stack. Once this operation is


performed, the new task’s context is restored from its storage area then resumes execution of the new

Fig 7: Multitasking using a context switch

task’s code. This process is called context switch or task switch. Context switching adds overhead to the application. The more registers a CPU has, the higher the overhead. The time required to perform a context switch is determined by how many registers has to be saved and restored by the CPU. Performance of a real time kernel should not be judged by how many context switches the kernel is capable of doing per second. Kernel The kernel is the part of multitasking system responsible for the management of the tasks (i.e.., for managing the CPU’s time) and communication between tasks. The fundamental services provided by the kernel is context switching. The use of real-time kernel generally simplifies the design of system by


allowing the application to be divided into multiple tasks managed by the kernel. A kernel adds overheads to your system because it requires extra ROM (code space) and additional RAM for the kernel data structures. But most importantly, each task requires its own stack space, which has tendency to eat up your RAM quite quickly a kernel also consume CPU time (typically 2to 5 percent). Single-chip microcontrollers are generally not able to run a real-time kernel because they have very little RAM. A kernel allows you to make better use of CPU by provided you with indispensible services a semaphore management, mailboxes, queue, time delay etc. Real-Time Kernel It is the software that manages the time of a microprocessor or microcontroller. It ensures that the most important code runs first. It allows multitasking. Application is broken down into multiple tasks (up to 63) each handling one aspect of your application. It is like having multiple CPUs. It provides valuable services to the application: time delays, resource sharing, inter task communication and synchronization. Scheduler Scheduler is the part of the kernel responsible for determining which task will run next. Most

real-time kernels are priority based. Each task is assigned a priority based on its importance. The priority of each task is application specific. Control is always given to the highest priority task ready to run. Preemptive Kernel A preemptive kernel is used when system responsiveness is important. Because of this, MicroC/OS-II and most commercial real time kernel are preemptive. The highest priority task that is ready to run is always given control of the CPU . When a task makes a higher priority task ready to run, the current task is preempted (suspended) and the higher priority task is immediately given control of the


CPU. If an ISR makes a higher priority task ready, when the ISR complete the interrupted task is.

Fig 8: Preemptive Kernel suspended and the new higher priority task is resumed. 3.4 Starting µC/OS-II In any application µC/OS-II is started as shown in the figure 1. Initially the hardware and software are initialized. The hardware is the ARM core and software is the µC/OS-II. The resources are allocated for the tasks defined in the application. The scheduler is started then. It schedules the tasks in preemptive manner. All these are carried out using specified functions defined in µC/OS-II.


Figure 9: Starting µC/OS-II

3.5 Initializing µC/OS-II µC/OS-II can be initialized as shown in the figure 2. The detailed steps are shown in the figure. Below shows the sample program for the steps shown in the figure. void main (main) { /* user initialization OSInit(); /* /* */

/* kernel initialization */ */ */

Install interrupt vectors

Create at least 1 task (start task)



Additional User code


OSStart(); /* start multitasking */


Disable interrupts Initialize internal OS structures Initialize: Interrupting nesting counter Task counter Context switch counter Statistics Start the execution of the RTOS TCB and event lists

Create the First Application Task (AppTaskStart)

Figure 10: Initializing µC/OS-II

3.6 Task Creation To make it ready for multitasking, the kernel needs to have information about the task: its starting address, top-of-stack (TOS), priority, arguments passed to the task, other information about the task. A task can be created by calling a service provider by µC/OS-II:


OStaskCreate(void (*task) (void *parg),

void *parg,

Address of the task

OS_STK *pstk,

Pointer to task’s Top –Of-Task’

INT8U prio);

Priority of task (0--64)

The ARM core uses a RISC architecture aimed at delivering simple but powerful instructions that execute within a single cycle at a high clock speed. The RISC philosophy concentrates on reducing the complexity of instructions performed by the hardware because it is easier to provide greater flexibility and intelligence in software rather than hardware. As a result RISC design plays greater demands on the compiler. In contrast, the traditional complex instruction set computer (CISC) relies more on the hardware for instruction functionality and consequently the CISC instructions are more complicated. The ARM7 core is based on the von Neumann architecture with 32-bit data bus that carries both instruction and data. Data can be of 8 bits, 16 bits, 32 bits. It has following features:      One cycle execution time Instruction pipeline Memory format Operation modes Coprocessor Debugging feature


Fig 11: ARM core data flow

Load-Store Architecture The processor operates on data held in registers. Separate load and store instructions transfer data between the register bank and external memory. These design rules allow a RISC processor to be simpler, and thus the core can operate at higher clock frequencies. 4.1 ARM Processor Core Similar to most RISC machines ARM works on load-store architecture, so only load and store instructions perform memory operations and all other arithmetic and logical operations are only performed on processor registers. The figure shows the ARM core data flow model in which the ARM


core as functional units connected by data buses. And the arrows represent the flow of data, the lines represent the buses, and boxes represent either an operation unit or a storage area. The figure shows not only the flow of data but also the abstract components that make up an ARM core. 4.2 ARM Characteristics           32/16-bit RISC architecture (ARM v4T) 32-bit ARM instruction set for maximum performance and flexibility 16-bit Thumb instruction set for increased code density Unified bus interface, 32-bit data bus carries both instructions and data Three-stage pipeline 32-bit ALU Very small die size and low power consumption Fully static operation Coprocessor interface Extensive debug facilities (Embedded ICE debug unit accessible via JTAG interface unit)

The advantages of using arm processor ae listed as follows:    Generic layout can be ported to specific process technologies Unified memory bus simplifies SoC integration process ARM and Thumb instructions sets can be mixed with minimal overhead to support application requirements for speed and code density  Code written for ARM7TDMI-S is binary-compatible with other members of the ARM7 Family and forwards compatible with ARM9, ARM9E and ARM10 families, thus it's quite easy to port your design to higher level microcontroller or microprocessor


  

Static design and lower power consumption are essential for battery -powered devices Instruction set can be extended for specific requirements using coprocessors Embedded ICE-RT and optional ETM units enable extensive, real-time debug facilities .

5.1 LPC2148 Features  16-bit/32-bit ARM7TDMI-S microcontroller in a tiny LQFP64 package.  40 KB of on-chip static RAM and 512 KB of on-chip flash memory.  In-System Programming/In-Application Programming (ISP/IAP) via on-chip boot loader software.  Embedded ICE RT and Embedded Trace interfaces offer real-time debugging with the onchip Real Monitor software and high-speed tracing of instruction execution.  USB 2.0 Full-speed compliant device controller with 2 KB of endpoint RAM.  Two 10-bit ADCs provide a total of 14 analog inputs  Single 10-bit DAC provides variable analog output  Two 32-bit timers/external event counters (with four capture and four compare channels each), PWM unit (six outputs) and watchdog.  Low power Real-Time Clock (RTC) with independent power and 32 kHz clock input.  Multiple serial interfaces including two UARTs, two Fast I²C-bus (400 kbit/s), SPI and SSP with buffering and variable data length capabilities.  Vectored Interrupt Controller (VIC) with configurable priorities and vector addresses.  Up to 45 of 5 V tolerant fast general purpose I/O pins in a tiny LQFP64 package.  60 MHz maximum CPU clock available from programmable on-chip PLL with settling time


of 100 us.  On-chip integrated oscillator operates with an external crystal from 1 MHz to 25MHz  Power saving modes include idle and Power-down. 6. SCHEMATIC DIAGRAM The main intention of this work is to design a system that performs continuous monitoring of different parameters using real time operating system other than general OS. The RTOS is chosen to perform multitasking and scheduling so that the most critical tasks are given the highest priority.Arm7 LPC2148 is chosen as the processor. The system structure is illustrated in the Fig.12. It consists of two ARM7 based LPC2148 kits. One ARM7 based system with the sensors deployed is to be employed in the site of monitoring area. Temperature, IR, Humidity and Gas sensors are deployed. Based on the application requirement the sensors can be used. Another ARM based processor is interfaced with the user system. Zigbee module is inserted on both sides. It is used to transfer the data from remote location to the user system. A graphical user interface is used to visualize the incoming data.

ARM (LPC2148)

ARM (LPC2148)

Zigbee Zigbee

RTOS µC/OS II Fig 12: Block diagram


The heart of the system is the real-time kernel that uses preemptive scheduling to achieve multitasking on hardware platform..

Task 3


Task 1



Task 4



Fig 13: Block diagram In Micro C/OS-II maximum number of tasks is 64. In the figure shown above the application has four tasks. Depending on the required application the number of tasks may vary. Here temperature, humidity, gas and IR sensors are the four tasks. Temperature is considered the most critical even and has given the h highest priority. Humidity, gas and IR sensor follow in order.


Gas sensor,MQ5 GND




Dout GND Zigbee

Infrared sensor

Humidity Sensor SY-HS-220 GND Vo/p +vc Vo/p Vo/p
+V c

Fig 14: Transmitter side module

Temperature sensor LM35 GND

Figure 14 shows the connections of various components in the transmitter section. Four sensors temperature, humidity, gas, infrared sensors are used. These sensors calculate the required information at the remote location . This information is transmitted to the receiver using Zigbee module. Temperature, humidity, gas, infrared sensor outputs are connected to p0.30, p0.25, p0.3, p0.29 respectively. 7.1 Temperature sensor

Fig 15: Temperature sensor 7.1.1 General description The LM35 series are precision integrated-circuit temperature sensors, whose output voltage is linearly proportional Celsius (Centigrade) temperature. The LM35 thus has an advantage over linear

temperature sensors calibrated in ° Kelvin, as the user is not required to subtract a large constant voltage from its output to obtain convenient Centigrade scaling. The LM35 does not require any external calibration or trimming to provide typical accuracies of ±¼°C at room temperature and ±¾°C over a full -55 to +150°C temperature range. Low cost is assured by trimming and calibration at the wafer level. The LM35's low output impedance, linear output, and precise inherent calibration make interfacing to


readout or control circuitry especially easy. It can be used with single power supplies, or with plus and minus supplies. As it draws only 60 µA from its supply, it has very low self-heating, less than 0.1°C in still air. The LM35 is rated to operate over a -55° to +150°C temperature range. 7.1.2 Features            Calibrated directly in ° Celsius (Centigrade) Linear + 10.0 mV/°C scale factor 0.5°C accuracy guaranteeable (at +25°C) Rated for full -55° to +150°C range Suitable for remote applications Low cost due to wafer-level trimming Operates from 4 to 30 volts Less than 60 µA current drain Low self-heating, 0.08°C in still air Nonlinearity only ±¼°C typical Low impedance output, 0.1 Ohm for 1 mA load

7.1.3 Parametric values       Supply 4 Volt Quiescent Current_ 56 µA Temperature Min 40, -55, 0 deg C Temperature Max 100, 110, 150 deg C Sensor gain 10 mV/Deg C Temperature Accuracy 1, 0.5 deg C


       

Quiescent Current_ 56 µA Temperature Min 40, -55, 0 deg C Temperature Max 100, 110, 150 deg C Sensor Gain 10 mV/Deg C Supply voltage 30 Volt Single Supply No Output Impedance 0.4 Ohm Quiescent Current 0.056 µA

In this circuit, parameter values commonly used are:        Vc = 4 to 30v 5v or 12 v are typical values used. The output voltage is converted to temperature by a simple conversion factor. The sensor has a sensitivity of 10mV / oC. Use a conversion factor that is the reciprocal, that is 100 oC/V. The general equation used to convert output voltage to temperature is: Temperature (ºC) = Vout * (100 ºC /V).So, if Vout is 1V , then, Temperature = 100ºC. The output voltage varies linearly with temperature.


7.2 Humidity sensor

Fig 16: Humidity sensor SY-HS-220 is the humidity sensor used. It converts relative humidity to output voltage. 7.2.1 Specifications

Rated voltage Rated power

: 5.0v : <=3.0mv

Operating temperature: 0-60C Storage humidity : within 95%RH

Storage temperature : -30 t0 85C Standard Output Accuracy : 25C at 60%RH : +or -5C


7.3 Gas sensor

Fig 17: Gas sensor 7.3.1 Features     

High sensitivity to LPG, natural gas , town gas Small sensitivity to alcohol, smoke. Fast response Stable and long life Simple drive circuit

7.3.2 Typical detection ranges:  It can detect town gases, hydrogen, 100ppm to 3,000ppm

7.3.3 Applications They are used in gas leakage detecting equipments in family and industry, are suitable for detecting of LPG, natural gas , town gas, avoid the noise of alcohol and cooking fumes and cigarette smoke.


7.4 Infrared sensor

Fig 18: IR led and IR sensor pairs The hardware module of IR sensor contains a TX-RX pair. An IR Led acts as a source for emitting IR rays. A reverse biased IR sensor is there for detecting this IR rays. This module is used to count the number of obstacles in its path. 7.5 Zigbee In an industry during certain hazards it will be very difficult to monitor the parameter through wires and analog devices such as transducers. To overcome this problem we use wireless device to monitor the parameters so that we can take certain steps even in worst case. Few years back the use of wireless device was very less, but due to the rapid development in technology nowadays we use maximum of our data transfer through wireless like wi-fi, Bluetooth, wimax, etc. In view of all these things, the design of wireless parameter progress helps in an industry to monitor the parameter in real time with the use of zigbee, is an easy installation platform, cost effective method for the low bit rate transmission, so with the help of the ready zigbee platform by using the PSoC Designer we interface the module with the pc and we monitor the parameters in the system.


The main use of this module helps in an industry during the worst cases as the analog device may be damaged during the fire accidents, etc. But with the wireless transmission we have an accurate data but when compared to the analog failure the errors are very minimum so we use wireless to monitor the parameter in an industry where there is no means of human interface to monitor the parameters. In this work the parameters are monitored wireless by using zigbee ready platform which is based on the IEEE 802.15.4, 2.4 GHz. The working of this module is simple in principle, the changes in certain place is monitored in real time process which is very accurate in monitoring. Here we monitor temperature, light and humidity with the help of respective sensors. This can be widely used for home automation, industrial application which helps for an easy wireless communication for a low data rate transmission. 7.5.1 Characteristics Characteristics of zigbee are: 

Low power consumption, with battery life ranging from months to years. Considering the number

of devices with remotes in use at present, it is easy to see that more numbers of batteries need to be provisioned every so often, entailing regular (as well as timely), recurring expenditure. In the ZigBee standard, longer battery life is achievable by either of two means: continuous network connection and slow but sure battery drain, or intermittent connection and even slower battery drain.  Maximum data rates allowed for each of these frequency bands are fixed as 250 kbps @2.4 GHz,

40 kbps @ 915 MHz, and 20 kbps @868 MHz.    High throughput and low latency for low duty-cycle applications (<0.1%) Channel access using Carrier Sense Multiple Access with Collision Avoidance (CSMA - CA) Addressing space of up to 64 bit IEEE address devices, 65,535 networks


  

50m typical range Fully reliable “hand-shaked” data transfer protocol. Different topologies as illustrated below: star, peer-to-peer, mesh.

7.5.2 Applications

ZigBee protocols are intended for use in embedded applications requiring low data rates and low power consumption. ZigBee's current focus is to define a general-purpose, inexpensive, self-organizing mesh network that can be used for industrial control, embedded sensing, medical data collection, smoke and intruder warning, building automation, home automation, etc. The resulting network will use very small amounts of power so individual devices might run for a year or two using the originally installed battery.

Typical application areas include:  Home Entertainment and Control - Smart Lighting, Advanced Temperature Control, Safety &

Security and Movies & Music   Home Awareness - Water Sensors, Power Sensors, Smart Appliances and Access sensors Mobile Services – m-payment, m-monitoring and control, m-security and access control, m-

healthcare.   Commercial Building– Energy Monitoring, HVAC, Lighting, Access Control Industrial Plant– Process Control, Asset Management, Environmental management, Energy







Fig 19: Receiver side module

Figure 19 shows receiver side connections. The information from the transmitter is sent to the receiver through Zigbee. The output is viewed on the matlab GUI. RTOS is not necessary in the receiving section since it does not perform any scheduling.

In this work four types of software tools are used 1. Keil Vision4 compiler 2. Flash magic tools 3. Matlab GUI 9.1 Keil uVision4 Keil is a cross compiler which is developed by ARM Ltd. It supports software development and debugging for ARM7, ARM9, and Cortex-M based microcontroller devices. A cross compiler is a compiler capable of creating executable code for a platform other than the one on which the compiler is run. Cross compiler tools are used to generate executables for embedded system or multiple platforms. It is used to compile for a platform upon which it is not feasible to do. In this, Cross compilers are used for developing applications for ARM microcontroller. The cross compilers run on host computer and develops application for different architecture i.e., for ARM architecture. 9.2 Flash magic tool To download the hex file into the microcontroller board we use a software called flash magic tool.


Fig 20: Flash magic tool Step 1-Communications Set COM Port :COM1 Baud Rate : 19200 Device : LPC2148 Interface: None(ISP) Oscillator Freq(MHz):12 Step 2-Eras


Select the box Erase all Flash + Code Rd Prot Step 3-Hex File Click on browse to load the serial.hex file from the folder serial_driver.

Step 4-Options Select the box Verify after programming. Power up the microcontroller board using USB cable, make serial cable connection between PC and microcontroller’s UART0 db9 connector.

To make the board enter programming mode Hold down SW2 (isp) and SW3 (reset), then release SW3 first and finally SW2.

Step 5-Start Click the Start button After finishing the programming, To check the result, open hyper terminal in PC using with same Flash Magic tool

Set baud rate: 19200.


Com port: com1 Click on ok button.

Now, to put the microcontroller in RUN mode, press RESET. Then we will get our output. 9.3 Matlab GUI GUIDE or the Graphical User Interface development environment is a tool for laying out and programming GUI’s. A GUI uses graphics and text input to make using Matlab much more user friendly for people who are unfamiliar with it. GUI’s can be created without using GUIDE but laying out the design of the window can be very time consuming. To open GUIDE click on the start button in the bottom left corner of Matlab and select START→MATLAB→GUIDE. A graphical user interface provides the user with a familiar environment in which to work. This environment contains pushbuttons, toggle buttons, lists, menus, text boxes, and so forth, all of which are


already familiar to the user, so that he or she can concentrate on using the application rather than on the mechanics involved in doing things. However, GUIs are harder for the programmer because a GUI-based program must be prepared for mouse clicks (or possibly keyboard input) for any GUI element at any time. Such inputs are known as events, and a program that responds to events is said to be event driven. The three principal elements required to create a MATLAB Graphical User Interface are 1. Components. Each item on a MATLAB GUI (pushbuttons, labels, edit boxes, etc.) is a graphical component. The types of components include graphical controls (pushbuttons, edit boxes, lists, sliders, etc.), static elements (frames and text strings), menus, and axes. Graphical controls and static elements are created by the function uicontrol, and menus are created by the functions uimenu and uicontextmenu. Axes, which are used to display graphical data, are created by the function axes. 2. Figures. The components of a GUI must be arranged within a figure, which is a window on the computer screen. In the past, figures have been created automatically whenever we have plotted data. However, empty figures can be created with the function figure and can be used to hold any combination of components. 3. Callbacks. Finally, there must be some way to perform an action if a user clicks a mouse on a button or types information on a keyboard. A mouse click or a key press is an event, and the MATLAB program must respond to each event if the program is to perform its function. For example, if a user clicks on a button, that event must cause the MATLAB code that implements the function of the button to be executed. The code executed in response to an event is known as a call back. There must be a callback to implement the function of each graphical component on the GUI. The GUI for this work is shown below

Fig 21: Graphical User Interface to display the acquired data


The work is successfully tested and got the desired results.

Fig 22: LPC2148 with sensor connections

In this the problem of monitoring devices using general operating systems has been discussed. They lack in reliability and stability. The system designed here offers a reliable cost effective sensing system using the ARM and µC/OS II. Here four tasks are scheduled and monitored. Such real time data acquisition systems have been identified as being useful in a variety of domains including industrial and military applications. They are mainly used for sensor applications in electronic warfare as the data coming from sensors is sent to the processing unit and since we are using a Real Time Operating System to capture the data from sensors, simultaneous data capture from many sensors is possible and priority can be given to critical data. It is very useful for military based applications and industrial based applications where some of the sensors outcome data is very critical out of many sensors data. Furthermore they are also used in several civilian application areas, including environment and habitat monitoring, healthcare applications, home automation, and traffic control.


This circuit can be extended such that it can measure multiple parameter by interfacing the number sensors. By using the advanced technologies and advanced processors the system can be made that it not only sense the parameters but also control them by varying their values if it exceed the optimum levels.

13.1 Implementation code at transmitter side #include "config.h" #include "stdlib.h" #include "header.h"

#defineTaskStkLengh 64

//Define the Task0 stack length

extern unsigned int tmp,x; unsigned char Temp[2];

OS_STK TestTask1Stack[TaskStkLengh]; void TestTask1(void *pdata);

OS_STK TestTask2Stack[TaskStkLengh]; void TestTask2(void *pdata);


OS_STK TestTask3Stack[TaskStkLengh]; void TestTask3(void *pdata);

OS_STK TestTask4Stack[TaskStkLengh]; void TestTask4(void *pdata);

void Initpll(void); void initlcd(void); void DECtoASCII(unsigned int data); int main (void) { PINSEL0 = 0x00050005; PINSEL1 = 0x15000000; IO0DIR |= 0x00001000; Initpll(); InitUart0(); InitUart1(); read_temp(); //UART0 //using adc0.1,adc0.2,adc0.3

OSInit(); OSTaskCreate(TestTask1, (void *)0, &TestTask1Stack[TaskStkLengh-1], 0);


OSTaskCreate(TestTask2, (void *)0, &TestTask2Stack[TaskStkLengh-1], 1); OSTaskCreate(TestTask3, (void *)0, &TestTask3Stack[TaskStkLengh-1], 2); OSTaskCreate(TestTask4, (void *)0, &TestTask4Stack[TaskStkLengh-1], 3); OSStart(); return 0; }

void TestTask1(void *pdata) { TargetInit (); while(1) { read_temp();

OSTimeDlyHMSM(0, 0, 0,900); } }

void TestTask2(void *pdata) { while(1)


{ read_count(); OSTimeDlyHMSM(0, 0, 0,200); } } void TestTask3(void *pdata) { while(1) { read_humidity(); OSTimeDlyHMSM(0, 0, 0,300); } }

void TestTask4(void *pdata) { while(1) {

read_gas(); OSTimeDlyHMSM(0, 0, 0,200);




void Initpll() { PLL0CFG=0x00000024; PLL0CON=0x00000001;

PLL0FEED=0x000000AA; PLL0FEED=0x00000055;

while(!(PLL0STAT & 0x00000400));

PLL0CON = 0x00000003;

PLL0FEED =0x000000AA; PLL0FEED=0x00000055; }


13.2 Implementation code at receiver side #include <LPC214X.H> int a; void isr (void) __irq { if(VICIRQStatus & 0x00000080) { if(U1IIR & 0x04) { U0THR=U1RBR;


VICVectAddr=0x00000000; } } int main()


{ PINSEL0 = 0x00050005; //using UART 0 & 1 PINSEL2 = 0x00000000; InitUart0(); InitUart1(); U1IER=0x01; VICDefVectAddr=(unsigned)isr; //(non vectored) VICIntEnable=0x00000080; Tx_string0("RTDA"); UART1 Rx interrupt

while(1) { } }

13.3 Real Time Data Acquisition code to display the acquired data in Matlab-GUI

function varargout = Real_time(varargin) % REAL_TIME M-file for Real_time.fig % % % % H = REAL_TIME returns the handle to a new REAL_TIME or the handle to REAL_TIME, by itself, creates a new REAL_TIME or raises the existing singleton*.


% % % % % % % % % % % % % %

the existing singleton*.

REAL_TIME('CALLBACK',hObject,eventData,handles,...) calls the local function named CALLBACK in REAL_TIME.M with the given input arguments.

REAL_TIME('Property','Value',...) creates a new REAL_TIME or raises the existing singleton*. Starting from the left, property value pairs are applied to the GUI before Real_time_OpeningFcn gets called. An unrecognized property name or invalid value makes property application stop. All inputs are passed to Real_time_OpeningFcn via varargin.

*See GUI Options on GUIDE's Tools menu. Choose "GUI allows only one instance to run (singleton)".


% Edit the above text to modify the response to help Real_time

% Last Modified by GUIDE v2.5 09-Jun-2011 17:12:35

% Begin initialization code - DO NOT EDIT gui_Singleton = 1; gui_State = struct('gui_Name', mfilename, ...

'gui_Singleton', gui_Singleton, ... 'gui_OpeningFcn', @Real_time_OpeningFcn, ...


'gui_OutputFcn', @Real_time_OutputFcn, ... 'gui_LayoutFcn', [] , ... 'gui_Callback', []); if nargin && ischar(varargin{1}) gui_State.gui_Callback = str2func(varargin{1}); end

if nargout [varargout{1:nargout}] = gui_mainfcn(gui_State, varargin{:}); else gui_mainfcn(gui_State, varargin{:}); end % End initialization code - DO NOT EDIT

% --- Executes just before Real_time is made visible. function Real_time_OpeningFcn(hObject, eventdata, handles, varargin) % This function has no output args, see OutputFcn. % hObject handle to figure

% eventdata reserved - to be defined in a future version of MATLAB % handles structure with handles and user data (see GUIDATA) % varargin command line arguments to Real_time (see VARARGIN)

% Choose default command line output for Real_time


handles.output = hObject;

% Update handles structure guidata(hObject, handles);

% UIWAIT makes Real_time wait for user response (see UIRESUME) % uiwait(handles.figure1);

% --- Outputs from this function are returned to the command line. function varargout = Real_time_OutputFcn(hObject, eventdata, handles) % varargout cell array for returning output args (see VARARGOUT); % hObject handle to figure

% eventdata reserved - to be defined in a future version of MATLAB % handles structure with handles and user data (see GUIDATA)

% Get default command line output from handles structure varargout{1} = handles.output;

% --- Executes on button press in pushbutton1. function pushbutton1_Callback(hObject, eventdata, handles) % hObject handle to pushbutton1 (see GCBO)

% eventdata reserved - to be defined in a future version of MATLAB


% handles clc; while 1

structure with handles and user data (see GUIDATA)

s=serial('com1'); fopen(s); a=fread(s,30) fclose(s); for i=1:20 if a(i)==97 i=i+1; c=num2str(a(i)); set(handles.temp,'String',c);

elseif a(i)==98 i=i+1; c=num2str(a(i)); set(handles.count,'String',c);

elseif a(i)==99 i=i+1; c=num2str(a(i)); set(handles.humid,'String',c);

elseif a(i)==100 i=i+1;


c=num2str(a(i)); set(handles.gas,'String',c); end

end %disp('a'); pause(2); end

function count_Callback(hObject, eventdata, handles) % hObject handle to count (see GCBO)

% eventdata reserved - to be defined in a future version of MATLAB % handles structure with handles and user data (see GUIDATA)

% Hints: get(hObject,'String') returns contents of count as text % str2double(get(hObject,'String')) returns contents of count as a double

% --- Executes during object creation, after setting all properties. function count_CreateFcn(hObject, eventdata, handles) % hObject handle to count (see GCBO)

% eventdata reserved - to be defined in a future version of MATLAB % handles empty - handles not created until after all CreateFcns called


% Hint: edit controls usually have a white background on Windows. % See ISPC and COMPUTER.

if ispc && isequal(get(hObject,'BackgroundColor'), get(0,'defaultUicontrolBackgroundColor')) set(hObject,'BackgroundColor','white'); end

function gas_Callback(hObject, eventdata, handles) % hObject handle to gas (see GCBO)

% eventdata reserved - to be defined in a future version of MATLAB % handles structure with handles and user data (see GUIDATA)

% Hints: get(hObject,'String') returns contents of gas as text % str2double(get(hObject,'String')) returns contents of gas as a double

% --- Executes during object creation, after setting all properties. function gas_CreateFcn(hObject, eventdata, handles) % hObject handle to gas (see GCBO)

% eventdata reserved - to be defined in a future version of MATLAB % handles empty - handles not created until after all CreateFcns called

% Hint: edit controls usually have a white background on Windows. % See ISPC and COMPUTER.


if ispc && isequal(get(hObject,'BackgroundColor'), get(0,'defaultUicontrolBackgroundColor')) set(hObject,'BackgroundColor','white'); end

function humid_Callback(hObject, eventdata, handles) % hObject handle to humid (see GCBO)

% eventdata reserved - to be defined in a future version of MATLAB % handles structure with handles and user data (see GUIDATA)

% Hints: get(hObject,'String') returns contents of humid as text % str2double(get(hObject,'String')) returns contents of humid as a double

% --- Executes during object creation, after setting all properties. function humid_CreateFcn(hObject, eventdata, handles) % hObject handle to humid (see GCBO)

% eventdata reserved - to be defined in a future version of MATLAB % handles empty - handles not created until after all CreateFcns called

% Hint: edit controls usually have a white background on Windows. % See ISPC and COMPUTER.

if ispc && isequal(get(hObject,'BackgroundColor'), get(0,'defaultUicontrolBackgroundColor')) set(hObject,'BackgroundColor','white');



function temp_Callback(hObject, eventdata, handles) % hObject handle to temp (see GCBO)

% eventdata reserved - to be defined in a future version of MATLAB % handles structure with handles and user data (see GUIDATA)

% Hints: get(hObject,'String') returns contents of temp as text % str2double(get(hObject,'String')) returns contents of temp as a double

% --- Executes during object creation, after setting all properties. function temp_CreateFcn(hObject, eventdata, handles) % hObject handle to temp (see GCBO)

% eventdata reserved - to be defined in a future version of MATLAB % handles empty - handles not created until after all CreateFcns called

% Hint: edit controls usually have a white background on Windows. % See ISPC and COMPUTER.

if ispc && isequal(get(hObject,'BackgroundColor'), get(0,'defaultUicontrolBackgroundColor')) set(hObject,'BackgroundColor','white'); end


% --- Executes on button press in stop. function stop_Callback(hObject, eventdata, handles) % hObject handle to stop (see GCBO)

% eventdata reserved - to be defined in a future version of MATLAB % handles structure with handles and user data (see GUIDATA)

close all;

[1] Liu Zhongyuan, Cui Lili, Ding Hong, “Design of Monitors Based on ARM7 and Micro C/OSII”, College of Computer and Information, Shanghai Second Polytechnic University, Shanghai, China, 2010. [2] Jian Fenga, Hongmei Jin, “μC/OS-II Port for STM32F107VC Processor” College of Computer Science and Technology, Xi’an University of Science and TechnologyXi’an, China, 2011. [3]. Tianmiao Wang “The Design And Development of Em bedded System Based on ARM Micro System and IlC/OS-II Real-Time Operating System” Tsinghua University Press. [4] Jean J Labrosse, MicroC/OS-II The Real-Time Kernel, Second Edition Beijing University of Aeronautics and Astronautics Press, [5]