OBJECTIVE The ultimate objective of this project is to develop the next generation Text to Speech software for regional Indian languages like Hindi and Bengali which is called Embedded Shruti. The keyword here is “next generation”. The desktop version of this software which was developed by MediaLab, IIT Kharagpur is called “Shruti”. This software is ported to Windows CE so that the software can be used on Embedded Devices like Handhelds, PDA, Pocket-PC and other devices which support Windows CE operating system. While porting software on Windows CE the key concern is to enhance the performance using the limited resources of Windows CE. Windows CE is an operating system with limited resources and a small Application Programming Interface compared to the Win32 operating system which has an extensive set of Application Programming Interface. There are several limitations on the embedded devices like limited main memory, slow processor and less disk space. These are the constraints that should be taken into account while porting any software for Windows CE platform. Several techniques are used to increase the performance of the software which will be explained in the thesis and the performance evaluation will show how the techniques have resulted in increase in efficiency of the software. This project is an important part of the MediaLab projects and it had extended the Text to Speech software to an evolving area of handheld computers.
INTRODUCTION In recent past the computing industry had seen a tremendous growth in the area of Handheld Systems. Handheld Systems also called as Personal Digital Assistants (PDAs) are gaining popularity. An important reason behind their increase in popularity is that they are mobile devices. People can carry the devices with themselves at any place and use them for their work. Another important reason is that the devices are relatively cheap compared to desktop computes or Laptops. This is because they have limited functionalities. The resources are limited. The disk space is less, processor speed is not very high and main memory is also very limited compared to the desktop computers or Laptops.
The most popular Personal Digital Assistants are the following:
There are two popular operating systems that were used in these Personal Digital Assistants. They are the following:
1. Windows CE (compact edition)
2. Palm OS (Palm operating system used for Palmtops)
Embedded Shruti is developed for Pocket-PC running Windows CE operating system. As the name suggests Windows CE or Windows Compact Edition is an operating system developed by Microsoft which is customized for Handheld Devices. It had a subset of Win32 Application Programming Interface and also had Microsoft Foundation Class support. Due to the MFC support it’s very easy for the programmers who are conversant with traditional windows programming to migrate to windows CE programming. There are some constraints which should be kept in mind while programming in Windows CE API but one who is familiar with Windows API can develop applications for Windows CE very fast.
With this brief introduction of underlying hardware (Pocket-PC) and the operating system (Windows CE) the rest of the chapter will introduce the technologies that were used in the design and implementation of Embedded Shruti.
2.1 Windows CE Overview
Microsoft® Windows® CE is an open, scalable, 32-bit operating system (OS) that is designed to meet the needs of a broad range of intelligent devices, from enterprise tools such as industrial controllers, communications hubs, and point-of-sale terminals to consumer products such as cameras, telephones, and home entertainment devices. A typical Windows CE-based embedded system is targeted for a specific use, often runs disconnected from other computers, and requires an operating system that has a small footprint and a built-in deterministic response to interrupts.
Windows CE offers the application developer the familiar environment of the Microsoft Win32® application programming interface (API), ActiveX controls, message queuing (MSMQ) and Component Object Model (COM) interfaces, Active Template Library (ATL), and the Microsoft Foundation Classes (MFC) Library. ActiveSync provides easy connectivity between the desktop and the embedded device, whether by serial connection, infrared port, or network cable. There is built-in support for multimedia (including DirectX), communications (TCP/IP, SNMP, TAPI, and more), and security. A variety of integrated applications, including Pocket Internet Explorer, Pocket Outlook, and Pocket Word expose objects that allow the developer to extend and customize the existing system, as well as extend the functionality of the application.
2.1.1 Important features of Windows CE 3.0
Windows CE 3.0 offers improved Windows compatibility, combined with hard real-time processing support. New kernel services, such as support for nested interrupts, better thread response, additional task priorities, and semaphores, let the operating system respond immediately to events and interrupts. These real-time features make Windows CE 3.0 ideally suited for industrial applications such as robotics, test and measurement devices, and programmable logic controllers.
With greater storage and file-handling capabilities, interprocess communications, and networking support, Windows CE 3.0 interoperates easily with desktop environments that are based on Microsoft Windows NT® and Microsoft Windows 2000, which makes it the optimal choice for an enterprise system that combines small mobile systems with high-performance desktops servers and workstations.
New hardware features for Windows CE 3.0 include:
Support for on-chip debugging.
The device I/O controls (IOCTL) function that allows a unique serial number on each device.
Multiple execute-in-place (XIP) regions.
184.108.40.206 Kernel Services
Thread response times have been improved in Windows CE 3.0 by the tightening of the upper bounds on scheduling latencies for high-priority Interrupt Service Threads (IST). This improvement in thread response allows developers to know specifically when the thread transitions occur, and aids them in creating new embedded applications by increasing the capabilities of monitoring and controlling hardware in Windows CE.
Shorter Interrupt Service Routine (ISR) latencies. Because the kernel uses the interrupt ID that is provided by the ISR to set the event that the IST is waiting on, a short ISR latency is essential for a real-time system.
Support for nested interrupts. Support has been added for nested interrupts, which allows interrupts at higher priority levels to be serviced immediately, instead of potentially waiting for a lower-priority ISR to complete.
Increased priority levels. Additional priority levels (a total of 256) allow users more flexibility in controlling the scheduling of embedded systems.
Support for semaphores. In addition to the currently supported mutexes and events, Windows CE has been expanded to support semaphores.
The ability to change the quantum of any thread in the system. This includes support for two APIs: CeSetThreadQuantum and CeGetThreadQuantum.
Kernel-level security. A new security model restricts access to system APIs that a rogue application could call to damage the platform. An OEM can specify whether modules and processes can run or not run and specify those that are fully trusted on a particular platform. Two new APIs allow software developers to retrieve the assigned trust level of a module or a process.
The size of the object store has been increased to 256 MB (from 16 MB in Windows CE version 2.1). Individual files now can be as large as 32 MB and a database volume can be as large as 256 MB.
The number of objects that can be kept in the object store has been increased from 216 (65,536) to 222 (4,194,304). Because the allowable number of objects exceeds the number of available object identifiers, freed object identifiers will be reused for new objects, effective with version 3.0. However, an object identifier will not be reused for at least 16 object allocations.
Support has been added for querying VERSIONINFO resources to obtain version and language-support information from files.
220.127.116.11 Interprocess Communications
Windows CE 3.0 provides interprocess communication support with COM and MSMQ.
Two separate COM modules offer two different levels of COM support: a limited-feature, small-footprint module that provides interprocess calls and a free-threading mode, and a larger module that supports out-of-process calls, full-threading model support, and Distributed Common Object Model (DCOM). The DCOM module, with the exception of the security interfaces, is fully compatible with Windows NT version 4.0 Service Pack 3 (SP3).
Enhanced MSMQ support in Windows CE 3.0 provides independent client support for messaging applications. MSMQ for Windows CE is compatible with Windows NT and Windows 2000 Message Queuing Services.
18.104.22.168 Communication Services
Communications enhancements to Windows CE include the following:
Lightweight remote access server (RAS) support. RAS uses Telephony Application Program Interface (TAPI) to make the call, and then manages the data through Point-to-point protocol (PPP) or Serial Line Interface Protocol (SLIP).
Windows 2000 Transport Control Protocol/Internet Protocol (TCP/IP) support.
Network Driver Interface Specification (NDIS) WAN support.
22.214.171.124 Communications Security
Security enhancements for Windows CE 3.0 include:
Microsoft Cryptography version 2.0 API (CAPI) subset. This is a set of encryption APIs that allow development of applications that will work securely over nonsecure networks, such as the Internet. The CAPI 2.0 subset will provide certificate management support.
Microsoft Enhanced Cryptography Service (RSAENH), including 128-bit encryption algorithms.
Cryptography Service Provider Development Kit.
X.509 certificate authentication.
126.96.36.199 Connectivity Services
Smart card PC/SC support. The Windows CE 3.0 smart-card subsystem conforms to the Interoperability Specification for ICCs and Personal Computer Systems, which makes it easy to port existing smart-card applications to Windows CE devices.
Windows CE 3.0 ActiveSync version 3.1.
188.8.131.52 User-Interface Services
Enhancements to shell services in Windows CE include the following:
Microsoft Windows CE Handheld PC (H/PC), Professional Edition shell, which includes the following applications:
Pocket Internet Explorer
Finer granularity componentization of common controls.
Ability to print mixed text and graphics.
Controls and dialog boxes that are resolution independent.
Ability for user to change the appearance of the user interface for notifications.
DirectDraw driver for Graphics Device Interface (GDI).
184.108.40.206 Internet Services
The new embedded Web Server provides many of the features of Microsoft Internet Information Services (IIS), which have been optimized for the limited resources of an embedded device. Features include:
Support for the HTTP/1.0 protocol, persistent connections, multiple connections, file downloading, directory browsing, and multiple virtual paths.
A remote administration tool for configuration.
Basic and NT LAN Manager (NTLM) authentication support.
Internet Services Application Program Interface (ISAPI) extensions and filters.
Dynamic pages, through a subset of Active Server Pages (ASP pages).
For client-side Internet development, Windows CE 3.0 includes a subset of the WinInet API, to support browser-based applications and FTP services.
2.1.2 Using Platform Builder The platform builder can be used to create customized embedded platforms. By default a number of embedded hardware platforms are available which includes embedded platforms for microprocessors like:
a) ARM processors.
b) MIPS processors.
c) SHX processors.
d) IntelX86 processors (Used for debugging the application on desktop environment).
Platform builder is essential for creating customized embedded platforms which are hardware specific and not compatible to the processors mentioned above.
Introduction to the platform builder will help to port the application to some customized embedded platforms in future. The steps to do the customized platform design are specified below:
Platform builder helps the programmer to create customized embedded platforms:
1. Using platform builder with the desktop based Windows CE emulator.
2. Using platform builder with a Windows CE PC based hardware development environment.
3. Creating and adding features to the platform thus made by the platform builder.
220.127.116.11 Designing Operating System elements
Using the platform builder one can do the following:
a) Create a boot loader.
b) Create a Board Support Package.
c) Create a custom shell.
d) Selecting a configuration for the platform.
To build a platform based on Windows CE operating system the following steps are to be done:
1. Create a platform using Windows CE configuration with a standard development board (SDB).
2. Customize the platform with additional project and catalog features
3. Build the Operating System image to a hardware platform (CEPC). Platform builder includes boot loaders and Board Support Packages for the CEPC and many other hardware development platforms.
4. After refining and debugging platform on hardware development platform, one can adapt it for custom target device.
5. Create a boot loader, OEM adaptation layer and board support package for the specific target device. OEM adaptation layer (OAL) is the layer between KERNEL and TARGET-PLATFORM FIRMWARE.
7. When the platform is complete export a Software Development Kit for the platform. Application developers can import that software development kit into development tools like eMbedded Visual C .
Platform creation is done using new platform wizard in which the following steps are done:
a) Select a board support package for the device.
b) Choose and Operating System configuration and variant.
c) Select the features for the platform.
After initial settings have been chosen, the new platform wizard sets up the environment with files that support operating system configuration that was selected. The features included in the platform depend on the operating system configuration which was chosen. There are 13 basic configurations included with Platform Builder and all of them are available from new platform wizard.
After the pictorial view of the whole process, an example of building Operating System image for a Thin Client will be provided.
Sequence of tasks in process of creating Windows CE based platform with Platform Builder:
18.104.22.168 Thin Client Example
Platform builder was used to generate Windows CE image for a HCL Win Bee 4000JS Thin Client which is having the following hardware details:
For the hardware description of the Thin Client given above a Windows CE image had been made and the first step was to choose an appropriate configuration. Platform builder provides two different configurations for Thin Clients which are the following:
Windows Thin Client – Minimal version of Microsoft Windows CE that includes Core Operating System and features necessary to support Microsoft terminal services.
Windows Thin Client with browser- This configuration supports the features of Windows Thin Client along with a browser.
Windows Thin Client configuration provides the starting point for remote desktop terminals, including those features necessary to support terminal services client. This configuration provides functionality for Remote Desktop Terminals through support for Microsoft Terminal Services client. It also has SNMP and local browser capabilities along with the possibility to adding additional Windows CE Operating System features.
After the appropriate configuration is selected for the Thin Client hardware is selected the next step is to select one or more available board support packages. Platform Builder supports a number of Board Support Packages.
22.214.171.124 Board Support Package
A board support package is a software package that contains:
1. Boot Loader
2. OEM Adaptation Layer (OAL)
3. Device drivers for standard development board (SDB) or Hardware Reference Platform
BSP is the main part of Microsoft Windows CE based platforms and contains source files and binary files.
The OEM adaptation layer (OAL) that links to Kernel image and supports:
Initializing and managing the hardware.
Set of configuration files.
Use of Boot Loader:
Used during development to download Operating System image.
Once created BSP can be reconfigured through environmental variables and .bib and .reg file can be modified to attain the reconfiguration.
Microsoft Platform Builder provides sample BSPs for many SDBs that are readily available in industry. By using the integrated BSP support, one can quickly evaluate the new Operating System features in Microsoft Windows CE.
1. Extensive infrastructure is provided for developing BSP for SDB made by the developer or hardware.
2. Offers support for developing drivers for the platform.
3. Focus on customizing, refining and developing additional Operating System features.
Platform Builder provides BSPs for ten SDBs that are readily available for purchase. At present Platform Builder supports 4 types of BSPs which are the following:
1. ARM BSPs
2. MIPS BSPs
3. SHX BSPs
4. x86 BSPs
There are several third party BSPs that are available. Windows CE supported Thin Clients are also available commercially [ref 1].
126.96.36.199 Creating an OEM Adaptation Layer (OAL)
An OEM adaptation layer is a layer of code that resides between the Microsoft Windows CE Kernel and the hardware of target device.
Physically OAL is linked with kernel libraries to create the kernel libraries to create the kernel executable files. It also facilitates communication between the Operating System and the target device. It includes code to handle the following:
Creating the OAL is one of the more complex tasks in the process of getting a Windows CE Operating System to run on a new hardware platform.
Easiest way to create an OAL:
1. Copy the OAL implementation from a working platform and then modify it to suit the specific requirements of the platform under consideration.
2. If a new OAL must be created from beginning (similar implementations are not there) then it’s more useful to approach the development process in stages.
Each stage adds a little more functionality than the previous one and provides a convenient separation point where new features can be fixed and validated.
Steps of creating a new OAL:
1. Preparing BSP files for building the kernel.
a) Put the necessary directories and files to build the OAL and kernel image in place.
b) config.bib will be created or modified in this step.
2. Creating a Base OAL
a) Initialize the platform at startup.
b) Enable the serial port for debugging.
c) Initialize the communication settings.
d) Goal is to provide basic system initialization code that will support further debugging and to ensure that basic initialization code is complete and consistent with target device.
3. Enhancing OAL functionalities:
a) Enhance the Interrupt Service Subroutines.
b) Manage clock and timers.
c) There are alternate debugging options for
2. Enable power management.
3. Provide platform information for applications.
Implement the remainder of platform support functions.
Ensure the fact that full Operating System boot is possible.
4. Completing an OAL: Implement any additional features that the developer want to add to it.
188.8.131.52 Creating a Boot loader
Boot loader is an integral part of Windows CE Operating System development process and in some cases part of the final product solution. Purpose of the boot loader is following:
Place the Operating System image into memory.
Jump to Operating system startup routine.
Boot loader can obtain the OS image in a number of different ways:
Cabled connection(such as Ethernet)
Through USB or serial port.
It can also load the Operating System from a local storage device such as compact flash, a hard disk or a disk-on-chip.
It may store the image in Random Access Memory or in a nonvolatile storage like
3. Storage device
Boot loader is typically used during the development process to save time. Rather than transferring the developmental image to the target device through a manual process such as flash programming, the boot loader allows the developers to quickly download the new development image to the target device.
In many final product solutions the boot loader is removed from the product and the Operating System image is stored on the device and bootstrapped by system-reset process.
But there are platforms that do not efficiently support this ability, such as X86 platforms or platforms that perform pre boot task.
Most common form of boot loader is one that downloads Operating System image over the Ethernet into a target device RAM and much documentation is available on that.