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"

1. Pocket-PC

2. Palmtop
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.

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 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.
  

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.
  

Windows CE 3.0 supports larger data storage systems, and larger files within those systems.

• 
  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 2¹⁶ (65,536) to 2²² (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.
  

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.
  

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.
  

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.
  

• 
  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.
  

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
    
  • 
    Pocket Inbox
    
  • 
    Pocket Word
    
  • 
    Help system
    
• 
  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).
  

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.
  

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.

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.

6. Rebuild the Operating System using new Board Support Package, download it into target device and debug platform.

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

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:


2.1.2.2 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:

1. 
   266 MHz National Geode Processor.
   
2. 
   On board VGA controller up to 4.0 MB shared VRAM.
   
3. 
   64 MB RAM upgradeable to 256 MB.
   
4. 
   16 MB flash memory.
   

Peripheral support:

1. 
   104 key PS/2 keyboard.
   
2. 
   PS/2 and serial mouse support.
   
3. 
   Audio : 16 bit stereo sound output
   
4. 
   Microphone output
   

Communications:

1. 
   TCP/IP with DHCP support.
   
2. 
   10/100 Mbps Ethernet Twisted pair (UTP RJ45) Interface.
   
3. 
   Full PPP(Point to Point Protocol) support
   

Server Operating System compatibility/support:

1. 
   Citrix Win-frame and other Citrix compatible Operating system.
   
2. 
   Windows NT server 4.0,Terminal Server Edition and Windows 2000 server family with CITRIX
   

Optional Support:

1. 
   Smart card reader
   
2. 
   ISDN support
   
3. 
   LCD Display
   
4. 
   USB ports
   
5. 
   ISA and PCI Expansion slots
   

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:

1. 
   Windows Thin Client – Minimal version of Microsoft Windows CE that includes Core Operating System and features necessary to support Microsoft terminal services.
   
2. 
   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.

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:

1. 
   Initializing and managing the hardware.
   
2. 
   Device drives.
   
3. 
   Boot loader.
   
4. 
   Set of configuration files.
   

1. 
   Used during development to download Operating System image.
   
2. 
   Once created BSP can be reconfigured through environmental variables and .bib and .reg file can be modified to attain the reconfiguration.
   

Interaction Diagram:

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].

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:

1. Interrupts

2. Timers

3. Power Management

4. Bus abstraction

5. Generic I/O control codes (IOCTL)

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.

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

1. Ethernet.

2. Enable power management.

3. Provide platform information for applications.

Goal:

1. 
   Implement the remainder of platform support functions.
   
2. 
   Ensure the fact that full Operating System boot is possible.
   

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:

1. 
   Place the Operating System image into memory.
   
2. 
   Jump to Operating system startup routine.
   
3. 
   Boot loader can obtain the OS image in a number of different ways:
   
   1. 
      Cabled connection(such as Ethernet)
      
   2. 
      Through USB or serial port.
      
   3. 
      It can also load the Operating System from a local storage device such as compact flash, a hard disk or a disk-on-chip.
      
   4. 
      It may store the image in Random Access Memory or in a nonvolatile storage like
      

2. EEPROM

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.