Overview of
For the
· Fast Bootstrap processes
· Immediate response to switching from one application to another
· Efficient back-up/synchronization operations
The requirements are best met by using real-time operating systems (RTOS), which provide the means for fast and efficient responses needed for running the PDAs.
In general, real-time operating systems are said to require:
· Multitasking
· Process threads that can be prioritized
· A sufficient number of interrupt levels
Real-time operating systems are often required in small embedded operating systems that are packaged as part of microdevices. Some kernels can be considered to meet the requirements of a real-time operating system. However, since other components, such as device drivers, are also usually needed for a particular solution, a real-time operating system is usually larger than just the kernel.
It is important to distinguish between a real-time system and a real-time operating system (RTOS). The real-time system consists of all elements—the hardware, operating system, and applications—that are needed to meet the system requirements. The RTOS is just one element of the complete real-time system and must provide sufficient functionality to enable the overall real-time system to meet its requirements.
Since communications in mobile phones have real time requirements, the operating system designed for them require real time capabilities apart from the normal embedded requirements.
Scope
The paper explores the aspects of
Each of these aspects is discussed in general for normal embedded RTOS, and compared with that in mobile / PDA OS, thereby showing how a complete operating system has evolved to serve the domain of Wireless Information Devices.
1. Need for OS in Embedded Applications
The computers used to control equipment, otherwise known as embedded systems, have been around for about as long as computers themselves. They were first used back in the late 1960s in communications to control electromechanical telephone switches.
However, as more efficient and compact devices were required, systems came into being which were microprocessor / microcontroller driven. The progress came took the form of moving towards more and more smaller, compact and much faster devices bringing size, power and performance related issues into being.
Increasingly, these embedded systems need to be connected to some sort of network, and thus require a networking stack, which increases the complexity level and requires more memory and interfaces, as well as the services of an operating system.
The operating system must handle multi-tasking, event based handling priorities, turn-around time, response time, efficient memory handling, etc..
The most recent developments have led to the development of embedded systems with real time requirements. In a real-time system the correctness of the system behavior depends not only the logical results of the computations, but also on the physical instant at which these results are produced. A real-time system changes its state as a function of physical time e.g. incoming call in a mobile phone. Based on this a real-time system can be decomposed into a set of subsystems i.e., the controlled object, the real-time computer system and the human operator. A real-time computer system must react to stimuli from the controlled object (or the operator) within time intervals dictated by its environment. The instant at which a result is produced is called a deadline. If the result has utility even after the deadline has passed, the deadline is classified as soft, otherwise it is firm. If a catastrophe could result if a firm deadline is missed, the deadline is hard.
2. Features of Embedded RTOS
The advent of microprocessors has opened up several product opportunities
that simply did not exist earlier. These intelligent processors have invaded and
embedded themselves into all fields of our lives be it the kitchen (food processors, microwave ovens), the living rooms (televisions, air conditioners) or the work places (fax machines, pagers, laser printer, credit card readers) …etc.
As the complexities in the embedded applications increase, use of an operating
system brings in lot of advantages. Most embedded systems also have real-time
requirements demanding the use of Real time Operating Systems (RTOS) capable of meeting the embedded system requirements. Real-time Operating System allows real time applications to be designed and expanded easily. The use of an RTOS simplifies the design process by splitting the application code into separate tasks. An RTOS allows one to make better use of the system recourses by providing with valuable services such as semaphores, mailboxes, queues, time delays, time outs…etc.
This section looks at the basic concepts of embedded systems, operating systems and specifically at Real Time Operating Systems in order to appreciate the domain constraints that one has to keep in mind while designing mobile / PDA RTOS.
2.1 Memory Management
In order to have software there must be a place to store the executable code and temporary storage for run-time data manipulations. These take the form of ROM and RAM respectively. To classify further, ROM takes the form of classical ROM used for storing the bootstrap, and FLASH, which is a read / write form of permanent storage medium. RAM can again be of two types – DRAM (Dynamic RAM) and SRAM (battery backed up Static RAM). If memory requirement is small, it may be contained in the same chip as the processor. Otherwise one or both types of memory will reside in external memory chips.
In embedded applications, memory is the most expensive resource. Thus, it is the endeavor of any good designer to strive to reduce the memory requirements to the minimum. There are multiple ways of achieving this –
· Reducing the kernel to micro kernel which comprises of essential modules like scheduler, IPC, interrupt handler
· Compact Applications Development that consume little memory space
· Dynamic Linking and Sharing of code
· XIP – eXecute In Place
Each programs need to held in a memory generally in a ROM to be executed. The task data (stack and registers) and all variables must be stored in RAM. In a real-time system the main requirement is that the access time should be bound or predictable. The use of demand paging is not allowed since the systems providing virtual memory mechanisms use memory swapping which is not predictable. RTOS have fast and predictable functions to allocate and free fixed size buffers. RTOS allows to setup pools each of which consist of same number of memory buffers. In any given pool all buffers are of same size. In many circumstances it is not acceptable for hardware failure to corrupt data in memory. In such instance hardware protection mechanism should be used. In many OSes like µCLinux, static memory allocation is used. However, if a memory management unit is present, dynamic memory allocation is preferred.
2.1.1 Structure of Flash RAM
The structure of Flash memory is as shown above. Each application has its own design of the Flash layout, but in general it has three basic parts :-
· Kernel (Compressed / Uncompressed)
· File System
· Boot Loader
Since Flash is a permanent, yet modifiable storage medium, i.e. it can be reburnt, having the kernel burnt onto it allows the kernel to be modified at a later date, to add more services. File System too resides on the flash making it a good permanent storage medium for data as well as programs. The boot loader is located at the end or start of the Flash. This allows the OS to easily run the loader at startup to perform system check and bring up the system. Each Flash partition is strictly enforced to prevent accesses from exceeding their allocated spaces.
During run time, execution involving Flash may take place in two ways –
1. Compressed Kernel from Flash is uncompressed and loaded onto RAM from where it is executed. This method is used when the allowable space on the Flash is small and RAM is bigger.
2. XIP (eXecute In Place) – This method is used when the RAM available is small and has demands from other needs. In this case, the kernel may be burnt onto the Flash in the uncompressed form and during runtime, it is run directly from the Flash.
2.1.2 RAM (Random Access Memory)
RAM is a fast, and cheap medium of storage used for storing volatile data. It acts as a temporary storage medium during execution for data, stack, and operating system. The memory management unit of the operating system manages this memory, allocating separate memory space for each process and enforcing protection of each of the memory space.
2.2 File System
File System is one of the core features of an operating system which determines the type and speed of accesses and storage techniques. A good file system is one which has minimal wastage of resources, is made of relocatable elements, and allows a fast and efficient search.
A variety of file systems have evolved, for different environments and different constraints. The file systems used predominantly in embedded applications have stiff demands of fast access and efficient utilization of space, with minimal overhead.
Flat File System
A flat file is a file containing records that have no structured interrelationship. The term is frequently used to describe a textual document from which all word processing or other structure characters or markup have been removed.
A system of organizing files in an operating system in which all files are stored in a single directory. In contrast to a hierarchical file system, in which there are directories and subdirectories and different files can have the same name as long as they are stored in different directories, in a flat file system every file must have a different name because there is only one list of files. Early versions of the Macintosh and DOS operating systems used a flat file system.
Record based File System
Here, the memory is divided into fixed sized chunks called records. Early file systems were designed to be of this type for e.g. DOS. In this case the handling of records was clean and transfer of data between various media was also fast. However, it led to a lot of internal fragmentation, and thus wastage of memory for PC based file systems. However, in some embedded environments, where performance was more important than memory wastage, such a file system was often used. Files collectively formed a database, and each file was made of multiple records.
Page based File System
This form of File System evolved later, which used a technique called Demand Paging. Here the memory was divided into pages of same or different sizes and request and allocation was done based on these sizes. A Memory Management Unit was required which handled page faults and performed page allocation to various processes.
2.3 Scheduling Algorithms
A scheduling algorithm is a set of rules that determines the task to be executed at a particular moment. It is the job of the scheduling algorithm and operating system scheduler to provide predictability to the system and to coordinate resources to meet the timing constraints of the physical system. Traditionally, many real-time systems have used the cyclical executives approach for scheduling [10]. Cyclical executives provide a deterministic schedule for all tasks and resources in a real-time system by creating a static timeline upon which tasks and resources are assigned specific time intervals. While such an approach is manageable for simple systems, it quickly becomes unmanageable for large systems. It is a painful process to develop application code so to fit the time slots of a cyclical executive while ensuring that the critical sections of different tasks do not interleave. This approach is typically expensive to create, verify, and update.
An alternative approach uses preemptive and priority-driven scheduling algorithms to schedule tasks. Embedded systems, particularly real-time systems, almost always require a way to share the processor that allows the most important tasks to grab the control of processor as soon as they need it. A deadline driven scheduling mechanism is the ideal one. However, the current state of technology does not allow this. Therefore most embedded operating systems utilize a priority based scheduling algorithm that supports pre-emption. We also need that interrupt handling in case of different simultaneous interrupts should be handled in a preemptive way.
A good embedded RTOS should have provision for lot of priority levels. A number of high priority levels have to be dedicated to the system processes and threads. And in a complex application with large number of threads, it is essential to be able to place all the real-time threads on a different priority level above the non real-time threads.
There is also necessary to have a backup scheduling policy. This is the scheduling algorithm to be used in the event that several ready tasks have same priority. The most common backup algorithm used is the round robin. If there are no tasks in ‘ready state’ when a scheduler is called, the idle task will be executed which is basically an infinite loop that does nothing. Idle task will have the lowest priority and will always be in ready state.
The actual process of changing from one task to another is called a context switch. Since the contexts are processor-specific, the code that implements this is also processor-specific. So it is always written in assembly language. For real-time systems the context switch should take only the bare minimum of time because this determines the response.
Using well defined algorithms to schedule tasks in a real-time system yields an understandable scheduling solution. Since the algorithmic approach accurately models the timing behavior of the system, the resulting schedule is easier to test.
2.3.1 Scheduling Periodic Tasks
The preemptive real-time scheduling algorithms can be broadly classified into two categories: static priority and dynamic priority. This classification is based on the manner in which priorities are assigned to tasks. A scheduling algorithm is said to be static if priorities are assigned to tasks a priori and they do not change during run-time. A static algorithm is also called a fixed priority scheduling algorithm, an example of which is the Rate Monotonic algorithm. A scheduling policy is said to be dynamic if priorities of a task might change from request to request. Earliest Deadline First algorithm falls under the category of dynamic priority scheduling policy. Before discussing these algorithms in detail, we will
clarify some of the terms associated with real-time scheduling theory.
A task is a thread of execution performing a specific function. For example, a task could be a simple thread polling the serial port to check if any data has arrived. A real-time task can be classified as periodic or aperiodic depending on its arrival pattern or as soft or hard based on its deadline.
Tasks with regular arrival times are called periodic. A common use of periodic tasks is to process sensor data. For example, a temperature monitor of a nuclear reactor should be read periodically to detect any changes promptly. Tasks with irregular arrival times are aperiodic tasks and are used to handle the processing requirements of random events such as operator requests.
Each of the tasks must complete execution before some fixed time has elapsed since its request. This fixed time is known as the deadline of the task. If meeting a given task’s deadline is critical to the system’s operation the task is called a hard real-time task. If missing occasional deadlines of a particular task does not adversely affect the system’s performance it is a soft real-time task.
Overhead is defined as the time spent in the kernel performing a service on behalf of a specific task, such as invoking or terminating it. Blocking is the time for which a higher priority task is prevented from running because of priority inversion.
Thus, a scheduling algorithm chosen, must have minimal overhead and be able to handle the type of processes that are present in the system. Each embedded system has its own custom scheduling algorithm to handle events that occur in its environment.
2.4 Interrupt Handling
“An interrupt is a hardware mechanism used to inform the CPU that an asynchronous event has occurred”. When CPU recognizes an interrupt, it saves its context and jumps to a subroutine known as Interrupt Service Routine (ISR).Upon completion of the ISR the program returns to
· The background in the case of foreground/background system
· Interrupted task incase of a non-pre-emptive kernel
· The highest priority task that is ready to run incase of a preemptive kernel.
Each OS needs to disable interrupts from time to time to execute critical code that should not be interrupted. The number of lines of this code should be minimum and bound under all circumstances. ISR must not call any RTOS function that might get blocked. An ISR must not call any RTOS function that might cause RTOS to switch task states unless RTOS knows that an ISR and not a task is running.
A good RTOS should have shortest Interrupt latencies, interrupt responses and interrupt recovery times. The ISR processing time also must be kept to the minimum for the best real time response.
2.4.1 Process -Thread -Task model
A multi-tasking concept is essential if one wants to develop a good real time application. Indeed an application has to be capable of responding in a predictable way to multiple simultaneous external events arriving in uncontrolled way. If only one processor is used we have to introduce pseudo parallelism called multitasking. The application running on a system is subdivided into multiple tasks. In complex systems like UNIX, the system is considered to be consisting of different processes. Here the context in each process is very
heavy resulting in large switching times. This approach was changed due to:
1. Implementing multitasking approach, which is a requirement in complex distributed software, is too heavy in a process model.
2. Bringing Real-Time and non-Real-Time world together, which the POSIX standards were aiming at, is not easy using a process concept.
Thus, the concept of thread was brought in , which is like a light-weight process. A thread inherits the context of the process but uses only a subset of it so that switching between threads can be done quickly. Today in a Real-time environment a process is an application subdivided into tasks or threads.
2.4.1.1 Task &
Task is the basic building block of software written under an RTOS. Each task in RTOS is in one of the following three states.
1. Running: The microprocessor is executing the instruction that make up this task. In single processor systems only one task is running at a time.
2. Ready: means that some other task is running but this task has things that it could do if processor becomes available.
3. Blocked: this task has nothing to do right now even if microprocessor becomes available. Tasks get into this state because they are waiting for some external event.
For example a task that handles data coming from a network will have nothing to do when there is no data.
2.4.1.2 Tasks and Data
Each task has its own private data [includes register values, Program Counter and stack. All other data like global, static, initialized, un-initialised…etc is shared among the tasks. A situation like this can lead to many of shared data problems. If task1 calls a function ReadX for reading a shared data that is being modified by task2, there is a chance that data read by task1 is erroneous.
2.4.1.3 Task Synchronisation & Intertask Communication:
There are several tools available in RTOS to enable inter task communication and task synchronisation
Semaphores: Semaphores are intertask communication tools used to protect shared data resources. Tasks can call Take-Semaphore and Release-Semaphore functions. If one task has called Take-Semaphore and has not called the Release-Semaphore to release it, then any other task that calls Take-Semaphore will block until first task calls Release-Semaphore. Here, in
the function where task2 is modifying shared data X (Fig. 6), we can protect the shared data by taking the semaphore before modifying and releasing it only after that. Whenever task takes a semaphore it is potentially slowing the response of any other task that needs the same semaphore. Two types of semaphore namely binary semaphore and counting semaphore exist.
A counting semaphore is used when more than one task uses the same resource like in the case of a buffer pool management. Using a different semaphore for highest priority tasks ensures better response. Multiple semaphores can be used to protect different shared resources.
Semaphore can also act as a signaling device for synchronisation. For example , a task that formats printed reports builds those reports into a fixed memory buffer. After formatting one report into the buffer the task must wait until interrupt routine has finished printing. Here the task can wait for a semaphore after it has formatted a report. The interrupt routine on feeding the report to printer can release the semaphore. The task on receiving the semaphore formats the next report. When using Semaphores, one should ensure that it does not lead to
Priority inversion or Deadly embrace. Some RTOS have a method called
priority inheritance to tackle this problem.
Message Mailboxes: Messages are sent to a task using kernel services called message mailbox. Mailbox is basically a pointer size variable. Tasks or ISRs can deposit and receive messages (the pointer) through the mailbox. A task looking for a message from an empty mailbox is blocked and placed on waiting list for a time(time out specified by the task) or until a message is received. When a message is sent to the mail box, the highest priority task waiting for the message is given the message in priority-based mailbox or the first task to request the message is given the message in FIFO based mailbox.
Message Queues: is used to send one or more messages to a task. Basically Queue is an array of mailboxes. Tasks and ISRs can send and receive messages to the Queue through services provided by the kernel. Extraction of messages from a queue may follow FIFO or LIFO fashion. When a message is delivered to the queue either the highest priority task (Priority based) or the first task that requested the message (FIFO based) is given the message.
Event Flags: basically these are Boolean flags which tasks can set or reset that other tasks can wait for. Event flags are used in cases where a task has to synchronise with occurrence of multiple events. A task can be synchronized when any of the events have occurred as in disjunctive synchronisation (logical OR) or may be synchronized when all the events have occurred as in conjunctive synchronisation (logical AND) [3]. More than one task can wait for same event. RTOS can form groups of events and tasks can wait for any subset of events
in a group.
3. General Embedded OS Architectures
3.1 Monolithic Architecture
The operating system is written as the collection of procedures, each call call other whenever it needs. To construct the actual object program of the operating system when this approach is used, one first compiles all the individual procedures, and files containing the procedures, and then binds them all together into the single object file using the system linker. There is no concept of information hiding, any procedure can access the data of other procedure.
3.2 Layered Architecture
This approach is better the monolithic as system call ditectly goes to individual layer. As shown above the application programs can directly access hardware without using system calls. ROM BIOS and MS-DOS device drivers are used to intercept and excute system calls from the application programs.
3.3 Client Server Architecture
In this system, the kernel handles communication between clients and the servers. By splitting the operating system up into parts, each one of which handles only one facet of system such as file service,process service, terminal service or memory service, each part becomes small and manageable. All servers run in user mode and not in kernel mode due to which they don’t have direct access to the hardware.
4. OS for
4.1 Need for a New Operating System
Low-cost, hand-held devices, such as electronic organizers, cell phones and pagers, have relied on proprietary, microcontroller-based system software to achieve affordable price points and long battery life. The resulting devices are limited in software functionality, provide poor user interfaces and little or no connectivity to the desktop. On the high-end are full multi-window, device-independent operating systems for PDAs and Personal Communicators. While these operating systems facilitate graphical user interfaces, applications development, and robust functionality, they require system resources that prevent the creation of fast, low-power, low-cost devices. Furthermore, even these high-end systems are not designed from the ground up to provide seamless connectivity with desktop PCs. In addition, handling Network related issues in an embedded environment demanded an efficient operating system to handle such demands.
4.2 Symbian
4.2.1 What is Symbian?
Symbian OS is an operating system for
the latest generation of data enabled
mobile phones. As mobile phone
networks add IP data traffic to their
existing voice offerings, there is a
requirement to provide software that
can interpret that data in a way that
appeals to users. That data may be an
internet email message, a photo, an
instant messaging buddy list, or a
corporate price list – each user has
their own views about what data they
value. In order to provide the greatest
variety of data services Symbian OS is
designed to be flexible, rich and open,
while maintaining a low resource
requirement to keep the cost of the
phone itself as low as possible.
Symbian OS is a proven data enabled
mobile phone operating system. It is
already being used in a number of
released and announced products.
The operating
system is driven by the combined
needs of Symbian’s licensees who
together provide over three-quarters of the world’s mobile handsets.
4.2.2 Architectural features
From the software perspective Symbian OS
is a 32-bit, little endian operating system.
It has been ported to many ARM cores
with V4 instruction set or higher. In addition
to the CPU core, Symbian OS requires
an integrated memory management unit
(MMU), caches, access to the various privileged
execution modes, and interrupt and
exception handling logic. The CPU, MMU
and cache along with a number of peripherals
all reside on the system-on-chip.
These system-on-chips usually include a
DMA controller, timers, watch-dog timer,
interrupt controller, real-time clock,
UARTs, LCD controller, GPIO interface,
some internal SRAM, and other bus interfaces.
4.2.3 Architecture
· Base layer
Kernel and User library: The user library is the lowest-level usermode code, which offers library functions to user-mode code, and controlled access to the kernel. The main features are:
· process, thread, program and memory management
· error handling and cleanup framework
· descriptors: strings of characters and buffers of binary data
· container classes: arrays and lists
· active objects, for event-driven multi-tasking without requiring the overheads of multi-threading
· client-server architecture, for simple and efficient inter-process communication. The client-server architecture supports both thread-relative and process-relative client resource ownership. The latter is to ease porting of code written for other platforms to Symbian OS, and delivers considerably enhanced Java performance
· a hardware abstraction layer (HAL) presenting a consistent interface to hardware across all devices
Device Driver:
The Base subsystem provides device drivers and/or software controllers for the following devices:
· DTE serial port
· DCE serial port
· infrared
· HWA (Driver implementing the hardware acceleration API for managing DSP hardware)
· USB client
· PC Cards
· MultiMediaCards (including support for password protected cards)
· SD Memory Cards
· LCD
· Keyboard
· Digitizer
· Telephony layer
The Telephony subsystem provides a multimode API to its clients. The abstract cellular networks include GSM, GPRS, EDGE, CDMA (IS-95) and 3GPP2 cdma2000 1x (Release A) and is ready for 3GPP W-CDMA making it easier for handset manufacturers to port Symbian OS from one mobile phone standard to another. The multimode telephony abstraction is key in Symbian OS to providing integration with the rest of the operating system to enable creation of advanced data services.
· Security
The security subsystem enables data confidentiality, integrity and authentication by providing underlying support for secure communications protocols such as TLS/SSL, WTLS and IPSec. It also supports the authentication of installable software using digital signatures. Secutiry is provided through Cryptography module and certificate management module.
Cryptography module: The cryptography module includes the following significant components:
· cryptography algorithms allowing data to be encrypted and decrypted and supporting symmetric ciphers: DES, 3DES, RC2, RC4 and RC5, and asymmetric ciphers: RSA, DSA and DH
· hash functions: MD5, SHA1 and HMAC
· pseudo-random number generator for generating cryptographic keys
Certificate management module: The certificate management module is used for authentication of other entities (e.g. third-party developers,web servers) to the user of the phone, and for authentication of the user of the phone. It supports WTLS certificates (as per the WTLS specification version used for the December 2000 WAP Conformance Release) and X.509 certificates according to the PKIX Certificate Profile (RFC 2459). This module provides
· storage and retrieval of certificates using the cryptographic token framework
· assignment of trust status to a certificate on an application-by-application basis
· certificate chain construction and validation
· verification of trust of a certificate
· Communication Interface
It provides support for communication protocols like TCP/IP, ICMP, PPP, TAPI, UDP, IPSec, FTP etc. The Comms Infrastructure subsystem provides the key frameworks and system services for communications and networking. This includes:
· a communications database manager which controls the system-wide communications configuration
· a socket server and client-side API which provides a framework for implementing various communications protocols through a socket interface. Plug-in protocols are dynamically loaded.
· multi-homing support: multiple simultaneous OSI Level datalink interfaces, each with its own unique IP address. This is not limited to Primary PDP contexts but enables multiple access technologies to be provided such as WLAN, BNEP and Ethernet along with multiple PDP contexts
· a network interface manager which provides a framework for connection to other computers or networks. The manager provides a mechanism for the client to monitor progress over e.g., a PPP connection
· a serial communications server provides a serial port (RS232C) abstraction to allow Symbian OS phones to function as a DCE and a DTE as required. Dynamically loadable plug-in communications modules are used to actually communicate with device drivers and other protocol stacks.
· HTTP and WAP stacks
· Messaging
The messaging framework provides support for messaging protocols for sending and receiving of text messages (SMS), enhanced messages (
· Application Framework.
The Application framework subsystem provides a powerful environment for licensees and partners to create differentiated user interfaces while enabling applications written in C++ and Java, by Symbian, licensees, partners and third parties to run seamlessly on open Symbian OS phones. This subsystem is architecturally central to the support of graphical user interface (GUI) applications. It includes a number of system-wide plug-in mechanisms for instantiating components at run-time, powerful reusable libraries for data, graphics and text support.
· Multimedia
The Multimedia Framework (MMF) provides a lightweight, multi-threaded framework for handling multimedia data. The framework provides audio recording and playback, audio streaming and image related functionality. Support is provided for video recording, playback and streaming. The framework allows developers to write efficient and powerful plug-ins.
4.2.4 Memory Management
Symbian OS configures the MMU in a conventional two level arrangement, with
small 4 kB physical pages to provide efficient memory usage and large first-level
virtual pages of 1 MB for fast context switching. The MMU is essential in providing the virtual machine environment experienced by applications, and applying protection to an application’s data. Thus the MMU is a crucial component in the design of the protected mode system, which enhances the security and stability platform. Data and instruction caches are required to produce acceptable performance. Onchip timers provide the real-time clock for the system tick timer, and millisecond scale timers are needed for use with hardware drivers.
While some memory will be available on the chip most will be provided off chip.
This off chip memory has three major functions: storage of the Symbian OS
image; persistence of user data in a file system; and storage of processes data at run time. Careful consideration of the speed, cost and persistence of the data has to be considered when choosing the memory for each of these three functions.
One option is for the operating system image to be located in ROM. ROM memory technologies are cheap but cannot be reprogrammed. Any change to the software at a later date would have to be per-formed by providing a patch, and inserting thisinto the image by reorganizing the MMU.Flash is more versatile than ROM, allowing the image to be changed as a whole, but the cost is greater. Images can be placed in RAM and marked as read only by the MMU, this improves the access speed to data, however this increases both the amount of memory needed and the boot time as the image has to be copied from ROM to RAM. Flash is the most commonly adopted solution for the Operating system image for mobile phones.
4.2.4.1 Symbian OS image
The Symbian OS image is a compact collection
of executable code and various data
files. The image consists mainly of dynamically
linked libraries (DLL) and other
required data including configuration files,
bitmaps, fonts and other file resident
resources.
The core of the image code is intended to execute in place. However it can be beneficial to store parts of the image in a low cost flash memory which does not support execute in place. In that case, the DLLs can be loaded on demand. Due to the fact that libraries are typically shared between many different applications, from the same
virtual memory location (which ensures
memory is never wasted storing duplicates
of code), they must contain no writable
static data. The OS does however provide a
mechanism to allow a DLL to store a small
amount of data associated to a particular
thread.
also linked to DLLs by ordinal position of the functions within the DLL. This keeps
the size of the libraries down. It is key for library developers to maintain the function order within a DLL. Doing this is a key part of maintaining the binary compatibility of other software linked to a particular DLL on different devices running the same version of Symbian OS.
4.2.5 Hardware interfaces
At the heart of Symbian OS is a compact
pre-emptive multitasking micro-kernel
with very little dependence on peripherals. The core kernel executable, less than 200 kB, is fully multi-threaded. Peripheral hardware support is embedded into the image in several places to make the port-ing of Symbian OS to different phones modular.
The MMU is configured such that all hardware registers can only be accessed in a privileged mode. The kernel always executes in privileged mode and hence has access to all the hardware. Applications have a common interface to kernel services through an API provided by the user library. All applications run in an unprivileged mode, and hence any operation which requires hardware access has to proceed through one of two methods: a momentary switch into privileged mode while maintaining the context of the application; or a request made to the kernel server thread which involves a switch in context while the kernel is scheduled.
Essential peripheral hardware support is
included in the kernel library. These
peripherals, resident on the chip, are such
things as timers, DMA engines, interrupt
controllers and UART serial ports. The kernel
library is then specific to a particular
chip. No access to this hardware is directly
available to applications. Applications
always link to the user library whose functions
may invoke hardware control
through the kernel.
Peripherals associated with user input can be packaged as a separate DLL called a kernel extension. User input has simply to provide events that are consumed by the kernel. Hence different kernel extensions can be produced for keyboard, keypad, digitizer, and navigation button and wheels. The appropriate kernel extensions
are added into the image, where the kernel
detects their presence at boot time and initializes
them.
Device drivers provide a mechanism of
extending the user API so that applications
can access hardware services. Hardware that is manipulated through device drivers is not essential to the running of the OS. The driver can be loaded and unloaded at anytime. A device driver consists of two parts: a library to which applications can link providing thedevice’s API; and one or two libraries which run in privileged mode, kernel side, to access the hardware. The kernel side library is often split into two libraries: These are a logical device driver DLL which encapsulates the logical functions of a device e.g., on, off, read,
write, and a physical device DLL which
carries out the functions on a specific
device. This logical device contains all the
complexity of typical device usage usually
in the form of a state machine. The physical
device can then be replaced if the
choice of part is changed in prototyping a
phone or the progression of a product line.
An example of this is the device driver for
the audio codec – the media server uses a
standard application side API and logical
device driver so only a physical device
driver has to be provided for the particular
codec on the phone. The kernel side device drivers have to be
loaded by the application side before
access to the hardware can be obtained. The application side library uses a message
passing mechanism to communicate
to the hardware libraries through the kernel.
The devices can be used synchronously
or asynchronously. Asynchronous use of
device drivers is preferred wherever possible,
as it is more power efficient.
4.2.6 Interrupt handling
Interrupt handling within Symbian OS is a
key part of its software model. The operating
system performs some operations that
limit the functions that can be executed as
part of interrupt handling.
Rather than mask the interrupts from the
CPU during these operations the handling
of the interrupt is performed in several
stages, ensuring safe handling with minimal
latency.
When an interrupt signals the suspension
of execution the processor may be performing
a context switch between two
threads. This context switching and associated
adjustment of the MMU does not
allow the interrupt service routine (ISR) to
pass any data directly into an applications
address space. However data can be stored
temporarily on the kernel heap as the kernel’s
memory is never moved with the
MMU. In order to perform further processing a function can be identified that is deferred until the MMU is in a consistent state, after
the context switch has been made but before the runnable thread has been
resumed. This delayed function call (DFC)
can then copy any data into the applications
address space. A running DFC is
interruptible so the interrupt latency of the
phone is not extended.
There is a further complexity in that neither
an ISR nor a DFC can allocate any
memory on the heap of any thread. This is
because the ISR and DFC can run during a
user threads manipulation of the heap
(creating or destroying a new heap cell), so
data can only be copied into an already
allocated object.
4.2.7 Application support
Symbian OS is a multi-threaded operating
system. Applications can have one or
more threads, and it is these threads which
are scheduled by the kernel. Each thread
has memory set aside for its stack and
heap to use during execution.
All applications run in a virtual machine
(VM) environment that has two benefits.
Firstly the code can be fixed-up to find
data at known addresses during compilation,
saving memory as the library does
not have any relocation information associated
with it. Secondly if there are two
copies of the application running they can
execute the same code. The VM is made possible by use of the MMU to move data around in the virtualaddress space. An application consists of a single process, the unit of memory protection, in which one or more threads are running. When the application is loaded it is given pages for static data, and the thread data in the top page table of the two-level MMU. When a context switch occurs to this process then the kernel adjusting the MMU configuration moves
all the pages to a predefined location in
the virtual memory map. Then execution
can continue in the appropriate thread. When Symbian OS is running on the
ARMv5 (or earlier) architecture, the data
cache is virtually tagged and it has to be
flushed every time a context switch takes
place. Allowing certain system server data
to be fixed at a unique location reduces
this. These ‘fixed process’ servers must be
used often to gain a performance benefit. Some examples are the kernel server, file server, and window server, which are often called by applications. Hence if an application requests a service from, for example, the file server the context switch to the file server does not involve any change in
the MMU or a cache flush and if the original
application is returned to, the data in
the cache is still valid. When Symbian OS
runs on the ARMv6 architecture, physically
tagged caches remove this complication,
and consequently increase system
performance.
4.3 Palm OS
In 1996, a product called the PalmPilot was released by US Robotics. The Palm Pilot ran on an operating system made especially for that device, called the Palm OS.
The Palm Operating System (Palm OS) is the current leader in the PDA market,
accounting for 70% of the market share. The Palm Pilot (now known as just Palm), became one of the fastest growing computer platforms in history, reaching the million sold mark faster than the IBM PC or Apple's Macintosh.
Palm OS is the computer operating system that provides a software platform for the PalmPilot series of handheld personal digital assistants made by Palm Computing, now part of 3Com. Palm OS was designed from the beginning to fit into a palm-size device of a specific size and with a specific display size.
Palm OS uses multitasking, but only one task is for applications. The user uses one application at a time, one application program must finish before the next can be selected. This constraint allows the operating system to devote full attention to the application that is open. The space needed by the system for any application that is running is kept in dynamic, reusable random access memory.
The application and its related database are kept in what is called permanent storage, but here the permanent storage is RAM (rather than a hard disk) that cannot be reused as the dynamic RAM can. Palm OS divides an application into runnable code and different types of data elements, such as user interface elements and icons. The data elements can be easily changed without necessarily having to rewrite code.
Palm Computing chose not to include a keyboard in the PalmPilot in order to produce a truly palm-size device. Learning from Apple's
4.3.1 Physical Features of Palm
· Small Screen
· Quick Navigation
· HotSync with PC
· Touch Screen
· Quick Response Time
· Low Power Consumption
· Limited Memory
The Palm OS platform consists of five primary components:
· Palm OS software
· Reference hardware design
· HotSync conduit data synchronization technology for one-button synchronization
· Platform component tools including an API that enables developers to write applications
· Software interface capabilities to support hardware add-ons
4.3.2 Architecture of Palm PDA
Design Goals
On the hand-held side it is designed for :-
· Speed and efficiency: Provide nearly instantaneous response to user input while running on a Motorola 68000 type processor, requiring only 32K system memory.
· Low-cost and low-power: Provide months of battery life on 2 AAA batteries, utilizing standard, low-cost memory and processing components.
· Small form-factor devices: Facilitate the creation of pocket sized devices with user interface objects designed specifically for small displays; enable fast efficient data entry without the use of a keyboard.
· Integrated PC connectivity: Use record IDs, status flags and common data storage to facilitate communication and synchronization with desktop software.
· Standard application development: Facilitate application development in C or C++ using Metrowerks compilers and other common development tools.
On the PC side, it is designed for :-
· Efficient synchronization: Synchronize hand-held data with multiple PC data sources without user intervention.
· Extendability: Enable Independent Software Vendors (ISVs) to develop “conduits”, links between a wide range of desktop and hand-held applications.
· Communication independence: Insulate conduit developers from the communications protocols to facilitate synchronization via a variety of physical links.
· Standard conduit development: Under Windows, conduits are DLLs and are developed using standard C or visual basic tools.
Thus the Palm OS consists of two parts :-
1. Efficient Operating System running on the handheld PDA on Motorola Dragonball Processor
2. Windows or Macintosh based system software running on the PC to manage synchronization between the PC and PDA
4.3.3 Palm OS Device Architecture
4.3.4 Memory Management in PalmOS
The Palm OS memory manager facilitates fast access to system software, applications, and data, yet requires a minimum of nonvolatile, dynamic memory.
To enable the creation of devices with a limited amount of dynamic memory, the Palm OS data manager stores data in a database-like structure rather than a traditional file system. Traditional file systems require large amounts of memory because they first read all or a portion of a file into the memory buffer, then later write the updated memory buffer back to the disk or storage medium. Because of the latency involved with reading and writing to disk, data access is generally slower. For devices that store data in memory, it makes more sense to access
and update data directly in place.
The Palm OS uses a database model to store data. It works with small chunks of data, less than 64K each. The system stores each data record, such as an address book entry, as a chunk. Chunks can be scattered throughout the memory space and accessed in place. This storage method speeds data access by allowing the system to add, delete and modify records in place.
The system groups related records, such as appointments or address book entries, in databases, which replace the traditional file concept. For example, the system stores the collection of all address book records in a database. The Palm OS works like a traditional file system with a fraction of the overhead. Applications can create, open, delete and close databases as necessary, just as files on traditional systems are created, opened, deleted and closed.
The Palm OS data manager facilitates fast data access and sorting. Each database may contain one or more presorted index lists to facilitate fast sorting. For example, the Address book application stores index lists of records by name and by company. This enables the application to switch data views instantaneously between the two.
In addition to accessing data in place, the Palm OS executes applications in place out of ROM or RAM (see Figure 2). The efficient program execution results in instant switching between applications, and eliminates the need for a wait cursor.
4.3.5 Power Management
The Palm OS minimizes power consumption with efficient power management. It supports three modes of operation: sleep mode, idle mode, and running mode.
When there is no user activity for a number of minutes, or when the user hits the off key, the device enters sleep mode. In sleep mode, the device appears turned off: the display is blank, the digitizer is inactive, the main clock is stopped, and the processor is not powered. To awaken from sleep mode, the device must receive an interrupt signal from a hardware button.
When the device is on but has no user input to process, it enters idle mode. In idle mode, the main clock is running, the device appears to be on, and the processor clock is running but the processor is halted.
In sleep or idle mode, when the system detects user input, it enters running mode. In running mode, the processor executes instructions. The device stays in running mode only as long as it takes to process the user input, then returns to idle mode.
4.3.6 File Formats in Palm OS
Currently, there are three types of file formats that are commonly used in the Palm OS® platform:
· Palm query application (PQA)
· Palm resource (PRC)
Files with a .pdb or .pqa extension are record databases. Files with a .prc extension are resource databases.
Palm Database (PDB) Files
A PDB is a record database generally used to store data for an application. Records are used to store application data which can be sorted, and searched
Palm Resource (PRC) Files
A Palm resource file contains a different type of data (resources instead of records), but has an almost identical structure to a PDB file. Palm OS applications are resource databases. A Palm OS application contains code resources as well as user interface resource elements.
Palm Web Clipping Application (PQA) Files
A PQA is a PDB that contains world-wide web content. On the Palm device all PQAs are associated through the Launcher with the Web Clipping Application Viewer (Viewer) software. When a user opens a PQA file for viewing, the Applications Launcher starts the Viewer, which in turn displays the contents of the selected PQA.
| Primary Target Devices | PDAs | Smartphones |
| Current Versions | Palm OS 5.2 | Symbian OS 7 |
| CPU | Older versions targeted Motorola DragonBall family. Newer version targets ARM processors. | ARM processors |
| User Interface | | |
| User interactive I/O | Pen and keypad | Pen and keypad |
| User Interface | GUI with check box, radio button, list, scrollbar support. | GUI with check box, radio button, list, scrollbar support. |
| User Interface Support | PilRC and Constructor UI builder tools. | Layered UI framework. UIQ 2.1 for Symbian OS with theme support. |
| Languages/Code Support | | |
| Languages | Native: C and C++. JVM support. | Native: C++. JVM PersonalJava and JavaPhone technologies in OS 6 and higher. Java MIDP in OS 7. |
| Internationalization | Requires resource files. | Native Unicode support. |
| OS Application Specifications | | |
| Multitasking | Available only for system services, not applications. | Although designed for event-based time sharing on a single thread, it also supports multitasking and multithreading applications. Only one application at a time can have access to the UI. |
| Maximum Memory | 16MB, Moves up to 128MB in 5.2 | Hardware driven, theoretically as high as 2GB. |
| Memory Usage | Applications must share memory with the operating system in main, also called dynamic, RAM. Some RAM, Storage RAM, is set aside for storage. Flash memory and expansion card memory can only be used for storage. | Applications share RAM with operating system but has exclusive access to their allocated memory area. All RAM available for OS and applications. Flash and expansion card memory is used for storage. |
| Shared Libraries | Yes. | Yes, DLLs, polymorphic DLLs. |
| Connectivity | | |
| Network/Async | TCP, UDP with socket API, IrDA, serial, Bluetooth. | TCP, UDP, IPv4 & v6 with socket API, IrDA, serial, Bluetooth. |
| Network Services | HTTP, HTTPS, IPSec, SSL, SMS. | HTTP, HTTPS, IPSec, MMS, SSL, SMS. |
| Data Synchronization | HotSync, Conduit Development Kit. | Connectivity SDK, SyncML. |
5. Future
The operating system extends the functionality of the PC by providing
a means to link to and carry desktop data. It also extends the power
of the hand-held device by leveraging the functionality of the PC
applications to perform more powerful functions.
Palm OS conduits
will be developed for a wide range of desktop applications, including
group scheduling, e-mail, personal finance and database.
As the Palm OS becomes more widely accepted, a new breed of
devices will emerge. It will serve as the foundation for a wide range of
increasingly smaller devices, including smart phones and graphical
pagers. The Palm OS expands the opportunity for hand-held computing
and extends the usefulness of the desktop computer. It will also
enable network devices that can connect to the Internet for information
access. 4
Symbian OS has been designed from the ground up for small memory devices. It
has support for all the leading industry standards that will be essential for the current
and forthcoming generations of data
enabled mobile phones. The open platform
allows the installation of third party
software to further enhance the user experience
with these phones.
6. Conclusion
Real time Operating systems play a major role in the field of embedded systems
especially in handheld devices. Selectio n of a particular RTOS for an application can be made only after a thorough study of the features provided by the RTOS. Since IC memories are getting denser scaled down versions of general operating systems are able to compete with traditional Real Time Operating Systems for the embedded product market. Also as the handheld devices are getting more and more complex by embedding applications, there is need to develop RTOS according to device requirements.
7. Appendix
7.1 Glossary
OS(Operating system): The operating system organizes and controls the hardware and it is that piece of software that turns the collection of hardware blocks into a powerful computing tool.
Database: Database is the collection of records.
Record: Record is the collection of attributes
TO DOWN LOAD REPORT AND PPT
