Intro To Embeddedwith Win Embed CE2 ND Ed

INTRODUCTION TO EMBEDDED SYSTEMS
USING WINDOWS EMBEDDED CE

SECOND EDITION
A Tutorial Approach with Laboratory Exercises for Windows Embedded CE 6.0 R2 and the eBox 4300 Embedded Computer
June 2008
James O. Hamblen School of Electrical and Computer Engineering Georgia Institute of Technology
Introduction to Embedded Systems using Windows Embedded CE
Copyright 2006 and 2008 Georgia Institute of Technology and James O. Hamblen Portions Copyright 2006 and 2008 Microsoft Corporation, reprinted with permission from Microsoft Corporation.
Contents licensed for non-commercial academic use for research and classroom/lab instruction.
The author and publisher of this book have used their best efforts in preparing this book. These efforts include the development, research, and testing of the theories and programs to determine their effectiveness. These example programs are provided for educational use only. The author and publisher make no warranty of any kind, expressed or implied, with regard to these programs or the documentation contained in this book. The author and publisher shall not be liable in any event for incidental or consequential damages in connection with, or arising out of, the furnishing, performance, or use of these programs
ActiveSync, ActiveX, Developer Studio, DirectX, Microsoft, MS-DOS, Visual Basic, Visual C++, Visual C#, Visual Studio, Win32, Windows, Windows NT, Windows XP, Windows Vista, and Windows Server are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. Other product and company names mentioned herein may be the trademarks of their respective owners. Microsoft Windows Embedded CE source code is reprinted with permission from Microsoft Corporation.
INTRODUCTION TO EMBEDDED SYSTEMS

USING WINDOWS EMBEDDED CE
S E C O N D E D I T I O N
Table of Contents
1 Introduction to Embedded Systems _____________________________ 18
1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9 Examples of Embedded Systems _______________________________________ 18 Real-Time Operating Systems _________________________________________ 21 Operating Systems for Embedded Systems _______________________________ 23 Processors and Software used in new Embedded System Designs ____________ 23 Introduction to the Embedded System Design Process _____________________ 28 Factors in the Pricing of Embedded Devices ______________________________ 29 Development of an Embedded Systems Design ____________________________ 30 Memory Technologies used in Embedded Devices _________________________ 32 For additional information: ___________________________________________ 33
1.10 Laboratory Exercises _________________________________________________ 33
2 Introduction to Embedded System I/O Architectures _______________ 36

2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 Example of a first generation microprocessor bus _________________________ 36 Building I/O interface hardware that attaches to a bus _____________________ 41 Software used to transfer data to I/O Ports _______________________________ 45 Example of a second generation microprocessor bus _______________________ 46 Software support for PCI devices _______________________________________ 50 Example of a third generation microprocessor bus ________________________ 50 An Example X86 Embedded System ____________________________________ 51 I/O Transfer Techniques ______________________________________________ 52 Program Driven I/O Transfers _________________________________________ 52
2.10 Interrupt Driven I/O Transfers ________________________________________ 53 2.11 Direct Memory Access (DMA) I/O Transfers _____________________________ 55
Introduction to Embedded Systems using Windows Embedded CE 2.12 OS support for Device Independent I/O & Files ___________________________ 56 2.13 Unicode and ASCII character encodings _________________________________ 57 2.14 For additional information: ___________________________________________ 58 2.15 Laboratory Exercises _________________________________________________ 58
3 I/O Interfacing Standards for External Devices ___________________ 64

3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 Parallel Printer Interface _____________________________________________ 64 Software support for the parallel printer port ____________________________ 65 RS-232C Serial I/O Interface __________________________________________ 65 Software support for serial communications ______________________________ 68 The PS/2 Keyboard and Mouse Interface ________________________________ 68 Software for the PS/2 Keyboard and Mouse Interface ______________________ 70 SPI Bus Interface ____________________________________________________ 70 I2C Bus Interface ____________________________________________________ 71 Software support for SPI and I2C devices ________________________________ 74
3.10 Analog Inputs and Outputs ____________________________________________ 74 3.11 The Universal Serial Bus (USB) ________________________________________ 75 3.12 Software support for USB devices ______________________________________ 77 3.13 Audio I/O Devices ___________________________________________________ 78 3.14 Interfacing to motors, relays and other high current devices ________________ 80 3.15 CAN and LIN Network Interfaces ______________________________________ 85 3.16 For Additional Information ___________________________________________ 88 3.17 Laboratory Exercises _________________________________________________ 89
4 Network Interface Standards __________________________________ 94

4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 Ethernet Terminology ________________________________________________ 94 Frame Types ________________________________________________________ 95 CSMA/CD over a Shared Medium Ethernet ______________________________ 96 Segmentation, Bridges, and Routers ____________________________________ 97 The TCP/IP Network Protocol _________________________________________ 98 Application Protocols_________________________________________________ 99 Transport Protocols _________________________________________________ 100 Network Communication Protocols ____________________________________ 100 Network Topology __________________________________________________ 100
4.10 Software support for Networking ______________________________________ 100 4.11 Wireless Networking Standards _______________________________________ 101
Introduction to Embedded Systems using Windows Embedde d CE
4.12 For Additional Information __________________________________________ 103 4.13 Laboratory Exercises ________________________________________________ 103
5 The eBox 4300 Embedded Computer System ____________________ 106

5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 Architecture of the eBox 4300 _________________________________________ 106 Booting the eBox ___________________________________________________ 110 Interfacing external hardware to the eBox ______________________________ 113 Interfacing external hardware using USB _______________________________ 113 Interfacing a USB Web Camera _______________________________________ 114 Interfacing external hardware using the Serial Port ______________________ 115 Low-cost Sensors for Embedded System Projects ________________________ 116 Using Servos for Embedded System Projects ____________________________ 119 Wireless support for the eBox _________________________________________ 120
5.10 Cell Phone Modems _________________________________________________ 120 5.11 Low-cost robot bases for the eBox _____________________________________ 121 5.12 Supplying power to the eBox in robots and mobile devices _________________ 123 5.13 Example Student Projects using the eBox _______________________________ 124 5.14 For Additional Information __________________________________________ 133 5.15 Laboratory Exercises ________________________________________________ 134
6 Architecture of a Real-Time Embedded OS - CE 6.0 R2 ___________ 136

6.1 6.3 6.4 6.5 6.6 6.7 6.8 6.9 6.11 User Applications ___________________________________________________ 138 Memory Architecture _______________________________________________ 141 Core operating system (OS) services ___________________________________ 147 File systems ________________________________________________________ 148 Graphics, Windowing, and Events Subsystem (GWES) ___________________ 150 Processes and Threads _______________________________________________ 150 Multitasking and Scheduling _________________________________________ 152 Real-Time Performance _____________________________________________ 155 Interprocess Communication _________________________________________ 160
6.10 Synchronization Primitives ___________________________________________ 157 6.12 Interrupt Processing ________________________________________________ 161 6.13 Device Drivers _____________________________________________________ 165 6.14 User Mode Drivers __________________________________________________ 166 6.15 The Registry _______________________________________________________ 168 6.17 Loader ____________________________________________________________ 172
Introduction to Embedded Systems using Windows Embedded CE 6.18 Power Management _________________________________________________ 173 6.19 OS Security Features ________________________________________________ 176 6.20 OS Networking Features _____________________________________________ 178 6.21 OS Wireless Networking Features _____________________________________ 182 6.22 The OS Build System and Platform Builder _____________________________ 183 6.23 Platform Builder Terminology ________________________________________ 184 6.24 Building a Run-time image ___________________________________________ 185 6.26 For Additional Information __________________________________________ 191
7 Building a customized CE Kernel _____________________________ 194

7.1 7.2 7.3 7.4 7.5 7.6 7.7 7.8 7.9 Videos & Virtual Labs: An introduction to the CE tools via the web _________ 194 Software Installation Instructions _____________________________________ 196 Tutorial I: Building a new OS kernel using the eBox BSP __________________ 200 Tutorial II: Downloading a new OS kernel to the eBox 4300 _______________ 216 Tutorial III: Creating, compiling, and debugging a C/C++ Subproject _______ 223 Tutorial IV: Creating a MyOS Release Build ____________________________ 229 Tutorial V: Generating a new SDK for use by application developers ________ 232 Tutorial VI: Creating and Building a C# Project _________________________ 236 Tutorial VII: Deploying new application code to the target device ___________ 241
7.10 Setting the Build Options for Standalone Operation ______________________ 251 7.11 For Additional Information __________________________________________ 252 7.12 Laboratory Exercises ________________________________________________ 252
8 Application Programming in CE ______________________________ 256

8.1 8.2 8.3 8.4 8.5 8.6 8.7 8.8 8.9 FileIO example program _____________________________________________ 256 SerialIO example program using OS File I/O Calls _______________________ 258 PortIO example program using the CE Device Driver Kit _________________ 261 Linking to other modules using the Projects sources file __________________ 265 ILASMIO example program using in-line X86 assembly code ______________ 267 Thread and synchronization event example program _____________________ 270 The Producer Consumer Problem _____________________________________ 274 AC97 example program using CE API audio functions ____________________ 280 A basic Windows application, the Hello World example ___________________ 281
8.10 Managed Code vs. Native Code _______________________________________ 285 8.11 The C# Hello World Example Program ________________________________ 286 8.12 The C# Serial Port Example Program __________________________________ 287
8.13 Calling C/C++ functions from C# ______________________________________ 288 8.14 For Additional Information __________________________________________ 289 8.15 Laboratory Exercises ________________________________________________ 289
9 Adding External I/O Devices and New Features _________________ 292

9.1 9.2 9.3 9.4 9.5 9.6 9.7 9.8 9.9 Phidget USB drivers and example programs ____________________________ 292 USB WebCam drivers and Camera test program ________________________ 296 Using the CEbased Web Server (HTTPD) _____________________________ 298 Adding Speech Synthesis and Recognition Technology ____________________ 300 Adding Cell Phone Radio Technology with a Modem _____________________ 302 Adding a small LCD touch panel display _______________________________ 310 Adding a GPS Receiver for Location Information ________________________ 313 Adding OCR Technology ____________________________________________ 318 Building a Mobile Robot Project using CE and the eBox __________________ 321
9.10 For Additional Information __________________________________________ 333 9.11 Laboratory Exercises ________________________________________________ 333
10 Introduction to I/O Device Drivers ____________________________ 338

10.1 The Stream Interface Model for Device Drivers __________________________ 339 10.2 ISR & IST Processing for Device Drivers _______________________________ 344 10.3 DMA operations in Device Drivers_____________________________________ 350 10.4 A simple example device driver for the eBox ____________________________ 351 10.5 Production Quality Drivers ___________________________________________ 361 10.6 Stream Interface Drivers for USB Devices ______________________________ 362 10.7 For Additional Information __________________________________________ 362 10.8 Laboratory Exercises ________________________________________________ 363
11 Advanced OS Topics________________________________________ 366

11.1 Porting the OS to a new device ________________________________________ 366 11.2 Developing a BSP for a new board design _______________________________ 367 11.3 Developing a Bootloader for a new device _______________________________ 368 11.4 Modifying the OEM Adaptation Layer _________________________________ 369 11.5 Hardware Debug Tools for Embedded Systems __________________________ 372 11.6 Moving a new OS image to the eBox for standalone booting ________________ 374 11.7 Tools for Testing ___________________________________________________ 376 11.8 Porting an Existing Application to a Different OS ________________________ 379 11.9 Safety-Critical Coding _______________________________________________ 380
Introduction to Embedded Systems using Windows Embedded CE 11.10 Licensing and IP issues for Embedded Systems __________________________ 382 11.11 For Additional Information __________________________________________ 383 11.12 Laboratory Exercises ________________________________________________ 383
Appendix A: Automatically running an Application _________________ 385 Appendix B: The Remote Display & Desktop Applications ____________ 388 Appendix C: Making a bootable USB drive for the eBox _____________ 392 Appendix D: Information on the CD-ROM Design Files _____________ 394 Appendix E: Common I/O connector pin assignments _______________ 395 Index _______________________________________________________ 397
Preface
Intended Audience The goal of these materials is to develop academic curriculum materials for students that can be used in undergraduate degree programs in Computer Science, Computer Engineering, and Electrical Engineering. Student laboratory assignments developed for these materials use Windows Embedded CE 6.0 R2, a commercial RTOS designed for embedded systems. Target devices include an ARM emulator and for this new second edition a newer low-cost X86 SOC computer, the eBox 4300. Phidgets USB-based I/O devices and sensors can also be used for projects needing additional I/O such as analog inputs and digital inputs and outputs. A wide variety of other interesting devices are also supported. At many schools, these materials would be appropriate for two undergraduate courses, Embedded Systems, and Senior Design Project. These are typically three hour credit classes. It is assumed students have had some prior coursework in programming in C or Java, digital hardware, introduction to computer architecture, and in some cases an introductory operating systems class. An Embedded Systems Design course has replaced the traditional microprocessor/microcontroller based design course at many schools. An embedded systems class is elective in most CS and EE degree programs, and typically is required in CmpE degree programs 1. These courses need to be continuously updated with newer technology that more accurately reflects current design practice and the technology used in new embedded products. The introductory operating systems classes typically include several OS case studies. The material in Chapter 6 on the Windows Embedded CE Architecture could be also be used to as one of these case studies as an example of a popular commercial RTOS used to develop embedded systems. Many students today also use an embedded computer board for their senior design project. These materials would also provide students an overview and
D. L. Maskell, and P. J . Grabau, , A multidisciplinary cooperative problem-based learning approach to embedded systems design, IEEE Transactions on Education, vol. 41, pp. 101-103, May 1998. J. W. Bruce, J. C. Harden, and R. B. Reese, Cooperative and progressive design experience for embedded systems, IEEE Transactions on Education, vol. 47, pp. 83- 92, Feb. 2004. M. Moallem, A laboratory testbed for embedded computer control, IEEE Transactions on Education, vol. 47, pp. 340- 347, Aug. 2004. S. Nooshabadi and J. Garside, Modernization of teaching in embedded systems design-an international collaborative project, IEEE Transactions on Education, vol. 49, pp. 254- 262, May 2006. S. Hussmann and D. Jensen, Crazy Car Race Contest: Multicourse Design Curricula in Embedded System Design , IEEE Transactions on Education, vol. 50, pp. 61 67, Feb. 2007. M. Grimheden and M. Trngren, What is embedded systems and how should it be taught?---results from a didactic analysis. ACM Trans. on Embedded Computing Sys. vol. 4, no. 3, pp.633-651, August 2005 K. G. Ricks, D. J. Jackson, and W. A. Stapleton, Incorporating embedded programming skills into an ECE curriculum. ACM SIGBED Review Special Issue on the Second Workshop on Embedded Systems Education (WESE 2006), vol. 4, no. 1, pp. 17-26, January 2007. R. E. Seviora, A curriculum for embedded system engineering. ACM Trans. on Embedded Computing Sys. vol. 4, no. 3, pp. 569-586, August 2005. J. K. Muppala, Experience with an Embedded Systems Software Course, ACM SIGBED Review Special Issue on the First Workshop on Embedded Systems Education (WESE 2005), vol. 2, no. 5, pp. 29-33, October P. Koopman, H. Choset, R. Gandhi, B. Krogh, D. Marculescu, P. Narasimhan, J. Paul, R. Rajkumar, D. Siewiorek, A. Smailagic, P. Steenkiste, D. Thomas, and C. Wang,. Undergraduate embedded system education at Carnegie Mellon. ACM Trans. on Embedded Computing Sys. vol. 4, no. 3, pp. 500528, August 2005. A. Sangiovanni-Vincentelli and A. Pinto, An overview of embedded system design education at Berkeley. ACM Trans. on Embedded Computing Sys. vol. 4, no. 3, pp. 472-499, August 2005.
1
10
tutorials on using Windows CE 6.0 R2 and the eBox computer for their design project. Topic Selection and Organization The text starts with an overview of the embedded system design process and the tools used to develop embedded systems in Chapter 12. Chapters 2-5 introduce the basic hardware design concepts needed to understand how software communicates to I/O devices in embedded systems. Several of the more commonly used I/O interface standards are described along with an overview of the eBox 4300 architecture. Chapters 6-11 introduce the Windows Embedded CE 6.0 operating system and include getting started tutorials on building a new OS kernel and applications development. These development tools run from the familiar Visual Studio IDE. Early tutorials can use the ARM emulator and then move to the eBox 4300 target hardware. A new OS can be generated on the PC-based development system and downloaded over the network to the eBox in just a few minutes. Next, source code and project files are provided for a number of application programs that utilize OS API calls to use different hardware features of the eBox and external I/O devices commonly found in embedded devices. Course Syllabus for a Semester-based Embedded Systems Course In a semester-based embedded systems class, there are typically around 45 fifty minute class meetings, several laboratory assignments, at least two major written tests, and in many cases, a design project. A student design project works well in an embedded systems class and makes the course more interesting to students. As an alternative to a written comprehensive final exam, many classes with design projects now have students give their final design project oral presentations during the final exam period. Technical presentations and team-based design skills are often required in industry or graduate school, so providing students with additional experience in this area can be just as worthwhile as a written final exam. If a design project is not included, additional time will be available for more in depth coverage of topics such as hardware design, programming languages, and additional OSrelated topics. Table P.1 shows a proposed schedule for a semester-based embedded systems design course with a final design project. A grading policy for such a semester-based embedded systems course could be setup as follows: Item Percentage of Grade Computer Lab Projects (5) 25% Test I - Hardware Related Topics 25% Test II - Software Related Topics 25% Team-based Design Project (End of Semester) 25% Final Exam Period - Design Project Presentations
2
J. Hamblen, Using a low-cost SoC Computer and a Commercial RTOS in an Embedded Systems Design Course, to appear in IEEE Transactions on Education, 2008.
11
Table P.1 A Lecture Schedule for a Semester-based Embedded Systems Class

Lecture 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 Topics Covered in Lecture Class Organization & Grading Polices Introduction to Embedded Systems What is an Embedded System? Introduction to Embedded Systems What is currently used? Introduction to Embedded System I/O Architectures A First Generation Bus & Attaching I/O interface hardware to a bus Laboratory Assignment #1 Understanding Computer Bus Signals A Second & Third Generation Bus Example: PCI & PCI Express Example Embedded System Bus Structure & I/O Hardware I/O Transfer Techniques and the Tradeoffs File system I/O using OS APIs and Common Character Encodings Laboratory Assignment #2 I/O Port Hardware Design I/O Interface Standards Parallel, Serial, PS/2, SPI, I2C I/O Interface Standards Analog , USB, Audio, Motors, CAN, LIN Network Interface Standards wired and wireless eBox 4300 Architecture and external I/O Hardware Options Overview of the Team-based Design Project & Design Project Movie Laboratory Assignment #3 A Bus I/O Cycle Simulation Review for Test I Test I Hardware for Embedded Systems Return Test I & go over solution & Submit Design Project Proposal CE RTOS Features and Architecture CE RTOS Features and Architecture - Continued Laboratory Assignment #4 OS Builds and Tools Tutorials CE Application Development in C/C++ CE GUI and C# Applications and CE I/O Device Applications CE I/O Device Applications - Continued Laboratory Assignment #5 Developing I/O Applications CE Device Driver Development & Example Serial Driver Code Advanced OS Topics (OAL & BSP, Porting Apps, Safe Coding) Review for Test II Test II Software for Embedded Systems Return Test II & go over test solution Design Project Proposal Initial Oral Presentations by Teams Work on Team-based Design Projects During Lectures 34 -43 Class meets in laboratory to work on design projects Weekly Status Report Due from each team Class meets in laboratory to work on design projects Class meets in laboratory to work on design projects Weekly Status Report Due from each team Class meets in laboratory to work on design projects Class meets in laboratory to work on design projects Weekly Status Report Due from each team Class meets in laboratory to work on design projects Review for Final Exam or Design Project Presentations & Demos Final Exam or Design Project Final Presentations by Teams Textbook Sections 1.1 1.3 1.31.8 Hwk 1.1-5 2.1 2.2 2.2 2.3 Ex. 2.4 or 2.5 2.4 2.4 - 2.7 2.82.11 Hwk 2.1-3 2.12 -2.14 Ex. 2.5 or 2.6 3.1 3.9 3.1015 Hwk 3.1-4 4.1 4.13 Hwk 4.1 5.1 5.13 5.12,Hwk 5.1 or 5.2 Ex. 2.6. or 2.2 Chapters 1-5 Chapters 1-5 Chapters 1-5 6.1 6.11 6.12 6.22 7.1-7.10 Ex 7.2 8.1 8.9 8.10-13, 9.1 2 9.3 9.9 One of Ex. 9.1-33 10.16 Hwk 10.1, 2 11.111.11 Chapters 6-11 Chapters 6-11 Chapters 6-11
Chapters 1-11 Chapters 1-11
12
Course Syllabus for a Quarter-based Embedded Systems Course In a quarter-based embedded systems class there are typically around thirty lectures, so adjustments must be made including fewer laboratory assignments, fewer lectures on more advanced course material, and a less complex final design project than in a semester long course. Table P.2 shows a proposed schedule for a quarter-based embedded systems design course.
Table P.2 A Lecture Schedule for a Quarter-based Embedded Systems Class

Lecture 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 Topics Covered in Lecture Class Organization & Grading Polices Introduction to Embedded Systems What is an Embedded System? Introduction to Embedded Systems What is currently used? Introduction to Embedded System I/O Architectures A First Generation Bus & Attaching I/O interface hardware to a bus Laboratory Assignment #1 Understanding Computer Bus Signals A Second & Third Generation Bus Example: PCI & PCI Express Example Embedded System Bus Structure & I/O Hardware I/O Transfer Techniques and the Tradeoffs File system I/O using OS APIs and Common Character Encodings Laboratory Assignment #2 I/O Port Hardware Design I/O Interface Standards Parallel, Serial, PS/2, SPI, I2C I/O Interface Standards Analog I/O, USB, Audio, Motors Network Interface Standards wired and wireless eBox 4300 Architecture and external I/O Hardware Options Laboratory Assignment #3 A Bus I/O Cycle Simulation Review for Test I Test I Hardware for Embedded Systems CE RTOS Features and Architecture CE RTOS Features and Architecture - Continued Laboratory Assignment #4 OS Builds and Tool Tutorials CE Application Development in C/C++ CE GUI and C# Applications and CE I/O Device Applications CE I/O Device Applications - Continued Laboratory Assignment #5 or Mini Design Project I/O Applications CE Device Driver Development & Example Serial Driver Code Review for Test II Test II Software for Embedded Systems Advanced OS Topics (OAL & BSP, Porting Apps, Safe Coding) Final Exam or Design Project Final Presentations Textbook Sections 1.1 1.3 1.3 1.8 Skip 1.6 2.12 Hwk 1.1-5 2.2 2.3 Ex. 2.4 or 2.5 2.4 2.4-5 Skip 2.6-2.7 2.811 Hwk 2.1-3 2.12 -2.14 Ex. 2.5 or 2.6 3.19 Hwk 3.1-4 3.10 14 Skip 3.15 4.1 4.13 Hwk 4.1 5.113 Skip 5.12 Ex. 2.6. or 2.2 Chapters 1-5 Chapters 1-5 6.1 6.11 6.12 6.22 7.3-7.10 Ex 7.2 8.1 8.9 Skip 8.7 8.10-13, 9.1 2 9.3 9.9 Skip 9.8 One of Ex. 9.1-33 10.1.5 Skip 10.4,6 Chapters 6-10 Chapters 6-10 11.1 11.11 Chapters 1-11
A simplified design project at the end of the course still works well and makes the course more interesting to students. The scope of the design project can be adjusted to reflect the time and equipment available in the laboratory. In a quarter-based course there is often insufficient time to order and obtain custom parts and devices unique to a specific student design project. One solution to this problem is to limit projects to parts and devices already available in the laboratory.
13
A typical grading policy for a quarter-based embedded systems course could be setup as follows: Item Percentage of Grade Computer Lab Projects (3 or 4) 25% Test I - Hardware Related Topics 20% Test II - Software Related Topics 20% Short Design Project (End of Quarter) 10% Final Exam 25%
Suggestions for Managing Design Projects For the final design project, students can be allowed to form their own teams of two to four students and select a project idea. It can also be organized so that the instructor assigns team members. In the instructor chooses to assign team members, an initial background survey of students is useful to make sure that each team has at least one person with some prior expertise in each area that will be needed for a successful project. Several weeks prior to starting development work, each team can be required submit a short one-page project proposal for instructor approval. This forces the students to start project planning work earlier and resolves problematic issues such as obtaining any special parts needed in time for the project. A thirty minute video of interesting student design project demos is available to show students to help motivate their early thinking about design project ideas 3. Based on the initial project proposal, the laboratory TA and instructor make recommendations to the students to adjust the project complexity to fit the time and number of people involved. Typically, feedback given to students on the project proposals will have roughly an equal number of recommendations to simplify the project, keep it as is, or do more work. While students are working on the projects, students can be required to submit a short one-page weekly progress report. This helps address many problematic issues with students starting project work too late. Similar status reports are often required in industry. Students can also be required to provide feedback on the contributions of other members in their team. As an alternative to a formal written project report, students can turn in a web site including documentation, source code, and videos of their project demonstrations. Final design project presentations can be given during the courses final exam period at many schools instead of a formal written final exam. Each team typically presents a ten to fifteen minute PowerPoint presentation. Live demos or videos are often included in the final design project presentations.
Download the thirty minute design project video at http://users.ece.gatech.edu/~hamblen/videos/Design_Projects_0023.wmv
14
Setting Up and Obtaining the Laboratory Equipment The number of development system PCs needed for the laboratory depends on the class size and structure. Around one PC per five to seven students is adequate in an open laboratory environment. If laboratory hours are strictly scheduled, a laboratory setup would be desirable for every two students in each laboratory section. To reduce the requirement for school provided laboratory PCs, students can also setup to work on PCs at home, if they checkout or purchase an eBox target system. Each PC will need a license for Windows Vista or XP, Visual Studio 2005, and the CE 6.0 tools, and an eBox target system. OS builds will take awhile, so a fast recent model PC is highly desirable. Software installation instructions are provided along with full details in Section 7.2. Installing the complete set of software takes several hours, so if identical laboratory machines are available, using a fast disk image copy software utility such as Ghost will save hours of setup and maintenance repair time for laboratory PCs. Even if a network server is not available for this purpose, a low-cost USB 2.0 external hard drive can be used and moved to each machine to install the disk image. Table P.3 Equipment Suggestions for a Typical Laboratory Setup
Description of Item Vendor and Model Approximate School Pricing US $1,000 US $225 US $125 US $17 to $65 US $40 US $60 to $90 US $165 US $60 US $100 to $500 US $250 US $45 US $80 US $32 to $120 For More Details Section 7.2 Section 5.1 Section 5.4, 9.1 Section 5.4,13 9.1 Section 5.9 Section 5.5, 9.2 Section 5.10, 9.5 Section 9.7 Section 5.11 Section 9.6 Section 5.6 Section 9.1 Section 3.14, 9.1
High-End PC Development Any recent fast PC running System, >1G M, >40G Disk Windows XP or Vista Target Device eBox 4300 X86 mini PC Optional Equipment to Support Student Design Projects LCD, ADC, Digital I/O USB Phidgets LCD 8/8/8 Analog Sensor Modules Phidgets Sensor Boards Internal WiFi Card w Ant. eBox mini PCI WiFi Card USB Web Camera Select Logitech QuickCam Cell Phone Modem Enfora GSM1218 Serial GPS Receiver GlobalSat BR-355 Robot Base for eBox iRobot Create or Stinger LCD VGA Touch Panel Xenarc 705TSV Microcontroller I/O Board Cypress PSoC CY3210 Kit RIFD reader Phidgets RFID Kit USB Motor and Servo Phidgets USB motor control Control Boards boards
A small assortment of Phidgets LCD 8/8/8 I/O boards, Phidgets sensor modules, Cypress PSoC boards, USB web cameras, cell phone modems, GPS receivers, robot bases, and LCD touch screens are useful to provide a wide array of options for interesting student projects. Since the Phidgets LCD modules are typically used in the suggested I/O laboratory assignment at least one per eBox setup is desirable. Fewer units of the other optional devices are needed since they are not used in every design project. Perhaps one for every two or three laboratory setups is adequate. Complete information on obtaining these external I/O devices, the device drivers, several code examples, and the
15
exact models required is provided in Chapters 5 and 9. Table P.3 contains a list of suggestions along with the approximate educational pricing for a typical laboratory setup. Software and Hardware Packages Windows Embedded CE 6.0 R2 is now available free to faculty and students under the MSDN Academic Alliance program and in a 180-day free trial version. Student members of the IEEE Computer Society can also obtain a free license. One other key consideration for schools and students is the cost of the embedded computer system. The current academic pricing for the eBox 4300 MSJK SoC embedded computer with CE preinstalled and a full set of cables is just a little more than current high-end academic textbooks. The other drivers used in the text for various I/O expansion devices are all available free of charge. Additional Web Material and Resources Updates to this material will be posted at the Microsoft Academic Alliance Curriculum Repository web site by searching for the title or author at: http://www.msdnaacr.net/curriculum/facetmain.aspx Links to other Microsoft resources for schools can be found at the Windows Embedded Academic Program (WEMAP) web site at: http://msdn.microsoft.com/embedded/community/wemap/default.aspx Information on obtaining academic discounts for the eBox 4300 MSJK embedded computer system can be found at: www.embeddedpc.net/academic Phidget USB I/O devices and sensor modules are available from Phidgets Inc: www.phidgets.com and www.phdigetsusa.com Information on other I/O devices supported on the eBox with CE 6.0 device drivers including web cameras, robot bases, GPS units, LCD touch screen displays, and cell phone modems can be found at the end of Chapter 5 and in Chapter 9. Example laboratory assignments, tests, student design project web sites, and other course materials from ECE 4180 Embedded Systems Design can be found on the class website at: www.ece.gatech.edu/~hamblen/4180
16
Acknowledgements This work was funded at the Georgia Institute of Technology in the School of Electrical and Computer Engineering under a research contract with Microsoft Corporation. GIT Contract 210663C and continued under 2106681, J. O. Hamblen, Principal Investigator. Scott Davis, Lindsay Kane, Mike Hall, and Sue Loh at Microsoft, Samuel Phung at ICOP, Jim Wilson, Tyson Hall, and David Jones have provided materials, software, hardware, helpful advice, and encouragement. Wallace Tennille, Yony Feng, Josh Beavers, and all of the students in the Embedded Systems Design class in 2006 through 2008 helped to develop, test, and improve these materials.
CHAPTER 1
Introduction to Embedded Systems
This TMIO ConnectIO Oven is an embedded system. It can refrigerate food prior to cooking it. It can be remotely controlled over the Internet or via a phone. It runs the Windows Embedded CE OS. Call it on the way home and your food will be ready when you arrive. Photograph courtesy of TMIO LLC.
18
1 Introduction to Embedded Systems

An Embedded system is any electronic device that incorporates a computer in its implementation. The user of an embedded device is often not even aware that a computer is present in the device. The computer is used primarily to provide flexibility and to simplify the system design. Unlike a PC, program code is usually stored in ROM and not a hard disk drive. Typically, the end user does not develop new software for the embedded device. With advances in VLSI technology, embedded systems have become so inexpensive that they are found in most of todays electronic devices.
1.1 Examples of Embedded Systems

A robot such as the Mars rover seen in Figure 1.1 is an embedded system. A cell phone, PDA, or portable multimedia player as seen in Figure 1.2 is an embedded device. Even the electric toothbrush seen in Figure 1.2 is an embedded system. A small microcontroller in the toothbrush provides programmable speed control and a battery state of charge indication. High end automobiles can contain nearly one hundred embedded microcontrollers. A typical middle class household has over fifty embedded devices. For every PC in the world there are over one hundred embedded devices. All told, embedded devices account for most of the worlds production of microprocessors.
Figure 1.1 Robots such as the Mars Rovers are Embedded Systems. Photograph courtesy of NASA/JPL CALTECH.
19
As seen in Table 1.1, embedded devices can be found in a wide array of products including aircraft and military systems, biomedical systems, cars, communications, computer I/O devices, electronic instrumentation, home electronics, industrial equipment, office machines, personal devices, robots, and smart toys. Embedded devices can be found everywhere. Embedded systems designers often face challenging design goals. Embedded systems must be reliable. Many e mbedded devices cant c rash, and may not be able to reboot. Software cant be updated in many embedded devices. Many devices have critical performance & power design constraints. Some devices may need to run on battery power for long periods of time. In addition, consumer devices typically have a fast time to market on new products and are very cost competitive. Real-time constraints occur in many applications and many devices have limited memory and processing power.
Figure 1.2 Cell phones, PDAs, and Multimedia Players are all embedded systems. Even this electric toothbrush! Photographs courtesy of Motorola, Microsoft, and Philips Sonicare.
20
Table 1.1 Examples of Embedded Systems Aircraft & Military Systems Biomedical Systems Cars Aircraft autopilots, avionics and navigation systems, automatic landing systems, guidance systems, engine controls. CAT scan and Ultrasound imaging systems, patient monitors, heart pacers. Engine control, anti-lock braking systems, traction control systems, air bag controls, heating and air conditioning controls, GPS mapping, Satellite Radio, On-board Diagnostics. Communication Satellites, network routers, switches, hubs. TVs, ovens, dishwashers, DVD players, stereos, security systems, lawn sprinkler controls, thermostats, cameras, clock radios, answering machines, set top boxes, other appliances. Keyboards, mice, printers, scanners, displays, modems, hard disk drives, DVD drives, graphics cards, USB devices. Data acquisition systems, oscilloscopes, voltmeters, signal generators, logic analyzers. Elevator controls, surveillance systems, robots, CNC machines, Programmable Logic Controllers, industrial automation and control systems. FAX machines, copiers, telephones, calculators, cash registers. Cell phones, portable MP3 players, Video players, Personal Digital Assistants (PDAs), electronic wrist watches, handheld video games, digital cameras, GPS systems. Industrial robots, autonomous vehicles, space exploration robots (i.e., Mars robots) Video Game systems, Aibo, "Furby, and Elmo type robot toys.
Communications Consumer Electronics
Computer I/O Devices Electronic Instrumentation Industrial Equipment Office Machines Personal Devices
Robots Toys
21
1.2 Real-Time Operating Systems

A real-time system must respond to external inputs and produce new outputs in a limited amount of time as seen in Figure 1.3. The response time needs to be bounded. Response times that are too long can cause real-time systems to fail. An illustrative example of a real-time system is the automobile airbag controller in your car. When the airbags motion sensors (accelerometers) detect a collision, the system needs to respond by deploying the airbag within 10ms or the system fails. At high speeds, with any delay longer than 10ms the driver will have already impacted the steering wheel before the airbag deploys.
External Input Event
Process New Data
Output Response to Event
System Response Time
Figure 1.3 A real-time system must respond to external inputs and produce new outputs in a limited amount of time or the system fails. Current response times are typically around 0.5 to 10ms.
In a soft Real-Time System, critical tasks get priority. A soft real-time system normally meets the real-time response constraint. A typical soft real-time example is a multimedia player. The player could occasionally skip a video frame or audio sample and a user might not even notice as long as it ran correctly the vast majority of the time. In a hard real-time system, a new output response must always be computed by the specified time bound or the system will fail. For a hard real-time example, consider a fly-by-wire (i.e., computer controlled) aircraft control system. In an aircraft flight control system when the pilot moves the control yoke, the flight control surfaces need to move very quickly in response or the aircraft would become unstable and crash. To insure safety, the Federal Aviation Agency (FAA) actually tests and certifies the real-time response of computer controlled flight simulators and aircraft. Virtual memory page swapping and garbage collection routines needed for object oriented languages can cause problems in hard real-time systems. Even caching is sometimes an issue since it can cause program execution times to vary. Many embedded systems are real-time systems with several inputs and outputs. Multiple events are occurring independently. Programming is simplified by
22
separating the tasks, but this requires the CPU to switch back and forth among the different tasks. An operating system that supports multitasking has features to time slice the CPU among multiple tasks. The OS also provides the synchronization primitives needed to coordinate activities among different tasks running in parallel. As an illustrative example, consider the internet and phone controlled oven described in the first page of this chapter. Example tasks for the oven would likely include at a minimum the following tasks: Control Oven Temperature (when cooking) Control Refrigeration Temperature (when cooling) Check for Keypad input and handle input Check cooking time to turn oven on/off (timed cooking) Update time and temperature LCD display on front panel Check for Internet communications and handle messages Check for Phone communications and handle messages
All of these tasks for the oven would need to be prioritized and scheduled. Recall that parallel tasks that share data require synchronization operations. Networking support is needed for the remote Internet and Phone control tasks. An OS would provide significant features in all of these areas that would help to greatly simplify and speed up the design and development of the device. Operating systems are often categorized by their real-time characteristics. A real-time operating system must be carefully designed in order to support realtime applications. A recent study concluded that 95% of real-time applications require a bounded response time in the range of 0.5 ms to 10 ms. Only a 10% variance (50 us to 1 ms jitter) in the response time can be tolerated. By these measures, most general purpose operating systems are not real-time. Using these measures, an embedded OS such as Windows Embedded CE qualifies as a real-time operating system (RTOS) 4. The Kernel code in an RTOS is written so that processor interrupts are only disabled for very short periods of time. The maximum interrupt response time (latency) is a key factor in the response time of an RTOS. A traditional desktop OS like Windows XP, Vista, or Linux can be considered only a soft real-time OS at best. Some third party tools and extensions are available at extra cost for Windows and Linux that improve the response times, but even these typically still have larger response times than an embedded RTOS that has been designed from the start to provide a fast hard real-time response.
Based on the definition and timing that was adopted by the Open, Modular, Architecture Control (OMAC) user group: A hard real-time system is a system that would fail if its timing requirements were not met; a soft real-time system can tolerate significant variations in the delivery of operating system services like interrupts, timers, and scheduling
23
1.3 Operating Systems for Embedded Systems

Most new devices have complex software that needs support for multitasking, synchronization of tasks, support for a wide range of I/O devices, scheduling and buffering of I/O operations, memory management, support for graphics displays, file systems, networking, security, and power management. An operating system can provide all of these features to aid application developers. Application programmers are more productive since they can work at a higher level of abstraction by using these features provided by the operating system. A recently released cell phone design contained over five million lines of code. Few, if any projects, will have the time and funding needed to develop all of this code entirely on their own. In cases such as this, it makes economic sense to use an existing operating system. The development time and costs saved more than pays for the licensing fees for the operating system. The typical commercial embedded OS license fees run only a few dollars per device. Some very simple low-end devices might not need an OS, but new devices are constantly getting more complex. For these reasons, most embedded devices use an embedded operating system. Embedded operating systems typically are developed largely in C/C++ and come bundled with a C/C++ compiler, assembler, and debugging tools to assist designers in developing application programs and testing the device. Embedded system development tools must also support program execution using code stored in non-volatile memory such as ROM or Flash memory.
1.4 Processors and Software used in new Embedded System Designs

Annual surveys of designers working on new embedded devices are conducted by several of the popular trade publications 5. It is interesting to examine the general trends uncovered by these surveys and see what types of new embedded systems are currently being developed. Figure 1.4 shows the bit size of processors currently being used in new embedded designs. Most current design activity appears to be centered around 32-bit processors. It is not surprising that given the continuing advances in VLSI technology, the trend has always been toward larger and more powerful processors in embedded devices. The program code and applications running on new embedded devices also continues to increase both in complexity and memory requirements.
Survey data is from the 2006 annual embedded market survey conducted by EETimes and Embedded Systems Design Magazine (www.embedded.com).
24
64-bit 32-bit 16-bit 8-bit 4-bit 0.00% 10.00% 20.00% 30.00% 40.00% 50.00% 60.00%
Figure 1.4 Processor bit size used in new embedded designs.
Figure 1.5 shows the annual 32 and 64-bit microprocessor sales data for 2002. ARM and X86 based processors have the largest market share followed by several other RISC processors, MIPS, SuperH, and PowerPC. Current data is believed to be similar, but is not publicly available. The ARM processor is a 32bit RISC low-power design from an English IP company, ARM ltd (Advanced RISC Machines) http://www.arm.com/. ARM does not make any processor chips, instead they produce their revenue by licensing the ARM IP processor designs to semiconductor manufacturers that produce their own version of an ARM processor. ARMs processor designs are licensed to over 100 chip manufacturers. ARM is used in many devices such as cell phones, the iPod Nano, Cameras, Handheld Games, HDTVs, and Set-Top boxes. 80% of ARM processors are in cell phones. A good performance/power ratio makes it a very popular choice in low power and battery operated devices. ARMs special thumb instruction subset is coded into 16-bits and decompressed on-the-fly to 32-bit instructions. It can switch from 16-bit to 32-bit instructions on the sub-routine level. This helps reduce memory costs in smaller devices.
25
ARM X86 MIPS SuperH PowerPC 0.00% 5.00% 10.00% 15.00% 20.00% 25.00% 30.00% 35.00% 40.00%
Figure 1.5 32 and 64-bit Annual Processor Sales Data for 2002.
The X86 processor family is based on the Intel 80X86 CISC instruction set used in processors in desktop PCs since the mid 1980s. X86-based processors have a fairly low cost due to their widespread use in PC technology. X86 processors and support chips are available from multiple vendors. A wide processor price/performance range is available in X86 devices. Most X86 processors for desktop PCs have been optimized for performance and not for low power.
1 Processor
2 Processors
3-5 Processors
More Than 5 0.00% 10.00% 20.00% 30.00% 40.00% 50.00% 60.00%
Figure 1.6 Number of Processors in each Embedded Device
The major desktop PC processor vendors (Intel, AMD) are moving on to newer designs and 64-bit architectures, but a number of other manufacturers are now making X86 processors for embedded devices. Intel recently re-entered the X86 embedded market with the new lower power X86-based Atom processor family.
26
Figure 1.6 shows the number of processors in each new embedded design. One or two processors are typical in new embedded product designs. Many current cell phones have both a general purpose processor and a DSP processor to handle the higher data rates needed for communication tasks and protocols. The processors used in embedded systems account for over 98 percent of the sales in the fifty billion dollar annual processor market.6
Commercial OS None Internally Developed Open Source 0.00% 5.00% 10.00%15.00%20.00%25.00%30.00%35.00%40.00%45.00%
Figure 1.7 Use of Real-Time OS Kernels in New Embedded Designs .
Figure 1.7 indicates that most new embedded devices have an operating system. In those devices with an operating system, the most popular choice is an offthe-shelf commercial operating system. Several studies and surveys have shown that the open-source OS option is staying about the same or even perhaps losing market share. One study indicated that the total product development cost can actually be higher for an open source OS when development time, salaries, and other license fees were included. One reason cited for this was the product maturity and development ease provided by the commercial operating systems currently available for embedded devices. Open Source licenses may also require that a manufacturer publicly release the source code for a device and many are hesitant to do so since their competitors could use it to develop similar products. In the commercial operating system survey responses, Microsoft Embedded has the largest market share in the 2006 survey seen in Figure 1.8. Microsoft Embedded consists of both Windows Embedded XP and Windows Embedded
D. J. Jackson and P. Caspi, Embedded systems education: future directions, initiatives, and cooperation, SIGBED Rev., vol. 2, no. 4, pp. 14, 2005 and J. Turley, The Two Percent Solution, Embedded Systems Programming, Dec. 2002.
27
CE. Next is the VxWorks OS from Wind River Systems. Symbian is an OS that is widely used in cell phones. Symbian is currently owned by Nokia.
Microsoft Emb. Wind River Symbian Green Hills Palm Others 0.00% 5.00% 10.00% 15.00% 20.00% 25.00% 30.00%
Figure 1.8 Commercial Operating Systems used in New Embedded Designs.
Figure 1.9 shows the response embedded designers gave to the questio n what languages do you use to develop embedded systems. The C family of languages is clearly used for the majority of embedded systems development. For assembly language, the response indicated that around one third of embedded systems designers still had to use assembly language for some small portion of their designs.
C C++ C# Java Assembly Others 0.00% 10.00% 20.00% 30.00% 40.00% 50.00% 60.00% 70.00%
Figure 1.9 Programming Languages used in Embedded Devices.
Note that the way this question was posed in the survey, this response does not mean that one-third of the code is written in assembly language. Rather it
28
means that one-third of the designers still need to use assembly language somewhere in their design. Other surveys indicate the amount of assembly language code to be somewhat less than five to ten percent of the code developed for new embedded devices. Even the PCs ROM BIOS code which is one of the last bastions of assembly language is currently being converted over to C by the major PC manufacturers. In conclusion, most new embedded devices use fairly powerful 32-bit processors. Most devices are complex enough that they require an operating system. In those devices that have an operating system, it is likely to be a commercial operating system. Most development work for embedded devices is currently done using the C family of languages. Assembly language may still be used in a few low-level routines on some devices, but its use continues to decline. Throughout the remainder of this document we will use Windows Embedded CE, one of the more popular commercial embedded real-time operating systems, as our case study for examples and for laboratory projects using the eBox X86-based embedded computer system.
1.5 Introduction to the Embedded System Design Process

The life cycle of an embedded product is seen in Figure 1.10. The initial conceptual design phase of a new product involves envisioning a product based on market forecasts, customer needs, and technology roadmaps. In product planning, a business case is made for the product with estimates for units sold, pricing, and margins. This results in an initial product mock-up, a design specification, and product marketing plans. Industrial designers may also be involved at this point in new product packaging concepts.
Design Phase
Design Concept Product Planning
Development Phase
Design Review Build Prototype Product Testing
Production Phase
Pilot Production Mass Production Technical Support
Figure 1.10 The Embedded device product life cycle phases, Design, Development, and Production.
Most hardware and software effort occurs at the end of the design phase and in the development phase. A design review helps to determine if it is physically possible to build the design concept given the design specifications. An electrical and software mock-up is often produced prior to the design review. A small number of prototypes are then designed, constructed, and used for more extensive hardware and software testing.
29
Finally, large quantities of the product are produced in the production phase. A small pilot production run is typically made first for further testing and evaluation before mass production starts. Quality engineers continually work to improve product and process quality. Sustaining engineers deal with the changes that follow after introduction of the new product and provide technical support for the product. Given the current globalization trends, mass production of the new embedded device often occurs in a different country where it is more cost effective. For many embedded devices, the entire process takes six months to a year, but competitive market forces are constantly reducing product life cycles.
1.6 Factors in the Pricing of Embedded Devices

Dont forget that a products sales price must recover the companys marketing, design, development and operating costs in addition to the per-unit manufacturing costs. It depends on the sales volume and the market, but a price level of three to four times the per-unit production cost is not uncommon.
33% Per-Unit Production Cost 42% Direct Costs Gross Margin Average Discount
10% 15%
Figure 1.11 Elements that contribute to the list price of a product.
Figure 1.11 shows a traditional pricing structure for a high-volume product in the computer and electronics industry 7. Per-unit production costs include the costs to purchase the components to assemble and test each device. The actual per-unit production cost typically accounts for around one-third of the list price. For unique and lower volume products, per-unit production costs can be significantly less than one third of the list price. Direct costs include the labor costs, warranty service, and yield losses in manufacturing.
7
This cost model is based on information originally presented in Computer Architecture: A Quantitative Approach, by John Hennessy and David Patterson, Morgan Kaufman Publishers 1996.
30
Gross margin is the companys overhead that cannot be billed directly to an individual product. Gross margin includes costs such as research and development (R&D), marketing, sales, cost of buildings and equipment, financing, taxes, and profits. Companies typically spend only five to ten percent of their income on R&D. Competitive and high-volume products typically are forced by the marketplace to have a lower gross margin. Average discount is typically a forty to fifty percent markup that is added for distributors, retail stores, volume discounts, and other sales costs. Stores and distributors also need to make money selling the product to stay in business. This cost varies depending on how the product is sold to end users. The Average Selling Price (ASP) is the price when the average discount or markup is removed from the list or retail price. The typical cost structure shown here is what has been historically required for a large to mid-size company to remain economically viable for a number of years through several generations of products. Outside consultants may be hired to help with a new design. Companies that provide consulting services only and that do not produce or directly sell a product also need to add a markup to their labor costs. The added cost of benefits (insurance, employer paid taxes, vacation time) and overhead (support staff, office space, equipment, taxes, and profits) usually is close to the salary cost for each employee, so they need to bill for consulting services at a rate at least double or even sometimes nearly triple the salary cost for an employee.
1.7 Development of an Embedded Systems Design

The primary focus of the software and engineering design effort occurs in the development phase which will be described now in more detail. Early on, the designers must select a processor and an operating system. The selection of a processor for an embedded device involves many considerations such as price, performance, power consumption, and software support. First, the processor must have adequate performance levels and memory to handle the tasks that will be required in the device. Prior experience with similar products often provides designers knowledge about the performance levels and memory needed. In new and unique devices, some initial analysis, simulation, and testing may be required to determine the processor speed and the memory required for proper operation of the device. The ever present desire to reduce cost, size, and power consumption, pushes designers to use slower processors that also consume less power, but they still need to be fast enough and have sufficient memory for the device to be able to function properly. Given that most embedded devices now require an operating system, the availability of an appropriate OS, device drivers, application programs, and the required compilers and software development tools are a major factor to consider in any new design, perhaps even more important than the processor choice. Most modern operating systems require a processor with a memory management unit (MMU) that provides hardware support for virtual memory
31
addressing and memory protection. In embedded devices, this allows the OS to run in a protected kernel memory address space and applications to run in a separate user memory address space. Virtual memory also helps the OS avoid memory fragmentation problems. The focus in this textbook will be on more complex embedded devices that require a processor with an MMU. Several embedded operating systems that have been targeted for the small MMU-less processors found in some of the simpler embedded devices are also available 8. They use only a single linear memory address space, do not provide hardware memory protection, and are therefore less secure. Commercial operating systems and commercial distributions of open source operating systems may have better OS development tools, a wider selection of device drivers, and an experienced consulting staff available to help with development. The real economic value of these services to the development effort should be considered carefully when selecting an embedded OS. The existing expertise of the products design team with the OS and processor family is also an important factor to consider. With any operating system, the costs and software development time can be minimized by carefully selecting a hardware platform with a processor and peripheral devices that has a mature supporting code base with all of the required device drivers. The natural desire or need to use new or faster hardware technology in a new product often comes into conflict with this principle. Manufacturers provide data manuals with their processors and typically provide designers with complete reference board designs that can be used as a starting point when developing a new computer design using their processor. In some cases, even the reference design schematic files for common CAD tools are provided. Complete details on each individual processor, memory device, and any required support chips are beyond the scope of this document, but some of the more common hardware features that directly impact software design will be examined later. After an embedded systems hardware designer has selected a processor and it s associated memory devices, the next step is to add the I/O hardware devices and the associated bus structures needed to interconnect to the required devices to the processor. Since processors are already designed by the manufacturer and memory interfaces are largely dictated by the processor, a significant portion of the hardware design effort in embedded devices is dedicated to selecting and connecting the hardware needed for the various I/O devices required in the new design. After carefully entering a complete electronic schematic for the design in a schematic capture tool, a printed circuit board (PCB) is designed for the embedded device using a PCB computer-aided design (CAD) tool. The PCB CAD tool imports the pin connection information from the schematic and uses it to route and verify the copper traces that are used to connect the integrated
8
Embedded Linux System Design and Development by P. Raghavan, Amol Lad, and Sriram Neelakandan, 2005.
32
circuits (ICs) on the PCB. Several PCBs are manufactured, stuffed with parts, and then used to run extensive software tests on the new design. Any hardware design errors detected during testing will require changes to the schematic, modification of the PCB design, and a new round of PCB fabrication and testing that will add to the development time. The software development tools are typically provided with the OS. Since the OS is written in C/C++, a compiler, linker, debugger, and binary image tools are needed to generate a new OS. These same tools are typically used for application development. Software development occurs in parallel with hardware development to reduce the total product development time. This has become more important given the ever shortening product life cycles of current embedded devices. Emulation tools and embedded computer boards with similar hardware running the same OS can be used to develop and test software before the new hardware platform is available. Since the majority of the code is written in C/C++/C#, a large portion of the software can even be developed and tested on a different processor or an emulator. Code is then recompiled to target a new processor for the final round of development and testing once the new hardware becomes available. In Windows Embedded CE, an ARM emulator is provided with the development tools, an X86 PC-based device (called a CEPC), or an embedded computer board (called a target device) can be used for initial software development and testing before the new hardware platform is available.
1.8 Memory Technologies used in Embedded Devices

Most embedded devices currently use two types of memory, SDRAM or occasionally perhaps SRAM for main memory and Flash or ROM memory for non-volatile storage as seen in Figure 1.12. SDRAM has a significantly lower cost per bit than SRAM, but requires a more complex hardware controller fo r periodic dynamic memory refresh cycles. One important decision that must be made early in the design process is how much memory of each type is needed for the device.
Processor
Main Memory
(SDRAM or SRAM)
Flash Memory
(non-volatile storage)
Figure 1.12 Most Embedded systems use two types of memory. SDRAM for main memory and Flash memory instead of a hard disk to store the OS and application programs.
33
The operating system and application programs are typically stored in flash, since most embedded devices do not have a hard disk drive. Hard disks have a higher failure rate, they require more space, and power, so they are not a viable option for many embedded designs especially in small mobile and battery operated devices. Flash memory read access times are significantly slower than SDRAM, so code is typically copied from Flash to SDRAM for faster execution. At power on, a boot loader in Flash loads the operating system. Flash memory supports only a finite number of write operations, so using a virtual memory system with continuous demand paging (like a desktop PC) with Flash memory (instead of a hard disk) serving as the virtual memory page swap drive is typically avoided in embedded devices. In such cases, virtual memory is still useful to provide each process a unique address space, reduce memory fragmentation, and to provide memory protection. Some embedded devices also use RAM memory for storage and maintain it in a low-power state when the device is not running using battery power. If the battery runs down completely, or a cold start is required this data will be lost.
1.9 For additional information:

Survey data is from the 2006 annual embedded market survey conducted by EETimes and Embedded Systems Design Magazine (www.embedded.com). Articles published throughout the year discuss the results of the annual survey and examine the implications and trends found in the data. The Total Cost of Development study is available at www.embeddedforecast.com. This study surveyed several embedded product development projects to compare costs when using Open Source versus a Commercial OS. The RTOS Evaluation Project report, RTOS State of the Art by M. Timmerman and L. Perneel compares three RTOS alternatives and is available at http://www.microsoft.com/windows/embedded/eval/wince/default.mspx . Check the web for more recent surveys and articles. Several other embedded market forecasts with data are also available, but many of these organizations charge a fee for their data and may require that it not be publicly released. The July 2006 Issue of IEEE Computer contains several articles on product life cycles and how globalization is changing the electronics and software industry.
1.10 Laboratory Exercises

1. List the embedded devices found in your home. 2. In a very competitive rapidly changing market (i.e., Cell Phones in Asia) a company needs to release a new product every three months. If it takes six months to develop each new product, how can they release a new product every three months? Explain.
34
3. A new superfast processor was just announced. Before selecting it for use in a new embedded design, what other factors should you consider carefully? 4. If a device is targeted to sell for $100 in a retail store, what would the per-unit parts and production cost need to be, assuming a cost model for the company as seen in Figure 1.11? 5. A designer is considering adding a new feature to a device that only requires an additional ten dollars in parts and assembly costs. Assuming the company has a typical business model as seen in Figure 1.11, how much would the retail price likely increase by when the new feature was added?
CHAPTER 2
Introduction to Embedded System I/O Architectures
A portion of the printed circuit board (PCB) artwork for an embedded system is seen above. Different line colors correspond to different copper layers on the PCB. The light yellow rectangles are the silkscreen that marks the locations where devices are soldered. Grayish white dots are mounting holes and feed through holes that connect to all layers. Photograph courtesy of Henrik Christophersen.
36
2 Introduction to Embedded System I/O Architectures

To understand how I/O hardware attaches to the processor and how software communicates with these I/O devices, I/O architectures that are similar to those found in current embedded devices will now be examined. Processors must transfer data to memory and input/output (I/O) devices over a bus as seen in Figure 2.1. A bus contains address information, the data value to transfer, and bus status information that indicates the operation being performed by the bus (i.e., read or write). Modern computer systems are more complex and they actually contain a hierarchy of busses of different types. Each bus used has a different set of costs and bandwidths. In general, higher bandwidth is more expensive. Some busses are often required to support legacy devices. To understand how memory and I/O devices are interfaced to the processor chip and how software communicates with I/O device hardware, you need to understand the basics of how this data is transferred on computer buses. We will briefly describe the operation of two common computer buses and then examine an example embedded computer systems bus architecture.
Processor
Memory
I/O Hardware
System Bus
Figure 2.1 A single bus architecture was used on early computers. Modern systems are more complex and actually contain a hierarchy of different busses.
2.1 Example of a first generation microprocessor bus

To understand how busses operate in a computer and how they are used in I/O hardware, we will start by examining a first generation microprocessor bus. The Industry Standard Architecture (ISA) bus was introduced on the first PCs by IBM in the early 1980s. The ISA bus was used to connect cards plugged into early generation PCs. ISA supports 8-bit and 16-bit data transfers. PC/104 is an industrial version of this bus that allows boards to be stacked and interconnected that is still used in some embedded systems. Later versions extended the ISA bus to a 32-bit bus called the Extended Industry Standard Architecture (EISA). The device that initiates a bus transfer is called a bus master or initiator. The ISA bus is used to transfer data between memory, I/O devices, and the
37
processor. A bus clock signal is used to provide a time reference for bus transfers. ISA bus clocks are typically in the 4 to 8 MHz range. The ISA bus clock is independent of the processor clock, they are not the same frequency. A typical ISA bus cycle requires 5 to 6 bus clocks. The ISA bus contains an address bus, a data bus, and several bus status lines. The address bus contains the address of the memory or I/O device selected, and the data bus contains the value to transfer. Each I/O device must have a unique I/O address. An address decoder circuit in each device checks the address bus and detects whenever the devices address is present on the bus. An example of a 4-bit address decoder build using an AND gate is shown in Figure 2.2. With digital logic gates, a simple address decoder consists of a large AND gate that has all of the address lines as inputs with invertors added on the address bits that are set low in the devices binary address value. A simple address decoder logic diagram for a 4-bit address (A3..A0) is shown below. The output of the AND gate will be high only when the address value 0xA is present at the inputs. An actual address decoder circuit would need to check all of the address bits on the address bus (unless some addresses are aliased). In a real device, more than 4 address bus lines must be decoded. 16 to 32 address lines are typical and multiple levels of gating would be required since most logic gate technologies can only support 4 to 5 inputs per logic gate.
A3 A2 A1 A0
Address Decoder Output
Figure 2.2 A simple address decoder circuit for a 4-bit address = 0xA
The four major bus status lines indicate the nature of the bus transfer cycle, memory read (MEMR), memory write (MEMW), I/O read (IOR), or I/O write (IOW). On the ISA bus, all of these bus status lines are active low ( i.e., the low signal indicates the type of transfer). Only one of these status signals would normally be active (i.e., low) at any given time. The ISA bus includes a number of other signal lines, but we will only discuss the major ones.
38
control 0 0 1 1
input output 0 High Z 1 High Z 0 0 1 1
tri-state control input
input
output
Figure 2.3 A tri-state buffer. Tri-state logic gate outputs must be used to drive most bus signals
Most modern bus signals are driven using tri-state logic devices. Recall that tristate logic has a third state that is high impedance (i.e., not connected) as seen in Figure 2.3. A tri-state buffer has an extra control line that makes it act just like a normal buffer or go to a high impedance (Z is used for impedance) state (i.e., disconnected). This allows multiple devices to drive the bus, but only one at a time. Only one device at a time ever turns on its tri-state control to force its outputs to drive the bus signals high or low. This is possible since each I/O device is assigned its own unique I/O address range that only it responds to. In this way, several tri-state gate outputs tied together perform the same logical function as a multiplexer (i.e, a multiple position switch), they connect one of several inputs to a single output. Inputs come from different devices and the output in this case is the bus. Two devices responding to the same address during a read operation would cause a bus conflict to occur with incorrect data bus values resulting. A design mistake or fault in a devices tri-state control logic can short out the data bus and crash the computer. Some older ISA boards have switches or jumpers that are used to assign the devices address and avoid address conflicts. This is often needed when several devices of the same type are used in a system. Early PCs had pre-assigned I/O address ranges for common I/O devices on an ISA bus as seen in Table 2.1. To save a few gates and a few chips on the address decoder circuits on ISA I/O boards, the designers of the early PCs only decoded the low 10-bits of the I/O address. With todays VLSI devices , a few gates are no longer a significant design concern, but this address assignment continues in todays PCs to ensure backwards hardware and software compatibility.
39
Table 2.1 Standard PC I/O Device Address Assignments. I/0 address range 000h - 00Fh 020h 021h 040h- 043h 060h- 063h 070h 071h 080h 083h 0A0h 0AFh 0C0h 0CFh 0E0h 0FFh 200h 207h 278h - 27Fh 2E8h - 2EFh 2F8h - 2FFh 378h - 37Fh 3B0h - 3BBh 3BCh - 3BFh 3C0h - 3CFh 3D0h - 3DFh 3E8h - 3EFh 3F0h - 3F7h 3F8h - 3FFh I/O device DMA controller Interrupt controller Timer Keyboard controller Real-time Clock DMA Page Register 2nd Interrupt controller 2nd DMA controller Reserved Game Adapter Parallel Printer (LPTx:) Serial Port 4 (COM4:) Serial Port 2 (COM2:) Parallel Printer (LPT1:) MDA Adapter Parallel Printer (LPTx:) VGA/EGA Adapter CGA Adapter Serial Port 3 (COM3:) Floppy Controller Serial Port 1 (COM1:)
Note: The early PCs only decoded the low 10 I/O address bits. So the IBM PCs I/O addresses ranged from 0 to 3FFH.
40
Bus Clock
Address
Valid Address
I/O Write
Data
Valid Data
Figure 2.4 An Example ISA Bus I/O Write Operation
An ISA write cycle is shown in Figure 2.4. First, the bus master (normally the processor) sends out the memory or I/O address on the system address (SAx) lines. After allowing around one bus clock cycle for the address decoder circuits to stabilize, the master device sends out the data on the system data (SDx) lines and sets I/O write (IOWR) status line low. The lines are all held steady for several bus clocks to allow for signal propagation and setup times. IOWR is then forced high, and the target device (normally an I/O device) saves the data bus value on the positive edge of the IOWR signal. The data bus value must be saved in the target device using a register since it is only present for a few clock cycles before another value appears on the data bus. Recall that registers can be built by using one D flip-flop per bit and connecting all the clock inputs together. The master device then releases both the address bus and data bus by turning off its tri-state drivers to setup for the next bus cycle. At the end of the bus cycle, the new data value has been saved in the target devices data output register for use by external I/O devices.
41
Bus Clock
Address
Valid Address
I/O Read
Data
Valid Data
Figure 2.5 An Example ISA Bus I/O Read Operation
An ISA read cycle is shown in Figure 2.5. First, the bus master (normally the processor) sends out the memory or I/O address on the system address (SAx) lines. After allowing around one bus clock cycle for the address decoder circuit to stabilize, the master device sets the I/O read (IOR) status line low. The target device sees its unique address on the address bus (using an address decoder circuit to check for its address) and seeing the IOR status signal indicating an I/O read cycle, it turns on its tri-state data bus drivers and sends out the data on the system data (SDx) lines. The lines are all held steady for several bus clocks to allow for signal propagation and setup times. IOR is then forced high, and the master device saves the data bus value. The master device then releases the address bus and target device releases the data bus by turning off their tri-state drivers to setup for the next bus cycle. Interrupts and DMA cycles can be requested by devices on the ISA bus using the Interrupt Request IRQx lines and the DMA request lines DRQx. A reset signal (RESET DRV) can be used to initialize devices at power-up reset.
2.2 Building I/O interface hardware that attaches to a bus

I/O device interfaces normally attach to a bus. The major building block used to interface I/O devices is an I/O port (also called an I/O register). An I/O input port transfers external data from the I/O device to the processor using the bus. An I/O output port transfers data from the processor to an external I/O device. Each I/O device is assigned a unique address and has an address decoder logic circuit that checks the bus for this address. The address value is sent out first,
42
so that the address decoder circuit has a stable valid output before the bus command lines activate the circuit.
Bus I/O Read Command Devices I/O Address Decoded Address Bus Address Decoder Circuit Data Bus bit x Tri-state Control Data bit x in from I/O Device One tri-state gate is needed for each bit on the data bus
Figure 2.6 Typical I/O Input Port Hardware Operation. A device turns on its tri-state drivers to drive the data bus with the I/O devices input data only when it decodes its address and a bus read operation occurs. The processor then saves the data bus value in a register.
The I/O input data is normally held stable in a register inside the I/O device. As seen in Figure 2.6, when the I/O input port interface hardware decodes its address on the bus and a bus I/O read operation is occurring, it places its data value on the bus by turning on its tri-state drivers to drive the data bus. Tri-state must be used since multiple devices share and can drive the data bus (only one at a time). ICs designed to attach to the bus, such as I/O port expanders, include the tri-state drivers and registers needed to interface to the data bus. Some busses (i.e., PCI) time multiplex address and data information using a single bus and would need to save address values in a register. A few busses still use an older alternative to tri-state outputs using special logic gates with open drain or open collector outputs. The PS/2 mouse and keyboard is one such example. In this type of bus, a special logic gate output can only drive the data signal low and a single external resistor weakly (and somewhat slowly by todays logic standards) forces it to the high state. This type of bus connection is sometimes called a wired-and or wired-or connection. With this type of output, there is not a potential bus conflict where two devices could try to drive the signal to a different logic state. Two standard output drivers in conflict (i.e., one high and one low) connected to a common signal line will cause an indeterminate logic level and a high current short condition.
43
Address Bus
Address Decoder Circuit
Data Bus
R e g i s t e r
Data out to I/O Device
Devices I/O Address Decoded Bus I/O Write Command
Clock
Figure 2.7 Typical I/O Output Port Hardware Operation . A device loads new data in the I/O ports output register only when it decodes its address and a bus write operation occurs.
An I/O output port transfers data from the processor to the I/O device using the bus. As seen in Figure 2.7, when the I/O output port interface hardware decodes its address on the bus and a bus I/O write operation is occurring, it clocks the data bus value into its I/O output register. The output data must be saved in a register since it is only present on the bus for a few clock cycles. Actual logic circuits are a bit more complicated than shown in these examples since some status signals may be active low on the bus and the data must be clocked into the register at the end of the I/O write signal (not the beginning) when the data is guaranteed to be valid for the setup and hold times on the register input. To minimize clock skew, instead of gating the clock input with an AND gate, a register with a clock (or load) enable input provides less clock skew and minimizes any possible flip-flop metastability problems (if an extra glitch occurs on the AND gate output, the flip-flop could see another phantom clock at the wrong time). With this approach, the I/O write command would serve as the clock and the decoder output as the clock enable. On the ISA bus, the logic must also check the bus signal AEN for a 0 to insure the device does not respond in error to DMA cycles (DMA activates more than one ISA bus status signal at a time). Some embedded devices may require their own custom I/O hardware devices. There are several options available. Instead of drawing gate level schemat ics, chip vendors and embedded systems designers typically design I/O hardware in CAD tools using a hardware description language (HDL) such as VHDL or Verilog. VHDL has syntax similar to Pascal or ADA and Verilog is similar to C. The HDL model is then synthesized to produce a net list. A net list is a textualbased description of a schematic. Automatic CAD tools can then use the netlist to place the hardware design in a custom VLSI device, an Application Specific
44
Integrated Circuit (ASIC), or a Field Programmable Logic Array (FPGA). Initial setup and mask costs for custom VLSI designs and ASICs are very high and a large sales volume is required to recover the high development costs. FPGAs are more appropriate for lower volume production, but they also consume more power and run slower. As an example of an HDL-based I/O hardware design, we will convert the earlier ISA input and output port hardware designs seen in Figure 2.3, 2.6, and 2.7 to VHDL. The address decoder described earlier just requires a check for equality in VHDL. On the ISA bus, AEN=1 indicates a DMA operation. In VHDL, the number of bits needed for each variable is specified when they are declared at the beginning of the program. The following code generates the address decoder for the ports: -- VHDL-based Address Decoder for 0x3E0 PORT_IO_DECODE <= '1' WHEN ADDRESS = X"3E0" AND AEN='0' ELSE '0'; In VHDL the assignment of a Z value to an output indicates a tri-state output. The tri-state buffers to attach to the 8-bit data bus and their associated control logic for an 8-bit input port as seen in Figure 2.6 can be generated using: -- VHDL-based I/O Input Port - use tri state buffers DATA <= PORT_DATA_IN WHEN PORT_IO_DECODE = '1' AND IOR = '0' ELSE "ZZZZZZZZ"; For registers in VHDL, a Process with a clock-edge sensitivity is needed. Registers will be built using positive edge triggered D flip-flops. The following code generates an 8-bit output port as seen in Figure 2.7: -- VHDL-based I/O Output Port use a register (with DFFs) PROCESS BEGIN -- clock on positive edge of ISA IOW WAIT UNTIL IOW'EVENT AND IOW='1'; -- use address decoder output for the DFF clock enable IF PORT_IO_DECODE = '1' THEN -- save data on ISA data bus in register PORT_DATA_OUT <= DATA; END IF; END PROCESS;
Using an HDL such as VHDL or Verilog with logic synthesis tools makes hardware designers more productive just as using a high level language makes
45
software designers more productive. I/O ports are typically 8, 16, or 32 bits wide. Most devices have one I/O port to transfer data and a second I/O port at an adjacent I/O address that is used for device status bits, handshake lines, and control signals. Many embedded computer boards provide extra I/O ports called general purpose I/O (GPIO) or sometimes called a parallel port for designers to use when adding their own custom I/O hardware. Other first generation microprocessor busses are similar. Several of the other interfaces to devices found in PCs still have signals similar to ISA since they were originally derived from it. Note that in the ISA bus cycle examples, it takes a minimum of 5 to 6 ISA bus clocks to transfer a single data value. As processors and memories became faster, the bandwidth of the ISA bus became a limiting factor. First memory was moved to a higher speed dedicated processor/memory bus. But high-speed network interfaces and graphics cards still needed more bus bandwidth than was available on the ISA bus. This led to a newer and faster second generation of busses for both PCs and embedded systems.
2.3 Software used to transfer data to I/O Ports

When an operating system is used, the low-level device driver code typically communicates with the I/O ports and user applications call these device drivers using OS APIs. To develop device driver code, most C/C++ compilers allow the use of in-line assembly language. Unfortunately, using assembly language means that your code will not port to a different processor. It also makes it more difficult for others to understand your code. On X86 processors, two special machine instructions must be used for transferring data to I/O ports. The IN instruction reads data in from an I/O port, and the OUT instruction writes data out to the I/O port. For these X86 instructions, the 16-bit I/O address register (DX) is one operand and an 8-bit register (AL) that holds the data value is the other operand. These are the only two instructions that will generate bus I/O read and write cycles. A C/C++ inline X86 assembly language example is shown in Figure 2.8. The keyword _asm indicates assembly language.
// X86 I/O Input Routine __asm{ mov dx,IO_address in al, dx mov IO_data,al }
// X86 I/O Output Routine __asm{ mov dx,IO_address mov al,IO_data out dx, al }
Figure 2.8 C/C++ in-line X86 assembly language instructions for I/O port input and output transfers.
46
On many processors, these I/O instructions are also privileged and can be trapped in hardware with a processor mode bit setting to prevent users from directly performing I/O instead of using OS API calls to perform I/O. The traditional Windows desktop operating systems use the mode bit to make I/O instructions privileged, but many embedded operating systems including Windows Embedded CE do not. Some RISC processors reserve a special address range in memory for I/O devices (memory mapped I/O) and then use regular Load and Store instructions to transfer data to I/O devices. Caching of memory mapped I/O port data must be disabled. C# does not allow in-line assembly language directly, but it can call C/C++ routines in a dynamic linked library (DLL) using a procedure called P/invoke. To develop device driver code, most C/C++ compilers have special function calls that can read and write I/O ports. In Windows Embedded CE using the CE Device Driver Kit (CEDDK), two such C functions are provided for 8-bit I/O ports. WRITE_PORT_UCHAR(I/O address, data ) writes a data value to an I/O port. READ_PORT_UCHAR (I/O address) returns the data value read from an I/O port. A CEDDK.h header file is needed in the source file and the code must be linked with CEDDK.lib . These function calls are normally found only in low-level I/O device drivers. Using this approach, code the will port easier to different processors and be easier for others to read and understand (especially those who do not understand the processors assembly language). C# does not have these functions, but it can call C/C++ functions that are defined in a *.dll library using the special [DLLIMPORT] P/invoke feature.
2.4 Example of a second generation microprocessor bus

As the bandwidth and memory address size limitations of the first generation buses like the ISA bus became apparent, several new bus standards were introduced. In the early 1990s Intel introduced the Peripheral Component Interconnect (PCI) bus. This bus became the most widely used standard and is now administered by the PCI Special Interest Group. PCI is a synchronous bus with all data transfers being relative to a PCI bus clock. Init ially PCI bus clocks were 33 MHz. Newer PCI-X systems can have clock rates of 66, 133, 266 and 533 MHz. The length, loading, and impedance of PCI bus signal lines needs to be carefully controlled to support these high clock rates. Only a few devices can be attached to a single PCI bus. PCI signals are even too fast to function correctly by wiring up devices on a student protoboard with long jumper wires. PCI supports both 5V and 3.3V logic levels. PCI 104 is a stackable board version of PCI used in some embedded devices. PCI uses a 32-bit multiplexed Address and Data bus, AD[31:0]. In a PCI bus cycle, during the first clock cycle the ADx lines contain the address, and in subsequent clock cycles the ADx lines contain data. This reduces the number of pins needed on connectors and lowers costs. This also means the target devices need a register to hold address and bus command values for the entire bus cycle and a state machine that knows which clock cycle it is (unlike the simple bus interface for ISA targets which only needed combinational logic (i.e., gates) ).
47
PCI also supports transfers of bursts of data. In a PCI burst, the starting address is sent out during the first clock cycle (address phase) and data is transferred from consecutive address locations (data phase) on each new clock cycle. The PCI frame signal (FRAME) signals a new address phase. Only one starting address is sent, so the target interface hardware needs to increment the saved address value. Data is transferred between an initiator and a target. The initiator drives the PCI command/byte enable (C/BE[3:0]) signals during the address phase to signal the type of transfer (memory read, memory write, I/O read, I/O write, etc.) as seen in Table 2.2. During the data phase, the C/BE[3:0] signals serve as byte enable to indicate which data bytes are valid. Both the initiator and target may insert wait states (add extra clocks to slow down) into a data transfer by deasserting the PCI initiator ready (IRDY) and target ready (TRDY) signals.
Table 2.2 PCI Bus Commands sent out on C/BE lines during the address phase
PCI Bus Command Interrupt Acknowledge Special Cycle I/O Read I/O Write Reserved Reserved Memory Read Memory Write Reserved Reserved Configuration Read Configuration Write Memory Read Multiple Dual Address Cycle Memory Read Line Memory Write and Invalidate
C/BE 0000 0001 0010 0011 0100 0101 0110 0111 1000 1001 1010 1011 1100 1101 1110 1111
48
0 Bus Clock

1 2 3 4 5 6 7 8
F rame #
AD
Address
Data1
Data2
Data3
C/BE#
Bus-Cmd
BE# s
IRDY#
TRDY#
DEVSEL#
Address Phase
Data Phase Bus Transaction
Data Phase
Data Phase
Figure 2.9 An Example PCI Bus Cycle doing a read burst operation
Clock Cycle 0 1
3 4 5 6 7 8
Description of PCI read operation Bus is idle The initiator sets FRAME low, places the address on the Address/Data (ADx) lines, and the bus command (read) on the Command/Byte Enable (C/BE) lines (address phase). The initiator tri-states the address and waits for the target to return a data value by turning on its tri-state drivers. Device Select (DEVSEL) low indicates a target device has decoded its address range and it is responding to the command. The target drives TRDY high to indicate the target needs another clock cycle to respond with the data.(data phase) The target drives the data value and sets target ready (TRDY) low to indicate that data is valid. When both IRDY and TRDY are low a data transfer occurs. The target sets TRDY high to indicate it need an additional clock cycle for the next data transfer. The second data transfer occurs when both TRDY and IRDY are low. The initiator saves the target data. The target drives the data value, but the initiator requests an additional clock cycle by setting IRDY high. The initiator sets IRDY low to complete the third data transfer. The initiator saves the target data value. The initiator drives FRAME high to end the data phase. All bus signals are tri-stated or driven to the inactive state.

0 Bus Clock 1 2 3 4 5 6 7 8
49
F rame #
AD
Address
Data1
Data2
Data3
C/BE#
Bus-Cmd
BE-1
BE-2
BE-3
IRDY#
TRDY#
DEVSEL#
Address Phase
Data Phase
Data Phase Bus Transaction
Data Phase
Figure 2.10 An Example PCI Bus Cycle doing a write burst operation
Clock Cycle 0 1 2
3 4 5 6 7 8
Description of PCI write operation Bus is idle The initiator sets FRAME low, places the address on the Address/Data (AD x) lines, and the bus command (write) on the Command/Byte Enable (C/BE) lines (address phase). The initiator places the data on the ADx lines and byte enables on C/BE lines, Device Select (DEVSEL) low indicates a target device has decoded its address range and it is responding to the command. When both IRDY and TRDY are low the target saves the data. (data phase) The initiator drives new data and byte enables. When both initiator ready IRDY and TRDY are low a data transfer occurs and the target saves the data. The initiator sets IRDY high and the target sets TRDY requesting an additional clock cycle. The initiator drives new data and byte enables and sets IRDY low. The initiator sets FRAME high indicating the final data transfer. The target drives the data value, but the initiator requests an additional clock cycle by setting IRDY high. The initiator sets IRDY low to complete the third data transfer. The target saves the data value. All bus signals are tri-stated or driven to the inactive state.
50
PCI timing for a burst cycle is often listed in a format such as 3-2-2-2. This means that the first data transfer takes 3 clocks (including the address phase) and the next three data transfers take 2 clocks each. The PCI bus also supports interrupts and DMA controllers (INTx, REQ, and GNT signals). The CardBus standard for small plug in modules is derived from PCI bus signals. Recently graphics cards began consuming most of the available PCI bus bandwidth, so they were moved to the new Accelerated Graphics Port (AGP). AGP is based on the PCI bus signals. Since AGP connects to only one device, a graphics card, it is technically a port and not a bus. AGP 2X, 4X, and 8X contain additional clock signals and clock phases that multiply the effective clock rate.
2.5 Software support for PCI devices

To support automatic hardware configuration, each PCI device contains a 256 byte configuration area. At power up, PCI devices can respond individually with manufacturer and device type information to help the operating system locate and load the correct device drivers. PCI devices that map into the memory and I/O address space can be programmed to respond to different base addresses and interrupts. This allows the operating system software to load drivers and assign addresses and interrupts automatically during power up. Enumeration is the term used to describe this process. This eliminates the need for manual jumpers and switches on each board. The operating system typically provides a driver that handles enumeration, but device drivers are still needed for each PCI device on the bus.
2.6 Example of a third generation microprocessor bus

PCI Express was recently introduced to provide even more bandwidth than PCI. Increasing bandwidth beyond PCI levels by making a large number of densely packed higher-speed parallel bus interconnect lines on current circuit boards was no longer possible, but it is possible with a newer generation of high-speed drivers when fewer lines are used and the length, loading, crosstalk, and termination of each line is carefully controlled. In PCI Express, a small number of high-speed serial lines are used to transfer the PCI bus signals. Data rates on the PCI Express high-speed serial lines range from 2.5 to 10 Gbps. For more bandwidth, several of the high-speed serial lines can be grouped together to connect a device (called lanes in PCI Express). Shift registers inside each devices PCI interface convert the signals from serial to parallel. Since PCI Express transfers the same PCI signals, the PCI software operation does not change. The new ExpressCard standard for small plug in modules is derived from PCI Express. PCI can support 5V and 3.3V logic levels. At about the same time, the PCI standard was also updated to support faster clock rates. A number of other chip-to-chip and board-to-board high-speed bus standards exist including AMDs HyperTransport, Freescales RapidIO, and Rambuss FlexIO. Many now use low voltage differential signals on bus signals. ARMs AMBA bus is somewhat similar to PCI.
51
Timing, bus length, loading (number of devices connected to bus), and termination are all critical on current microprocessor busses and the requirements need to be understood and examined in detail when designing new hardware and even when laying out the PCB traces for the bus. Many buses require an external resistor on each signal line for proper termination. Complete specifications of the bus standards can run several hundred pages and are available for hardware designers from various sources. A fully compliant PCI interface requires over ten thousand logic gates. PCI intellectual property (IP) core designs are also available from a number of vendors for hardware designers to incorporate in a new design.
2.7 An Example X86 Embedded System

Modern computer systems contain a hierarchy of busses. Each bus has a different set of bandwidth vs. cost tradeoffs. The processor and memory bus is the highest bandwidth bus and these connections can only be a couple inches long with a few memory devices. A bus bridge is used to connect signals from one type of bus to another. Most systems have one or more bridges to convert signals from the processor pins to the busses that contain I/O devices.
Figure 2.11 Vortex86-based Embedded PC Hardware Block Diagram. Image courtesy of ICOP.
A typical PC compatible hardware system built for embedded devices using the Vortex86 System-on-a-chip (SoC) is shown in Fig. 2.11. The eBox 2300 uses the Vortex86 SoC and contains a subset of this hardware. Note that the single Vortex86 SoC chip contains the X86 processor along with the two main bridge
52
chips (North Bridge and South Bridge) that are found on PCs that have both a PCI and an ISA bus. The traditional North Bridge connects to the processor pins and provides the memory bus to connect to SDRAM and a PCI bus. The Ethernet network controller chips connect to the PCI bus. The traditional South Bridge also connects to the PCI bus and provides the Low Pin Count (LPC) bus, the BIOS ROM interface, and several other PC I/O interfaces. The Low Pin Count (LPC) motherboard-only bus generated by the South Bridge requires fewer chip pins than ISA and uses a 33 MHz clock, but operates similar to ISA in software. Slower legacy devices connect to the South Bridge chip. The SuperIO chip provides a PC compatible floppy disk, printer, and serial port interface. The ISA bridge chip provides the ISA bus signals for the PC/104 connector.
2.8 I/O Transfer Techniques

Most I/O devices are orders of magnitude slower than a processor. An I/O devices handshake lines must be used to synchronize each I/O data transfer. Each I/O device sets a hardware handshake line (i.e., input ready, output ready) when it is ready to transfer data. Before any new data transfer on the devices I/O data port, the processor or other hardware must check that the I/O device is ready by reading and checking the devices handshake line. Handshake line bits are normally connected to another I/O port called a status port. Typically the devices status port has the next I/O address after the I/O data port (this also saves address decoder hardware since it can be shared for several consecutive addresses). There are three main approaches used to transfer data to I/O devices. They are programmed I/O (also called polling or software driven I/O), interrupt driven I/O, and direct memory access (DMA). Each has a slightly different set of hardware/software tradeoffs and requirements.
2.9 Program Driven I/O Transfers

In programmed I/O, the processor must read and check the I/O ready bits for the proper value before any data transfer. This requires reading in the status port, masking off the ready bit with the bitwise AND ( & in C) operation, checking for correct value on the ready bit, and looping back and repeating the operations until the device is ready as seen in Figure 2.12. // loop until output ready=1 do { status = read_IO_port(status_port_IO_address); output_ready = status & 0x01; } while (output_ready == 0); // ready, so output new data value write_IO_port(data_port_IO_address, data_value);
Figure 2.12 Pseudo code for a programmed I/O output routine. Program code must loop constantly reading the status port and waiting for the output ready bit, before outputting a new data value.
53
When the device is ready, the processor then inputs or outputs data value to I/O device. When the processor reads or writes the data port, the handshake line is usually reset in hardware. This approach is normally limited to simple systems with just a few I/O devices since there is significant processor overhead in having the processor continuously loop checking all of the I/O device ready bits in software. In many cases, this also prevents the processor from entering into power saving modes, an important consideration for battery operated devices. In a multitasking OS, other techniques are normally used for I/O that require less processor overhead and free up processor time to run other processes.
2.10 Interrupt Driven I/O Transfers

For interrupt driven I/O, the I/O ready signals are used to generate a hardware interrupt signal. An interrupt signal normally stops the processor at the next instruction (assuming interrupts are enabled) and the processor calls an interrupt service routine (ISR). The ISR then handles the interrupt and returns as seen in Figure 2.13.
1. Currently Running Process is Interrupted . Mov Add .. . . .. . .. .. . . 2. ISR Code executes Mov.. Out.. . Reti 4. ISR Returns 3. IST Launched (Optional) . .. .. .. . .. .
Figure 2.13 When an interrupt occurs, after the current instruction finishes execution, control transfers to the appropriate interrupt service routine (ISR). The ISR then performs the necessary I/O operations to clear the interrupt and transfer the data. The ISR returns control back to the next instruction in the interrupted process when it completes. To reduce interrupt latency, some ISRs may launch an interrupt service thread (IST) just before returning to complete some of the tasks later.
54
Using interrupts eliminates the processor I/O ready wait loops that are needed in programmed I/O. The interrupt service routine transfers the data, clears the interrupt signal, and returns. Interrupt routines must initially save all registers on the stack, process the interrupt, restore the register values from the stack, and then return to the code that was interrupted using the interrupt return address stored on the stack. In this way, ISRs are somewhat like subroutines in that they save data on the stack and use a return address from the stack, but they are invoked by the hardware interrupt signal and not a call in software. Special hardware called an interrupt controller is provided to enable/disable and prioritize multiple interrupt signals. Many processors have a vectored interrupt system. With vectored interrupts, each different hardware interrupt signal line jumps to a different ISR address. When an interrupt occurs, X86 processors perform a table lookup of ISR addresses in low memory and then directly jump to the ISR. Lower number interrupts typically have a higher priority (they can even interrupt a higher number interrupts ISR). By ass igning faster devices to lower number interrupts it is possible to give faster I/O devices priority. Interrupt signals can be shared with more than one device, but in this case the ISR will need to check status bit to determine which I/O device needs to be serviced. Some critical code sections (called non-reentrant) might require that interrupts be disabled. Most processors have an enable and disable interrupt machine instruction. The interrupt latency time is set by longest instruction or longest block of code that disables interrupts. An RTOS is designed to minimize this time. The length of time to execute the ISR is also critical. In many cases, the ISR saves the data, resets the interrupt request signal, and returns right after starting an interrupt service thread (IST) that runs later to complete the operation. The ISR execution time determines the maximum time to respond to an interrupt and is critical to minimize in real-time systems. Interrupts must occur at a slower rate (on average) than the ISR service time. Interrupts that occur faster than this rate can be lost or they can cause stack overflows, if they repeatedly occur at too fast of a rate. Interrupt controller hardware is needed to set interrupt priorities and enable/disable each interrupt signal. Additional bus signals are also needed for interrupts. On the ISA bus the IRQx lines and the PCI bus the INTx lines are used for interrupt signals. For security, the OS must control all interrupt hardware, the interrupt vector table, and the ISRs. Many I/O device drivers are interrupt driven. Most C/C++ compilers have special functions to setup ISRs within the OS. They automatically save all registers and correctly return using the interrupt return address at the end of the ISR. Another function is typically available to register the ISR with the system and setup any ISR address tables needed to service the interrupt and jump to the ISR. ISR routines can normally only use a small restricted subset of the OS API calls. C function calls to enable and disable interrupts are typically provided.
55
2.11 Direct Memory Access (DMA) I/O Transfers

A direct memory access (DMA) controller is a special hardware unit that transfers blocks of data directly to/from memory and the I/O device. A DMA controller requires a state machine with an address pointer and a counter. A DMA controller functions as a bus master. Like the processor, it can serve as a bus master and initiate bus cycles. The DMA controller hardware automatically counts down the number of data values and adjusts its address pointer as each new data value is transferred on the bus. The processor is not directly involved in a DMA transfer operation once it starts. Since the DMA controller(s) and processor must share the bus, bus arbitration hardware is needed to control bus access (i.e., will a DMA controller or the processor get the next bus cycle). A DMA controller interrupts the processor when its block transfer is complete and its counter reaches zero. The processor then programs the DMA controllers address register and counter to start a new DMA transfer. Hardware is needed for each DMA controller and an interrupt system is needed to support DMA. Most current processors have a cache which helps free up bus bandwidth for use by DMA controllers.
Processor With Cache
Memory
I/O Hardware using DMA
System Bus
Figure 2.14 During a DMA bus cycle, the DMA controller serves as the bus master and the processor is disconnected (tri-stated) from the bus. Bus arbitration hardware is required for DMA.
Additional bus signals are needed to support DMA. DMA controllers must request a bus cycle and wait until it is granted by bus arbitration hardware. On the ISA bus DRQx and DACKx signals are used for DMA, and the PCI bus uses the REQx and GNTx signals for DMA. For security, the OS must control all DMA hardware. DMA is most effective when it is used for high-speed block transfer devices like disk drives (disks transfer sectors) and network interfaces (transfer packets). In an ideal system, several DMA controllers and the processor will be operating in parallel allowing the overlap of computations on the processor with the DMA I/O transfer operations. While one process is busy waiting on its DMA I/O operations to complete, the processor can be performing useful computations on another process. In Windows Embedded CE, the CEDDK library and the kernel have several functions that are used to support DMA.
56
2.12 OS support for Device Independent I/O & Files

Operating systems provide support for the underlying I/O hardware. Many of the I/O devices can be supported in application programs by using the basic file system API calls. One important feature of an operating system is the support it provides for file system I/O. It provides a uniform logical view of information storage. Different storage media and many of the I/O devices (including serial and parallel ports) can use a single API interface to read and write data. Typically the following five basic file operations are supported by OS API calls: Open (or Create): For a read operation on an existing file, the open operation searches for the file, for a write operation it searches for available space on the storage device and typically allocates buffer space to handle file transfers. A file name is passed with the open call. For I/O some devices, such as a serial port, the filename is the device name and only one Open at a time is allowed since the device requires exclusive access. An argument to the open operation typically specifies if the file will be read or written. Errors can occur if the file is not found on a read operation or no space is available on the storage device on a write operation. Read: The next block of data is read from the open file. A file identifier or handle and a pointer to a buffer area in which to return the data read are arguments. Write: The next block of data to write to the open file. A file identifier or handle and a pointer to a buffer area from which to copy the data to write are arguments. An error can occur when no space is available on the storage device. Seek: Move to a specific location within a file. The argument is normally the record number to seek to. Seek is much faster than reading multiple times to move to a specific record in a file. Typically, the seek operation is not supported on every file type and device. Close: Close the open file. For a write operation, close flushes all write buffers and updates the final directory entries for the new file. It also releases the internal file buffer space. A close is required in most operating systems. In some, but not all operating systems when a process terminates, all of the processes open files are automatically closed. In most cases, these functions all return error codes which should be checked by the application. In Windows Embedded CE, these file operations are provided by CreateFile, ReadFile, WriteFile, SetFilePointer , and CloseHandle. See the on-line help for more information on all of the parameters for these functions.
57
2.13 Unicode and ASCII character encodings

Embedded systems designed for international markets that require support for different languages commonly use the 16-bit Unicode character encoding standard. Many peripheral I/O devices use the 8-bit ASCII character code seen in Table 2.3. The first 128 Unicode characters are the same as the ASCII characters, but with an extra leading zero byte in front of them. Conversion charts can be found at www.unicode.org/charts/ . (English uses the Basic Latin Script) Table 2.3 ASCII Character to Hexadecimal Conversion Table.
0 1 2 3 4 5 6 7 0 NUL DLE SP 0 @ P ` p 1 SOH DC1 ! 1 A Q a q 2 STX DC2 " 2 B R b r 3 ETX DC3 # 3 C S c s 4 EOT DC4 $ 4 D T d t 5 ENQ NAK % 5 E U e u 6 ACK SYN & 6 F V f v 7 BEL ETB ' 7 G W g w 8 BS CAN ( 8 H X h x 9 HT EM ) 9 I Y i y A LF SUB * : J Z j z B VT ESC + ; K [ k { C FF FS , < L \ l | D CR GS = M ] m } E SO RS . > N ^ n ~ F SI US / ? O _ o DEL
The American Standard Code for Information Interchange (ASCII) is a standard seven-bit code for computer equipment adopted in 1968. In Table D.1, locate A. It is in row 4 in column 1, so the hexadecimal value for A is therefore 0x41. The eighth bit is sometimes used for parity in communication devices. Codes below 0x20 are called control codes. Control codes perfo rm operations other than printing a character. Several of the most common control codes are described below:
LF (line feed) - Moves the cursor down to a new line, but not to the left. \n in C/C++. CR (carriage return) - Moves the cursor all the way to the left, but does not advance to the next line. \r in C/C++ . For a new line, both CR and LF are used. SP (space) prints a blank space and cursor moves to the next character position. FF (form feed) - Advances paper to the top of the next page on printers or clears the text display window in terminals. \f in C/C++ . BEL (bell) - Causes a beep in terminals and terminal emulation programs. BS (backspace) - Moves the cursor move backwards (left) one space. \b in C/C++. HT (horizontal tab) - Moves the cursor right to the next tab stop. The spacing of tab stops is dependent on the output device, but is often 8 or 10. VT (vertical tab) - \v in C/C++ ESC (escape) Sometimes used to terminate program commands NUL (null) all zeros, sometimes used for end of strings.
58
Note that the decimal digit characters 0 to 9 range in value from 0x30 to 0x39. The code is setup so that A<B<C so that numeric values can be used for alphabetical ordering. A single bit in the code changes the case of a character (i.e., see A and a) when the shift key is hit. Also the ctrl key changes a single bit in the code. Extended ASCII codes use the eighth bit to display another 128 special graphics characters. There are several different standards for these new graphics characters, so check the device s manual for details. The first 128 characters are the same as the 7-bit original ASCII code standard. In Unicode, the first 128 characters are the same as ASCII character with a high byte of all zeros to pad it to 16-bits. Windows Embedded CE uses Unicode by default for all character strings. In C, the built-in type char uses 8-bit ASCII encoding, but type TCHAR uses 16-bit Unicode. A special macro call _T or _TEXT can be used to initialize a Unicode string from a C character string. As an example, _T(hi) would generate a 4byte Unicode string with a value of 0x00, 0x68, 0x00, and 0x69. The C\C++ functions, WideCharToMultiByte and MultiByteToWideChar , are available to convert character strings to/from ASCII and Unicode. The function, lstrlen, returns the character length of a Unicode string. See the on-line help for more information on parameters for these functions.
2.14 For additional information:

ISA & EISA Theory and Operation, by Edward Solari. (RTCbooks) (ISBN 0929392-15-9) ISA System Architecture, by Don Anderson and Tom Shanley (ISBN 0-92939215-9) (MindShare) (ISBN 0-201-40996-8) PCI Hardware & Software Architecture and Design by Edward Solari & George Willse (RTCbooks) (ISBN 0-929392-59-0) PCI System Architecture by Tom Shanley (MindShare) (ISBN 0-201-40993-3) The PCI special interest group www.pcisig.org sells the full PCI specifications PCMCIA (Personal Computer Memory Card International Association) www.pcmcia.org has specifications available on PC Card and Express card modules. PCI 104 specifications are available at http://www.pc104.org/

1. Compute the peak I/O bandwidth of a 16-bit ISA bus that takes six 8Mhz clocks per transfer and compare it to a 32-bit PCI bus with a 66Mhz clock doing a PCI burst of four data values with 2-1-1-1 clock timing on the burst. 2. An external input signal needs to be sampled at a 10,000Hz rate using an I/O port with interrupt hardware support and an interrupt service routine. How much time is available for the interrupt service routine to run per interrupt cycle on average to insure that it uses less than 10% of the available processor time in the system? 3. Rewrite the code segment shown in Figure 2.12 for an I/O input operation.
59
4. If you have used a VHDL or Verilog synthesis and simulation tools in earlier coursework, develop an ISA I/O port synthesis model and simulate I/O read and write operations to an 8-bit I/O port at address 0x3E0. Be sure to test those cases where the I/O port should not respond such as a different I/O address or bus cycles other than I/O read and write. Free VHDL and Verilog tools are also available for students from the major FPGA vendors including Altera and Xilinx. 5. Using a Logic Analyzer or a Mixed Signal Oscilloscope capture bus signals from a real bus such as ISA. Try to capture and explain both an I/O read and an I/O write bus operation. To simplify, if enough channels are not available or hookup is difficult capture only the lower address and data bits, but be sure to include the critical bus status signals. If a bus prototyping card or bus extender card is available they can make hookup easier to the test equipment. 6. If an ISA prototyping system or board is available for the PCs in the laboratory, design and build an 8-bit I/O input and output port at address 0x3E0. This address is typically not used by other devices present in a PC. Octal TTL devices, a 74LS688 used for the address decoder with an Intel 8255, or an FPGA can be used to reduce the chip count. Test the I/O ports operation using DOS Debugs input and output commands. Note: Some older motherboards still have ISA slots and special USB to ISA adapters are also available for PCs without ISA slots. 7. If a standard student logic protoboard system is available with a few switches and LEDs in the laboratory, design and build an 8-bit I/O input and output port at address 0x3E0 that would function on an ISA bus. Address 0X3E0 is typically not used by other devices present in a PC. Octal TTL devices, a 74LS688 used for the address decoder and an Intel 8255, or an FPGA can be used to greatly reduce the chip count. Test the I/O ports operation using the switches for input signals and LEDs for output signals. If the number of switches or protoboard size is limited, omit the higher address and data bits to simplify the circuit. The primary goal is to be able to demonstrate a circuit that can read and write at least one external data bit using the standard ISA bus signals. 8. If you have used a VHDL or Verilog synthesis and simulation tools in earlier coursework, develop a PCI I/O port synthesis model and simulate I/O read and write operations to an 8-bit I/O port at address 0x3E0. Be sure to test those cases where the I/O port should not respond such as a different I/O address or bus cycles other than I/O read and write. Free VHDL and Verilog tools are also available for students from the major FPGA vendors including Altera and Xilinx. Make the following assumptions to simplify your HDL synthesis model and simulation:
60
You only need to implement and simulate the PCI bus signals shown in the textbooks PCI timing figures. You can ignore IRDY and TRDY and assume both devices are always ready. You do not need to implement the individual byte enables on your 32-bit output port and assume it is not accessed in a PCI burst (i.e., assume only 1 data value is transferred per PCI bus cycle) Use an initial reset signal to clear all registers in your simulation. The PCI Bus clock is 33 MHz and the Address/Data bus is 32-bits wide. Save any values needed from the bus on the rising edge of PCI Bus Clock using a positive edge triggered DFF or Register. To detect the start of the bus cycle, save the previous value of Frame in a 1-bit register. When the old (saved) value is a 1 and the current value is a 0 assume that this signals the first clock cycle of a new bus cycle that contains address and command information (and not data). On the first clock cycle, save the address (A/D) and bus command (C/BE) information in a register. Then check the registers output values to decode the address and check (C/BE) for the type of bus operation to decide what operation to perform in the second clock cycle of the bus cycle. You will need to automatically clear both of these register values out at the end of the PCI bus cycle.
9. Search on the web for other bus standards used for the ARM Processor family such as AMBA and summarize the function of the major bus signals. 10. Special PCI cards are available to connect Logic Analyzers to the PCI bus along with special software that decodes the PCI bus cycles as seen in Figure 2.15. If such test equipment is available, capture some data from a PCI bus on a PC while it is operating. 11. Many processors have special built-in hardware debug pins or other features to trace the processors instruction execution using special test equipment similar to a logic analyzer. On some simple processors, you can also follow instruction execution by connecting a logic analyzer to the processors memory address and data lines. An example is seen in Figure 2.16. If such test equipment is available along with an appropriate target board, capture the execution of the first few machine instructions as the processor on the embedded device powers up. 12. Write two short C/C++ code segments that would output the data value 0x41 to an 8-bit parallel port at address 0x3e0. First use in-line X86 assembly language and second using CEs CEDDK library APIs.
61
Figure 2.15 A Tektronix logic analyzer setup to capture and decode PCI bus signals. This logic analyzer is actually an embedded system that runs Windows XP. A special PCI interposer adapter card is used to quickly connect probes along with special firmware for the logic analyzer. Images courtesy of Nexus Technology.
62
Figure 2.16 A Tektronix logic analyzer with optional software setup to capture and disassemble an ARM processors instruction execution sequence. This logic analyzer is actually an embedded system that runs Windows XP. Images courtesy of Nexus Technology.
CHAPTER 3
I/O Interfacing Standards for External Devices
A Kuka industrial robot assembly line building Mercedes automobiles. Kuka robots are available with controllers that are based on Windows Embedded CE. Photograph courtesy of Kuka Roboter GmbH.
64
3 I/O Interfacing Standards for External Devices

A number of widely used digital interface standards have developed over the years to interface computers to their peripheral devices. This section will describe several of the more common standards and briefly discuss how they operate. Each standard has its own set of hardware, software, and performance tradeoffs. Normally, several of these interfaces will be found in an embedded device. A large number of peripheral devices and ICs use these standards.
3.1 Parallel Printer Interface

The parallel printer interface standard was developed in the 1970s and is a widely used standard for transferring 8-bit parallel data. Most PCs and many embedded computers have a parallel printer port. Data is transferred in parallel using eight data bits and standard digital logic voltage levels. Handshake lines are required to synchronize each data transfer. The handshake lines are connected to I/O status and control ports. In PCs, the parallel printer port is interfaced to three 8-bit I/O ports on a processor. One I/O port is used for 8-bit data transfers, the next I/O address contains an I/O port for the status and the third address contains an I/O port for the control bits that are used for handshake signals. The transfer of a single data byte value is shown in Figure 3.1. In step 1, the computer waits for t he printers busy signal to go L ow. In step 2, the computer outputs the eight data bits and the computer then sets the strobe signal Low for at least 500 ns in step 3. The computer then waits for the printer to pulse Ack Low. The computer must wait for Ack Low before changing the data or strobe lines. The printer may go Busy after it raises Ack .
Data Lines Busy
Data Valid
nStrobe
nAck 1 2 3 4
Figure 3.1 Parallel Port transfer of an 8-bit data value to a printer
65
Handshake lines from the printer can make the computer wait for events such as paper out, a page feed, or buffer overflow. Timeout loops are sometime s used in software, so that notices are sent to the user when the printer is busy too long. Other special purpose devices often use the parallel port interface for GPIO to control external hardware since it is an easy way to access several digital logic output bits. Originally the parallel printer port was unidirectional. Newer parallel port standards support bidirectional and faster data transfers between an external device and the computer (i.e., IEEE 1284 ECP and EPP standards). A new control bit was added that specifies the data transfer direction. Tri-state gate outputs are used in both the computer and printer to drive the data lines bidirectionally based on the setting of the control bit. Parallel cables need to be fairly short. The serial interface described in the next section can have longer cables that require fewer wires, but it also has lower data transfer rates and less bandwidth.
3.2 Software support for the parallel printer port

Most operating systems provide device drivers for a parallel printer port. On X86 systems, parallel printer ports typically have the device name LPT x:, where x is the printer port number. The Bidirectional protocols are described in more detail in the IEEE 1284 Parallel Port Standard. Methods used for printing graphics and different fonts vary widely (i.e., PS and PCL) and typically require a printer driver for the specific printer model. If a printer driver is implemented on a platform in Windows Embedded CE, the function calls PrinterOpen, PrinterSend, and PrinterClose can be used to send data to a printer or file system API I/O calls using the LPT device name can be used. A default PCL printer driver is included in Windows Embedded CE. If the printer port is being used for other special devices, their drivers can send data directly to the I/O ports using the WRITE_PORT_UCHAR function and read the status bits using the READ_PORT_UCHAR functions found in the CEDDK.
3.3 RS-232C Serial I/O Interface

Most serial interfaces support the EIA RS-232C standard. V.24 is the standard used in Europe. An 8-bit data value is transmitted one bit at a time serially. Most PCs and embedded computers have at least one RS-232C serial COM port. In the RS-232 standards simplest implementation, only three wires are used in the cable. One wire is used to transmit data (TD), one to receive data (RD) and one to connect the signal ground (GND). A fixed frequency clock is used to shift out the serial data. The frequency of this bit clock is called the serial interfaces baud rate. Baud rate is named in honor of the French engineer, Baudot, who invented a serial interface for the telegraph. Serial devices can be transferring data in both directions at the same time (fullduplex) since two different signal wires are used for receive and transmit . Serial interface cables can be long and they only require a few wires. The ASCII
66
character code is typically used on most serial devices, but they can also be used to transfer any 8-bit binary values. The baud rate clock is not synchronized with a clock signal wire connected between the sending and receiving devices, rather it is asynchronous and is derived using a state machine that is watching the serial data bit transitions occurring at the receiver. There is no clock connection between the sender and receiver for synchronization in an RS-232 serial interface. The transmitter and receiver must be initially set to operate at the same clock or baud rate. A state machine is used to adjust the clock phase. Even though they have the same clock rate, the clock phase must still be synchronized between a serial transmitter and receiver by examining the incoming serial data. Universal Asynchronous Receiver Transmitter (UART) is the name used for the hardware needed to implement a serial interface. Features based on the original 16550 UART chip are used in most PC hardware today including the eBox 4300 target device that will be used for laboratory projects.
0x50 = ASCII P 0 Mark (1) Space (0) Start Bit 0 LSB 1 2 3 4 5 Data Bit number 6 7 MSB Stop Bit 0 0 0 1 0 1 0
Figure 3.2 RS-232C Serial interface transmission of an 8-bit data value. Voltage levels are >3 for a mark and <-3 for a space. This is not compatible with standard logic levels and a converter is needed.
The transmission of an individual ASCII character is seen in Figure 3.2. The serial bit has two states. Mark is the high state (>3V) and Space is the low state (<-3V). Older generation serial devices may have around +12V and -12V levels for Mark and Space. Note that for the proper RS-232 voltage levels, a standard digital logic output bit will have to have its voltage levels converted for use in a serial interface. To convert to RS-232 voltage levels, special ICs are available. RS-232 level conversion ICs can also generate the required DC supply voltages from the standard digital logic DC power supplies. The idle state is High (Mark). Whenever the interface starts sending a new 8-bit data value, the line is dropped Low (Space) for one clock cycle (baud rate clock). This is called the start bit. The eight data bits are then clocked out during the next eight baud clocks in low to high bit order. The highest data bit is sometimes used as a parity bit for error detection, when only seven data bits are used instead of eight. After the data bits are clocked out, the bit goes high for one clock. This is called the Stop bit. Sometimes at very low baud rates, two
67
Stop bits are present. Note that at least 10 baud rate clocks are required to transfer each 8-bit data value. A UART is typically interfaced to a processor using several I/O ports. One port transfers the eight bit data value. Another port contains handshake lines to indicate when new data is available or the UART is ready to send new data. Often much of the I/O port hardware is actually contained inside the UART. The processor is much faster than the serial transmission rates, so the status bits must be checked in software or hardware for the proper values before any data transfers occur. Additional status bits can also detect error conditions. An 8-bit shift register is used inside the UARTs transmitter and it is clocked by the baud rate clock to shift out the data one bit at a time. A shift register is used for parallel to serial conversion. The UARTs hardware automatically adds start and stop bits. The receiver at the other end of the cable is another UART. It has an internal state machine that uses the start and stop bits to help it adjust the clock phase on the incoming serial data. Whenever it sees a data edge on the incoming serial data, it readjusts the clock phase. Several bits could have the same value and there would be no data edge. The state machine has a counter to detect and correct for this condition. The state machine inside a UART typically uses a faster clock that is eight, sixteen, or even sixty four times faster than the baud rate. It also uses this fast clock and a counter to sample the data in the middle of each bit period. There is often noise and ringing on serial cables near edges, so sampling in the middle of each bit improves the reliability. After sampling data with a slower synchronized baud rate clock derived by the state machine, a second shift register is used in the receiver for serial to parallel conversion. Optional handshake lines can be used in serial cables to start and stop the flow of data. These commonly include RTS (request to send), CTS (clear to send), DCD (data carrier detect), DSR (data set ready), and DTR (data terminal ready). Without handshaking or software flow control, at higher baud rates many serial devices will drop characters since the UARTs buffers are relatively small and a microprocessor may not be able to read the data in fast enough. An RS-232 device can be one of two types, data terminal equipment (DTE) and data carrier equipment (DCE). The normal RS-232C serial cable is setup to connect a DTE device to a DCE device. If two devices of the same type are connected, a special null modem cable or adapter is needed. A null modem exchanges the Transmit Data (Tx) and Receive Data (Rx) signal lines at one end of the cable along with several connections on the handshake lines. When the Ebox 4300 is directly connected to a PCs serial port, a null modem cable must be used since both devices serial connectors are setup as DCE. There are also low-cost RS-232 analyzer devices designed to help figure out the various options for null modem and the exact handshake setup. They are handy if you have problems connecting two serial devices. Special PC software is also available that displays additional serial port information that helps monitor and debug serial data transmissions.
68
3.4 Software support for serial communications

Most operating systems provide device drivers for serial ports. On X86 systems, serial ports typically have the device name COM x:, where x is the serial port number. In Windows Embedded CE in C/C++ you can open a COM port with the CreateFile function, read data with ReadFile, and write serial data with WriteFile. To close the serial port use CloseHandle. Baud rate, number of data bits, parity and other options can be read and set using the GetCommStatus and SetCommStatus functions. COM1: is often used for debug information in Windows Embedded CE. If both serial transmit and receive operations are needed simultaneously, threads are normally used. One thread sends serial data and another thread receives serial data. The special synchronization function, WaitCommEvent , is typically used in these threads.
3.5 The PS/2 Keyboard and Mouse Interface

The Personal System 2 (PS/2) interface is based on a standard used in an early IBM PCs mouse and keyboard in 1984. Many embedd ed computer boards support the use of either a mouse or keyboard using a PS/2 connector on the board. The PS/2 signal connector has 6 pins including ground, power (5VVDD), PS/2 data, and a PS/2 clock line. The computer supplies the power to the mouse and keyboard microcontrollers. The PS/2 serial data line is somewhat similar to the RS-232 signals, but in this case a clock signal is connected between the device and computer for synchronization and the standard logic gate voltage levels are used. This makes the hardware less complex, but an extra signal wire is required for the clock. The PS/2 clock and data lines are open collector outputs and bi-directional. On systems with both a mouse and a keyboard, there is one set of PS/2 clock and data lines for each device. The clock line is normally controlled by the keyboard (or mouse), but it can also be driven by the computer system, when it wants to stop data transmissions from the keyboard. The keyboard (or mouse) and the computer can both drive the data line. The single data line transfers all data between the two devices. The keyboard (or mouse) and the computer can exchange several commands and messages. To encode a keyboard, the key switches are arranged in a matrix of rows and columns. All rows and columns are periodically checked by a circuit called a keyboard encoder. The keyboard encoder scans through the keys at a high rate to find any key state changes. Key data is transmitted serially to the computer from the keyboard using what is known as a scan code. Each keyboard key has a unique scan code based on the key switch matrix row and column address to identify the key pressed. Scan codes on a PS/2 keyboard consist of a series of Make and Break codes. Each time a key is pressed a make code is sent. A break code is sent whenever the key is released. On many keys, the break code is a byte stream of 0xF0 followed by the make code for the key. When typing, it is common to hold down several keys at the same time before the first key is released. With make and break codes, the computer can decide whether or not the key has been
69
pressed, and if more than one key is being held down. It can also distinguish which key has been released. This also happens when using the shift or control keys. While the shift key is held down, the '1' key should return the value for the '!' symbol instead of the value for the '1' symbol. 8-bit scan codes are transmitted serially on the PS/2 data lines using an 11-bit format. When both the PS/2 device and the computer are not sending any data, the PS/2 data line and the PS/2 clock line will be High (inactive). Figure 3.3 shows the transmission of a single byte of a keyboard scan code and it consists of the following bits: 1. A start bit ('0') 2. 8-bits of data containing the key scan code in low to high bit order 3. An odd parity bit. 4. A stop bit ('1') During transmission of data from the PS/2 device the following occurs: 1. The PS/2 device checks to ensure that both the clock and keyboard lines are inactive. Inactive is indicated by a High state. If both lines are inactive, the keyboard prepares the 'start' bit by dropping the data line Low. 2. The PS/2 device then forces the clock line Low for around 35us. 3. The PS/2 device will then clock out the remaining 10 bits at a rate of around 70us per clock period. The PS/2 device drives the data and clock line. 4. The computer recognizes the start bit and clocks in the serial data. The 8-bit serial data is followed by an odd parity bit and finally a High stop bit. If the PS/2 device wishes to send more data, it follows the 11th bit immediately with the next start bit. This pattern repeats until the keyboard is finished sending data at which point the clock and data lines will return to their inactive High state.
PS/2 Clock PS/2 Data Start Bit 0 1 1 0 1 0 0 Data Bits (low to high) 0 Parity Stop Bit Bit
Scan code 16H for 1 key

Figure 3.3 PS/2 Transmission of a Keyboard Scan Code
In Figure 3.3, the keyboard is sending a scan code of 16 for the "1" key and it has a zero parity bit.
70
Both the PS/2 keyboard and the PS/2 mouse use the same synchronous serial communication protocol. Internally, the original mouse contained a ball that rolled two slotted wheels. The wheels were connected to two optical encoders. The two optical encoders report x and y motion by counting pulses when the wheels move. It also contains two or three pushbuttons that can be read by the system and a single-chip microcontroller. After power up, a PS/2 command is sent telling the mouse to start sending special data packets. The microcontroller firmware in the mouse then starts periodically sending 3-byte data packets to the computer over the PS/2 signal lines. The three byte mouse data packets report relative XY movement and button status.
3.6 Software for the PS/2 Keyboard and Mouse Interface

Operating systems typically include standard PS/2 keyboard and mouse device drivers. The keyboard driver converts sequences of key scan codes to characters and the mouse driver uses the relative motion information contained in mouse data packets to calculate the location of the displays mouse pointer and to monitor mouse button status. In a desktop Windows OS and in Windows Embedded CE, keyboard and mouse input activity automatically creates a Windows messaging event that is handled by a window application s callback function. The application processes the messages that are sent to it. It does not directly read the keyboard and mouse input.
3.7 SPI Bus Interface

The serial peripheral interface (SPI) bus dates back to the 1980s. SPI is used for serial communication between a microprocessor and its peripheral ICs. SPI has the following four signal lines: Serial Clock (SCLK), Chip Enable or Select (CS), Serial Data Input (SDI), Serial Data Output (SDO). The microprocessor drives the CS and SCLK signal lines. SPI slave devices get their clock and chip select inputs from the microprocessor. Whenever an SPI device is not (chip) selected, its SDO output line is tri-stated (high impedance state). The number of serial data bits can vary depending on the device. SPI interface hardware contains shift registers. One shift register is used to send out data and another shift register is used to receive data. The clocks are all synchronous and they use SCLK. Multiple SPI devices can be connected in one of two ways. In a cascaded connection, only one chip select is used. The microprocessor outputs SDO. SDO connects to one sla ve devices SDI inp ut. Each devices SDO line connects to another devices SDI line . The final device connects back to the microprocessor, so the serial data shifts through one large shift register. This simplifies the hardware and works well in systems where all devices are always sampled or updated at the same time. But if only one devices data is needed, it is necessary to shift through the other SPI devices in the chain to get to its data.
71
Slave 0
Master CS0 CS1 CS2 SCLK SDO SDI
Slave SDI SDO

Master CS0 CS1 CS2 SCLK SDO SDI
SDI
SDO
SDI Slave SDO
Slave 1 SDI SDO
SDI Slave SDO
Slave 2 SDI SDO
Figure 3.4 The two SPI slave device configuration options.
In the second SPI configuration, each device has its own chip select, and they all function as independent shift registers. Recall that if a device is not selected, it tri-states its output. The outputs can be connected together, but only one device at a time can be enabled. This allows independent reading and writing of the SPI devices. The disadvantage is that more output lines are needed for the chip selects. SPI also supports multiple bus masters. SPI device clock rates can range from 30 kHz to 3 MHz. Typically, SPI devices will place new data on their outputs during the falling clock edge, and data will be clocked in on the rising clock edge. Double check each SPI device s datasheet since this scheme is sometimes different. SPI is also known as Microwire in National Semiconductor ICs. Datasheets for Motorola SPI devices often use different names for the SPI signals. CS may appear as SS, SDI as MOSI, and SDO as MISO. SPI devices are also available in several different voltage supply levels ranging from 2.3 to 5 volts. SPI uses a common clock and standard logic voltage levels. This makes the hardware interface simpler than an RS-232C serial device, but it is also designed for shorter distances such as on a single printed circuit board (PCB).
3.8
I2C Bus Interface
To connect ICs on a single PCB the Inter IC (I 2 C) bus also appeared in the 1980s. A wide assortment of ICs and microprocessors are available with an I 2C interface used to transfer data serially to other ICs. Like SPI, a serial interface has a hardware advantage in that it requires fewer pins and traces on a PCB as long as the bandwidth is sufficient. An I2C bus has only two signal wires, SCL and SDA. SCL functions as a clock line and SDA can function as a 1-bit serial data line or as a 1-bit serial address line. A common ground is of course also required. The I 2C signal lines are open
72
drain. Once again, this means they are only driven low and a single external pull up resistor pulls the line high (when no device is pulling it low). With additional logic gates, a tri-state output can simulate an open drain output by tri-stating its output whenever the bit should go high. I2C devices are either masters or slaves. Slaves respond to requests from the master. An I 2 C slave device is assigned a unique 7-bit I 2C bus address. Since I2C has address information, the bus protocol is more complex than SPI. Recall that SPI used chip select lines and no addresses. When a microprocessor (master) needs to communicate with an I2 C device (slave) it sends out a start sequence. To stop an I 2 C sequence, the microprocessor sends out a stop sequence. In Figure 3.5, note that a start sequence is the only time SDA goes high to low while SCL is high. Also note that a stop sequence is the only time SDA goes low to high while SCL is high. This allows a special logic circuit to detect start and stop. The microprocessor drives the SCL clock lines to transfer each SDA serial bit. I2C devices can drive SCL low to force a wait state. Typical clock rates range from 100 kHz to 400 kHz. Consult each device s datasheet for details.
SDA MSB ACK Signal from Slave Byte Complete SCL S STA RT Ad dress Clock Line Held Low while serviced 1 2 3-7 8 9 ACK ACK Signal from Receiver
3-6
8 9 R/W ACK
P STOP
Data
Figure 3.5 An I2C interface serial transmission of an 8-bit data value
Each address and data transfer contains a total of nine bits. Eight data bits with an acknowledge bit (ACK) used for handshaking. The bits are sent out in high to low order, one per clock. Seven address bits are used and the final eighth bit is a read/write (R/W) bit. Some datasheets describe this as eight address bits where even addresses are used for reads and odd addresses for writes, leaving out the R/W bit. The slave sends the last acknowledge (ACK) bit in each address and data transfer. ACK low indicates the slave is ready. When ACK is not low, the microprocessor can send a stop sequence.
73
When a microprocessor wants to send data to an I2 C device it must perform the following I 2C operations as shown in Figure 3.5: 1. The microprocessor sends an I2 C start sequence. 2. The microprocessor serially clocks out the 7-bit I 2 C address of the slave with the R/W bit set Low (i.e., write operation) 3. The microprocessor serially clocks out the 8-bit internal register number to write. Most I 2C devices have a device address followed by a register address (the register address in this case would be in the data field shown in Figure 3.5). 4. The microprocessor serially clocks out the 8-bit data value(s). 5. The microprocessor sends a stop sequence. As shown in Figure 3.5, when a microprocessor wants to read data from an I 2C device, it must perform the following I2 C bus operations: 1. The microprocessor sends a start sequence. 2. The microprocessor serially clocks out the 7-bit I 2 C address of the slave with the R/W bit set Low. 3. The microprocessor serially clocks out the 8-bit internal register number to read. 4. The microprocessor serially clocks out an I2C repeated start sequence. 5. The microprocessor serially clocks out the 7-bit I 2 C address of the slave with the R/W bit set High (i.e., read operation). 6. The microprocessor serially clocks in the 8-bit data value(s). 7. The microprocessor sends a stop sequence. It is possible to have multiple bus masters with collision detection in one of the I2C standards. Bus arbitration is required. A collision occurs when two masters drive the bus at the same time. The bus arbitration scheme determines which device can drive the bus. Some I2 C devices support a higher 3.4 MHz clock rate, expanded 10-bit addresses, programmable addresses, and lower supply voltages. Many PC motherboards use the System Management Bus (SMB) to measure temperature, fan speed, and voltage. SMB was developed by Intel in 1995 and is based on I2C. I2 C devices can also be found in new TVs, automobiles and many other consumer electronics. The SPI and I 2C standards both provide excellent support for communication with low-speed devices on the same PCB. SPI is perhaps a better choice for applications that need to transfer higher bandwidth data streams that do not require address information. Analog-to-digital (A/D) and digital-to-analog (D/A) converters used to continuously sample or output analog signals are perhaps the most widely used SPI devices. I2 C requires addressing, so the hardware is more complicated but with current VLSI chip technology these additional hardware costs are minimal.
74
3.9 Software support for SPI and I 2C devices

Some general purpose microcontrollers and many USB microcontrollers include I2C and SPI interfaces. Two or three bits on a GPIO port can be also used with the appropriate software driver to implement an SPI or I 2 C interface. Using GPIO bits, the processor needs to generate all of the signals including the clocks by toggling GPIO bits on an I/O port, so the software implementation approach requires more processor effort.
3.10 Analog Inputs and Outputs

Systems that require analog inputs use analog to digital (A/D) converters and systems with analog outputs use digital to analog (D/A) converters. These devices all require a time delay when performing the conversion operation and are accurate to a specified number of bits. Typically, the conversion times are in the microsecond range and accuracy is in the range of 8 to 20 bits. In general, faster devices are more expensive and devices with more bits of accuracy cost more. Keep in mind that many sensors and signals actually have high noise levels and/or limited frequency content, so not every signal needs a large number of bits of accuracy and the fastest possible conversion time. Making an intelligent choice of accuracy and sample rates is an important design issue. Sampling rates are also limited by the real-time response of the system. It is not uncommon for an embedded device to have analog signals with different sampling rates. In addition to A/D and D/A chips, some analog signal conditioning circuitry is typically required to buffer the analog signals and adjust their voltage levels. Many A/D and D/A chips have SPI type interfaces and some have a parallel style interface for the devices required digital I/O lines. In addition to data lines, A/D and D/A devices typically have an input signal to start conversion and an output signal that indicates when the conversion is complete. These signals typically are used for the device s I/O ready bits. Commercial off-the-shelf (COTS) data acquisition systems on plug-in cards, USB, or network interfaces are available with analog I/O features. These devices contain built-in A/D and D/A chips, the associated analog signal conditioning circuitry, and often are available with device drivers for the major operating systems. Phidgets are one such example, a free CE driver is available, and they will be used in a laboratory project with the eBox 4300. The Phidgets LCD and 8/8/8 digital-analog USB I/O module that will be used in later examples with the eBox contains a MCP3008 A/D chip. The MCP3008 device shown in Figure 3.6 contains a successive approximation 10-bit A/D converter with on-board sample and hold circuitry, and an eight-channel input multiplexer that enables it to read eight external analog inputs. The MCP3008s accuracy is specified at 1 LSB (0.1%). Communication with the device is accomplished using a simple serial interface that uses the SPI protocol. The device is capable of conversion rates of up to 200K samples per second. It will sample much slower when it is used with a USB 1.0 microcontroller and a standard USB driver in the Phidgets module (50-125
75
samples per second). The module also contains a MCP23S17 16-bit GPIO expander chip with an SPI port that is in turn attached to a CY7C63823 USB Microcontroller. Note that the A/D converter actually is built using a special fast digital counter called a successive approximation register (SAR) and a D/A converter. The D/A converter s analog output value is compared to the analog input. When the two analog values are the same as measured by the analog comparator, the digital value in the counter is the new A/D converter value.
Figure 3.6 The MCP3008 10-bit 200Ks/sec A/D chip used in Phidget modules has an SPI interface. Image courtesy of Microchip Technology.
3.11 The Universal Serial Bus (USB)

The Universal Serial Bus (USB) 1.0 specification was released in 1996. USB 2.0 is a newer higher speed standard that also supports USB 1.0 devices. As its name implies, USB is a serial bus that was designed to support a wide range of peripherals. It transfers data in packets similar to a network, but since the maximum length is limited to several feet it is technically considered a n external bus and not a network. USB cables contain a +5V power and ground connection and two twisted pair signal wires (D+,D-). The two signal wires operate both in singled ended and in differential mode (one signal is subtracted from the other). It uses a NRZI (non
76
return to zero invert) encoding scheme that provides data along with a clock sync field. Power supply drain on the bus is limited to 500mA. USB supports three transfer rates, high speed (USB 2.0 only) is 480Mb/s, full speed 12Mb/s, and low speed 1.5Mb/s. USB is host controlled and only one host is normally allowed per bus. The host is responsible for initiating all transactions and scheduling bandwidth. Up to 127 different devices can be connected on a single USB bus. A new USB 3.0 standard is also being developed that has around ten times the bandwidth of USB 2.0. USB is designed to be hot pluggable. If you look into the end of a USB connector you will notice that the outer power and ground pins are longer than the two inner signal pins. When a connector is plugged in the power and ground are connected before the signal lines are connected. If signal wires were connected before a common ground was established, it could damage the device.
+5V bytes D+ DSerial Interface Engine (SIE) bytes USB Interface Progr am & Data (R AM & ROM) I/O Ports
GND USB Connector USB Transceiver
General Purpose Microprocessor
Figure 3.7 A low-cost USB Microcontroller is typically used in USB Devices.
USB devices are typically implemented using a low-cost USB microcontroller as seen in the Figure 3.7 above. In addition to a general purpose microprocessor with ROM & RAM memory, they contain the additional USB interface hardware needed. Special firmware in the microcontrollers ROM is used to control each USB device. These microcontrollers only cost a few dollars and can even be cheaper than just the cable and connectors needed for some of the older standards such as a parallel printer port cable. USB transfers information in packets. There are four types of packets, token packets, data packets, handshake packets, and periodic start of frame packets. A typical USB transaction seen in Figure 3.8 consists of a token packet (a header defining what should follow), an optional data packet (contains the data payload), and a handshake packet (acknowledge the transaction for error detection and correction). A cyclical redundancy code (CRC) is used to check for any transmission errors.
77
The serial data rates needed for USB are too high for a low-cost microprocessor to handle in software. A special serial to parallel conversion hardware unit called a serial interface engine (SIE) is included in most USB microcontroller chips. The SIE contains intelligence to manage the buss bit-level protocol and encoding. The microprocessor then transfers bytes (not bits) to the SIE at a slower data rate.
O U T
A D D R
E N D P
C R C 5
D A T A 1
Payload Data Data Packet
C R C 1 6
A C K H/S Pkt
O U T
A D D R
E N D P
C R C 5
D A T A 0
Payload Data Data Packet
C R C 1 6
A C K H/S Pkt
Token Packet
Token Packet
Payload D ata D+ Serial Interface Engine D(SIE) A C K Payload D ata
USB Transceiver
Figure 3.8 The USB Serial Interface Engine (SIE) performs the high speed serial to parallel conversions on USB packets since the serial data rates are too high for most microcontrollers.
The token packet contains a packet identifier, an address, and an endpoint. The packet identifier in the example below is an OUT token. Each device address (ADDR) can have several endpoints (ENDP). An endpoint is a buffer (typically 8 bytes) that interfaces between the SIE hardware of the device and the firmware running on the microprocessor in the USB device.
3.12 Software support for USB devices

When a new USB device is plugged in using a special process called enumeration, the host detects the addition of a new device and interrogates the inserted device to determine its USB Product ID and Vendor ID (PID/VID). The PID/VID information allows the host to search for and load the appropriate driver for the new device. The host then issues a set address command to assign an address to the new device. Operating systems typically include a driver to initialize the USB device and then search for the specific USB device driver needed. Standard drivers are typically provided with the OS for storage devices, Human Interface devices
78
(HID) such as a keyboard and mouse, and sometimes a generic USB serial device. Other devices normally require a specific device driver from the manufacturer. In CE, the USB device s PID/VID and the associated driver info is stored in the registry. Software and hardware USB Protocol Analyzers as seen in Figure 3.9 are available that monitor and display USB packets and they are useful when developing new USB drivers.
Figure 3.9 A software-based USB protocol analyzer captures and displays the USB packets exchanged with a USB Flash Drive (www.usbdeveloper.com, www.usblyzer.com, and www.hhdsoftwre.com ).
3.13 Audio I/O Devices

Many embedded devices now have audio features. Audio Codec 97 (AC97) is a PC standard for audio encoders/decoders developed by Intel in 1997. Codec refers to signals being en coded/decoded to analog audio from digital audio and vice versa. A codec is actually a combined A/D and D/A converter with mixers.
79
AC97 supports data rates up to 96 kHz in 16 to 20-bit stereo resolution. PCs also have a newer HD Audio standard, but embedded devices such as the eBox 4300 are more likely to use the older lower-cost AC97 devices for audio. The eBox 2300 uses a Realtek ALC202 18-bit AC97 Codec for audio as seen in Figure 3.10. In Windows Embedded CE devices with audio support, a large number of API functions are available for applications programmers. PlaySound (for *.wav files one at a time), WaveIn, and WaveOut are some of the more widely used API functions. A version of Windows Media Player ships with Windows Embedded CE and several sample audio application programs are included with Windows Embedded CE in the \SDK\SAMPLES\AUDIO subdirectory. Standard speech APIs are defined for the OS, but additional third party software speech engines are still required for speech synthesis and voice recognition.
Figure 3.10 Realtek ALC202 AC97Audio Device Block Diagram. Image courtesy of Realtek.
80
3.14 Interfacing to motors, relays and other high current devices

When interfacing digital outputs to control high current devices such as motors, relays, buzzers, solenoids, speakers, or lights, a special driver circuit that provides additional drive current is required. Even through the voltage levels may be compatible, a typical digital output pin found on an I/O port provides only a few milliamps of current, but a motor or relay might need several amps of current. Attempting to drive a large inductive load like a motor or relay directly from a digital logic IC pin can easily blow up the internal driver transistor in a typical digital output circuit .
Figure 3.11 Block Diagram of the Fairchild FAN8100N Low Voltage Dual H-Bridge DC Motor Driver IC. Image courtesy of Fairchild Semiconductor.
For motors and relays, special driver circuits are available than have larger power transistors that provide more drive current. One power transistor can be used as a switch to turn a device on and off. The driver circuit goes between the
81
normal digital logic output pin and the high current device to provide the higher current levels required. For a single output pin, a small circuit can be added using a discrete power transistor to drive the device. A digital logic output bit controls the transistor. Special driver ICs are also available with several such driver circuits in a single IC package. An H-bridge is a useful circuit designed to control and reverse DC motors. A DC motor runs in the reverse direction when its two leads are reversed. Hbridge circuits are available in ICs or small pre-assembled modules. The block diagram for a dual H-bridge IC is seen in Figure 3.11. Each H-bridge contains four large power transistors seen on the right in Figure 3.11. An H-bridge has two digital input signals that control the circuit as seen in Table 3.1. NPN and PNP, or PMOS and NMOS power transistors can be used in an H-bridge. Note that in some simple H-bridge circuits, the last state can actually short the power supply and therefore must always be avoided. When supported, the brake function shorts the motor leads stopping the motor faster, but it requires a more complex decoder circuit to drive the control inputs to the four power transistors in the H-bridge. Check data sheets to confirm this feature exists before using it. Table 3.1 H-Bridge Control Functions Input 10 01 00 11 Function Forward Reverse Stop Brake or Short Power Supply (not allowed!) Operation DC Motor runs in the forward direction DC Motor runs in the reverse direction Motor is not connected Coasts and eventually stops Motor Terminals Shorted to Brake or Power Supply Shorted!
Diodes are sometimes connected backwards across the power transistor output pins on inductive loads such as motors, relays, and solenoids. When the current in an inductive load is turned off abruptly, it generates a reverse voltage spike (back EMF). The diode helps dissipate the energy in the spike and protect the driver transistor. Note that these diodes are actually seen in Figure 3.11. Speed control on DC motors with a driver circuit can be implemented by varying the on/off time (duty cycle) of the motors digital control signal using pulse width modulation (PWM). To avoid jerky movements and excessive noise, the control signal needs to be pulsed at several kilohertz (well above the natural frequency response of the motor and gears). A low pass filter is sometimes added across the load when PWM speed control is used.
82
Many robots use two DC drive motors with one motor for each wheel. Even the same model motors speed varies significantly from motor to motor, and synchronizing two motors to move at exactly the same speed is all but impossible without some feedback sensor such as an optical motor shaft angle encoder. Some new driver ICs also have a motor current feedback circuit, and it is used to make the motor speed less dependent of the load on the motor.
Figure 3.12 This dual H-Bridge module switches up to 10 amps at 24V DC. The eight discrete power transistors can be seen on the right side of the board. Photograph courtesy of RoboticsConnection.
Higher current H-Bridge modules typically use discrete power transistors assembled on a board as seen in Figure 3.12. This dual H-Bridge module designed for robot drive motors switches up to 10 amps at 24V DC. The eight power transistors can be seen arranged on the right side of the board and screw terminals are provided to connect to the DC motor leads. When instantly reversing DC motors, large back EMF voltages are generated that may put excessive noise on the power supply lines. Motors also take more current when they first start up. In some cases, the noise spike generated on the power supply lines can be strong enough to crash the processor. A 10-1000 uf electrolytic decoupling capacitor connected across the power supply lines near the driver circuit can help filter the power supply noise generated by turning on and off motors. A 0.1 uf capacitor is typically also connected in parallel in this circuit, to filter high frequency noise since the dielectric material in electrolytic capacitors does not work at high frequencies (i.e., the C value is not constant with frequency in real devices). Sometimes even a different power source is used to drive the motors to help prevent noise problems. For example, if a battery is used, the motors might connect directly
83
to the battery and a voltage regulator circuit provides regulated power to the processor and digital circuits. Some systems also add a small software time delay whenever they reverse a motor to reduce the noise spike. The motor is turned off first for a small (100-500ms) time delay, before the reverse command is sent. Stepper motors are used when accurate position control without feedback sensors is needed. One common application for stepper motors is to move cutting tools in low-cost computer numerical control (CNC) machines, to move the read head in a floppy disk drive, and to move the sensors in a scanner. A stepper motor has multiple coil windings and when a motor winding is activated in the proper order, the motor shaft rotates a few degrees and stops (i.e., a step). For stepper motors, there are special purpose stepper motor driver ICs that contain all of the drivers and logic interface circuits required. A stepper motor typically has two motor windings and they can be controlled by using two H-bridge circuits. Newer stepper motor driver ICs also contain a state machine or firmware that automatically accelerates and decelerates the stepper motor movements using PWM. Stepper motor driver ICs also are available with SPI, I2C, and LIN interfaces. A Phidgets USB-based stepper motor controller board that can control and drive up to four stepper motors is seen in Figure 3.13.
Figure 3.13 This USB-based stepper motor controller board can control up to four stepper motors. Photograph courtesy of Phidgets (www.phidgets.com)
84
AC devices can be controlled using mechanical relays, optically isolated TRIACs, and preassembled solid state relay modules. Some AC devices, such as lights can be dimmed by turning on the device at a controllable voltage threshold. Solid state relays typically have some extra circuitry to reduce the RF noise emissions that occur when switching a high current load. Figure 3.14 shows a solid state relay module. It is controlled by a digital logic level input signal and it can control a 120V AC 10 amp device. For optical isolation, an optical control signal is used to isolate the low voltage DC input circuit from the higher voltage AC output circuit. Even a momentary short of high voltage AC line to a digital output will destroy low voltage DC circuits.
Figure 3.14 This optically isolated solid state relay module can control a 120V AC 10 Amp circuit using a digital logic input signal. Photograph courtesy of Opto22.
When controlling mechanical systems with valves, solenoids, and relays, hysteresis may need to be added to reduce the number of on/off cycles. As an example, a thermostat with hysteresis used for temperature control of a heater would turn off at a temperature a couple of degrees higher than the temperature it turns on at. If the same temperature was used for the on/off decision, it would constantly cycle on and off. Many mechanical actuators are lifetime rated based on the number of cycles, so less cycling through the use of hysteresis extends their life. Constant cycling can also increase noise and greatly reduce power efficiency in some systems. In embedded system industrial automation applications, there are frequently a mixture of DC and AC inputs and outputs to control and sense. The number of signals of each type varies widely for each application.
85
Figure 3.15 This Programmable Automation Controller (PACs) contains a controller (processor) and several I/O modules. The user can select and assemble the AC, DC, and digital I/O modules needed for each application. Photograph courtesy of Opto22.
As seen in Figure 3.15, many commercial Data Acquisition Systems (DAQs) and Programmable Automation Controllers (PACs) contain a controller and several I/O modules. These I/O modules also contain the required interface circuits to drive large loads and sense different voltages. The user can select and assemble the AC and DC I/O modules or cards needed for each application. This approach offers flexibility for systems with a large number of assorted AC and DC I/O signals. They are widely used in industrial automation and control.
3.15 CAN and LIN Network Interfaces

The Controller Area Network (CAN) is a serial network was developed by Bosch and Mercedes in the mid 1980s to interface multiple controllers in a car (www.can.bosch.com). It can support data rates up to 1M baud and up to 110 devices. There are two CAN standards, ISO 11519 has a 125K baud limit and ISO 11898 has a 1M baud limit. CAN is widely used in the automotive industry and given the widespread availability of CAN support chips, it now can also be found in many embedded devices.
86
It is a multiple-master type bus with collision detection and bus arbitration somewhat similar to Ethernet. Instead of containing address information, CAN messages contain a unique message number and lower number messages have higher priority whenever two masters need the bus at the same time. Part-A CAN controllers support 11-bit message identifiers and Part-B supports 11 or 29-bit message identifiers. Each device on the bus checks the message number and determines if it needs to read the message off of the bus.
Message Frame
Bus Idle
Arbitration Field
Control
Data Field
CRC Field
ACK
EOF
Int
Bus Idle
SOF 11 Bit Identifier RTR r1 r0
D LC Data (0-8 Bytes) 15 Bits
Slot
D elimiter
Figure 3.16 A CAN 2.0A Message Frame
The CAN Version 2.0A Message Frame shown in Figure 3.16 consists of seven different bit fields: The Start of Frame (SOF) field. A 0 bit that indicates the beginning of a message frame. The message and arbitration field, containing an 11-bit message identifier and the Remote Transmission Request (RTR) bit. If RTR is 0, the bit indicates that the message is a Data Frame. A 1 value indicates that the message is a Remote Transmission Request. A Remote Frame is a (read) request by one node for data from some other node on the bus. Remote Frames do not contain a Data Field, another message sent in response will contain the data. A Control Field containing six bits. The two most significant bits (r0 and r1) are not currently used. The four-bit Data Length Code (DLC) indicates the number of data bytes in the message The Data Field contains from zero to eight bytes of data. The cyclic redundancy code (CRC) field contains both a 15-bit CRC error code and a 1 delimiter bit The acknowledge (ACK) field, consists of two bits. The Slot bit, which is transmitted as a 1 bit, but is subsequently over written by dominant bits transmitted from all other nodes that successfully receive the message. The second bit is a 1 delimiter bit The End of Frame (EOF) field, consists of seven 1 bits. Following the end of a frame is the intermission (INT) field consisting of three 1 bits. After the 3-bit INT period, the bus is free. A new bus cycle can start anytime following the INT period.
87
CAN is ideally suited for applications that need high-speed transfers with short message lengths. It has faster data rates, higher noise immunity, and more error detection than the older serial standards such as RS-232. A faulty node also attempts to isolate itself from the bus. Two signal wires are used, CAN-high and CAN-low. They operate in differential mode. Wire lengths can be tens of meters long at the highest baud rates and the ends of the bus are terminated with a resistor (typically 120 ohms) to reduce reflections. 3.15.1 LIN network interface There is also a newer lower cost, lower voltage, and lower data rate (20K baud) serial bus standard intended for use at levels below CAN in automobiles. It is called the local interconnect network (LIN). LIN is intended to interface a subsystem processor to its smart sensors while CAN is used to connect the subsystems together at a higher level. LIN can be supported using a standard serial UART and microcontroller firmware or with special ICs. LIN (ISO9141) has only 1 bus master with up to 15 slaves, uses only 1 signal wire, and does not require crystal oscillators in each device (www.lin-subbus.org).
Message Frame
Header
Response
Sync Break
Sync F ield
Ident F ield
Data F ield
Data Field
Data F ield
Data Field
Interbyte Space In_Frame Response Space
CheckSum F ield Interframe Space or Break
Figure 3.17 A Typical LIN Frame Consisting of Synch Break, Synch Field, Identifier, Data Field and Checksum.
Each byte of data in the frame as seen in Figure 3.17 follows a standard 10-bit serial format (i.e., start bit, eight data bits, stop bit). A frame consists of the following fields: Sync Break (sent by LIN Master) o At least 13 bits - Start of frame o Sync Field (LIN Master Task) o 1 bit - Synch Delimiter o 0x55 (8-bit data, start & stop bits) Used to synchronize
88
Identifier Field (sent by LIN Master) o 8 bit data, start & stop bits o Bits 0 to 3 - LIN ID o Bits 4 to 5 - Length Control o Bits 6 to 7 Parity Data Field (sent by LIN Slave) 2, 4 or 8 bytes (each 8-bit data, start & stop bits) Checksum 8 bits (sent by LIN Slave)
3.16 For Additional Information

Appendix E contains the pin assignment information for several of the most commonly used I/O connectors. The books Parallel Port Complete and Serial Port Complete by Jan Axelson published by Lakeview Research (www.lvr.com) contain complete details on using parallel and serial ports. When debugging a serial device connected to a desktop PC, the RealTerm Terminal Emulator displays more information and supports more data formats than the HyperTerminal program included with Windows XP. It is available for download free at: http://realterm.sourceforge.net/ To test and debug I 2 C or SPI devices a low-cost USB/serial to I 2C/SPI adapter that works with RealTerm is available from: http://i2cchip.com. Many new oscilloscopes also decode I 2 C and SPI (see exercise 1). The IBM PS/2 Hardware Interface Technical Reference Manual, IBM Corporation, 1988 contains the original PS/2 information on the keyboard and mouse in the Keyboard and Auxiliary Device Controller Chapter. The book, Rapid Prototyping of Digital Systems by James Hamblen also contains parallel, serial, and additional PS/2 information including scan codes, commands, and data packet formats. Scan codes normally used by the PC can be also found on the web and in many PC reference manuals. The Indispensable PC Hardware Book 4th Edition by Hans-Peter Messmer has many additional details on legacy PC hardware. The full I 2 C specification is available from NXP formerly known as Philips Semiconductors (www.nxp.com) and SMB at (www.smbus.org). The Motorola MC68HC11 data manual (www.freescale.com) and various National Semiconductor manuals (www.national.com) have more information on SPI. Analog Devices (www.analogdevices.com) makes a wide variety of low-cost A/D and D/A converters with SPI and parallel interfaces. The USB Implementers Forum was founded by the companies that developed the USB specification www.usb.org. The free USB in a Nutshell Manual http://www.beyondlogic.org/usbnutshell/usb1.htm. is available at
89
The books USB Complete by Jan Axelson, and USB Design by Example by John Hyde contain additional information on building USB devices. Shared source code projects for CE including Web Cam and Phidgets USB drivers are available at http://msdn2.microsoft.com/enus/embedded/aa731151.aspx ,

1. If the ASCII character a was being sent out on a serial device, draw a picture of the signal that you would see on a RS-232 serial line as all of the data associated with that character is transmitted. Draw a graph similar to what would be displayed on an oscilloscope (i.e., voltage vs. time). 2. Many of the newer Logic Analyzers and multi-channel oscilloscopes are embedded devices that have built-in or optional software to decode and display RS232, SPI, I2C, USB, CAN, or LIN bus signals as seen in Figures 3.18 & 3.19. If such test equipment is available, find a device with one of these interfaces and capture some data from the bus while the device is operating. 3. If you have one of the low-cost USB/Serial to I2C/SPI adapters available (http://i2cchip.com) or another device with similar capabilities, attach it to an interesting I2C or SPI sensor. Run the RealTerm application on a Desktop PC, send commands to the sensor, and capture some data readings from the sensor. 4. Using one of the software or hardware-based USB Protocol Analyzers, capture some USB packets from a USB device attached to a desktop PC. Try to explain the significance of the packets.
90
Figure 3.18 The Tektronix DPO7000 1-4 Channel Oscilloscope is an embedded device that runs Windows XP. The display above is from an optional software package for the oscilloscope that decodes and displays SPI bus signals. Images courtesy of Prodigy Test Solutions.
91
Figure 3.19 The Tektronix DPO7000 1-4 Channel Oscilloscope is an embedded device that runs Windows XP. The display above is from an optional software package for the oscilloscope that decodes and displays I2 C bus signals. Images courtesy of Prodigy Test Solutions.
CHAPTER 4
Network Interface Standards
This Ovation2 iX Gas Pump runs Windows Embedded CE. It is networked to a back office server to handle credit card transactions and to provide remote diagnostics and maintenance information. The display can also play video ads and take food orders while you fill up. Photograph courtesy of Dresser Wayne.
94
4 Network Interface Standards

Networking is an important feature in many of todays embedded devices. The first working Ethernet network was developed in 1973 by Bob Metcalfe at Xerox's Palo Alto Research Center. The network used eight-bit address fields and only ran at 3 Mbits/s, but the general design of today's systems could already be seen in Metcalfe's original work. What started as a means of connecting a computer to a printer soon was on its way to becoming the most popular method of networking computers. By the end of 1980, DEC, Intel, and Xerox placed their support behind Ethernet connections when they decided to come together to promote an Ethernet standard. The standard became known as the "DIX" standard for "DEC/Intel/Xerox". The DIX standard set the source and destination addresses each at 48-bits and transmitted data at 10 Mbits/s. The DIX standard would set the basic foundation for all future Ethernet standards. Since 1980, the Ethernet standard has continually been redeveloped to incorporate new technologies and the increasing speeds of networks (100 Mbps, 1 Gbps). The current standard for Ethernet connections is the IEEE 802.3-2005. The Institute of Electrical and Electronics Engineers (IEEE) developed their original IEEE 802.3 standard in 1983. The 802.3 standard has been revised every few years with major revisions to the base standard occurring in 1998, 2002, and 2005. Ethernet controller chips are widely used in embedded devices. On the eBox 4300, the Ethernet controller chip directly attaches to the PCI bus.
4.1 Ethernet Terminology

To better understand Ethernet connections, there are several important terms that need to be defined and understood. Medium The medium connects Ethernet devices along a common path and transports the device signals. The medium is usually a twisted pair wire or a fiber optic cable. Segment A segment refers to a single shared medium. Node Devices that attach to a segment are stations or nodes. Nodes are either transmitting or receiving at any given time. Frame Frames are variable sized pieces of information that are exchanged between nodes. A frame is the minimum amount of information that can be exchanged. Protocol An Ethernet protocol is a set of rules that govern the construction and interpretation of frames.
95
Ethernet is used primarily for local area network (LAN) connections. Ethernet networks are mostly confined to a single building or small area. Limits for running Ethernet lines are set at a few hundred feet for most connections, but recent advancements have allowed Ethernet connections to reach up to several miles away. Ethernet devices in a specific network must all follow the same protocol in order to communicate successfully. The protocol specifies the minimum and maximum lengths for frames, and set what information is required to appear in the frame. For example, typical frames include both a source address and a destination address along with the data being sent. Each device connected to the network should have its own address to allow for its unique identification from other devices.
4.2 Frame Types

There are several types of Ethernet frames. The following four are the most common frame types: 1. DIX frame (Ethernet Ver. 2 or Ethernet II) the most common, used directly by IP 2. Novell's 802.3 frame ("raw 802.3") IEEE 802.3 without IEEE 802.2 LLC 3. IEEE 802.2 Logical Link Control (LLC) frame 4. IEEE 802.2 LLC/Subnetwork Access Protocol(LLC/SNAP) frame Different frame types have different formats and Maximum Transmission Unit (MTU) values, but can coexist on the same physical medium. For communication, all that is needed is the source and destination nodes be able to understand the same protocol. Frames are divided up into specific regions. Each frame type has rules for what order and size the regions can be. These regions for a DIX frame are shown in Figure 4.1.
Preamble 56 bits of alternating Is and Os. SFD Start field delimiter, flag (10101011) Destination Address 6 bytes Source Address 6 bytes Length PDU 2 bytes
Preamble 7 bytes
SFD 1 byte
Data and Padding 46 to 1500 bytes
CRC 4 bytes
Figure 4.1 An Ethernet Frame showing the subfields.
96
The regions are defined as: 1. 2. 3. 4. 5. Preamble - 56-bit start region, denotes the beginning of a Ethernet frame SFD - Start Frame Delimiter, 8-bit value marking the end of the preamble Destination MAC Address 48-bit address denoting were data is headed Source MAC Address 48-bit address denoting were data came from Length/Type Protocol Data Unit - 16-bit sub-protocol label field for length or protocol type (length in bytes only if less than 1518) 6. Payload The data being sent 7. CRC (or Frame Check Sequence), a CRC value computed on the entire frame. Used to detect bit errors occurring during transmission. For an IEEE 802.2 LLC frame, the same format is used but the Ethertype is used as a length field and is followed by a LLC header. The LLC header tells software if a frame is a DIX frame or IEEE 802.3 frame. All 802.3 frames must have the LLC header. By examining this header, it is also possible to determine whether a LCC header is followed by a SNAP header. The LLC header is made up of two additional eight-bit address fields, called service access points (SAP). When both source and destination SAP are set to the value 0xAA, the SNAP service is requested. The SNAP header allows EtherType values to be used with all IEEE 802 protocols, as well as supporting private protocol ID spaces. In IEEE 802.3x-1997, the IEEE Ethernet standard was changed to explicitly allow the use of the 16-bit field after the MAC addresses to be used as a length field or a type field.
4.3 CSMA/CD over a Shared Medium Ethernet

Originally, Ethernet was used over a shared coaxial cable medium that was attached to every machine on the network. This can be seen in Figure 4.2.
P ri nter Com puter
Ethernet Medium
Com pu ter
Com puter
Figure 4.2 A Small Ethernet Network
97
In order for communication to occur, a process called carrier sense multiple access with collision detection (CSMA/CD) was developed. The process provided a simple technique for all the devices on the network to share the medium for communication. CSMA/CD for each node works as follows: Main Process 1. Frame ready for transmission 2. Check to see if medium is idle. If not, wait until it is. 3. Start transmitting 4. Check if a collision is occurring. If so, go to Collision Process. 5. End successful transmission Collision Process 1. Continue transmission for short period of time to produce collision. 2. Stop and wait random period. 3. Re-enter Main Process. A common analogy would be to think of a dinner table with several people sitting down. They share a common medium (the air) in order to communicate. In order to speak, each person must wait until the current speaker stops. If two people start taking at once, each stops and waits a short, random time before attempting to speak again. By choosing a random time, it is less likely that their will be another collision. A drawback of this procedure is that any frame sent out to the mediu m is received by all nodes connected to that medium. This creates a security risk for shared-medium Ethernet. Also the use of a single medium means the bandwidth is shared. This creates a slowdown when many devices try to use the medium at the same time.
4.4 Segmentation, Bridges, and Routers

As Ethernet devices on a single medium increase in number, the network is faced with congestion problems. Congestion causes more collisions to occur and successful transmissions to decrease. Segmentation is splitting a single segment into multiple segments to reduce congestion. But this solution creates another problem of communicating across segments. This is where bridges and routers come in. Bridges are used to connect two or more segments on a network. They send and receive transmissions like any other node on the network but are different in two ways. The first is that it does not originate any frames of its own, and the second is the way in which it connects the segments it is connected to. In Figure 4.3, if Computer A were to send out a frame, the bridge would receive the frame and examine it. Only if the destination node was C or D, would it transmit the frame onto the segment 2. Additionally, by filtering packets when appropriate, the bridge makes it possible for station A to transmit to station B at the same time that station C transmits to station D, allowing two conversations to occur at the same time.
98
Statio n
S tati on
A
Bridge Segment 1 Segment 2
S tati on
S tati on
Figure 4.3 An Ethernet Bridge Connection Two Segments.
An important characteristic of bridge operation is that they forward Ethernet broadcasts to all connected segments. This behavior is necessary because Ethernet broadcasts are a special signal that needs to be sent to every node on the network, but it can pose problems for bridged networks that grow too large. When a large number of stations broadcast on a bridged network, congestion can increase to the same level as on a non-bridged network. Routers provide an alternative to this problem. Routers are advanced networking components that divide a single network into two logically separate networks. While Ethernet broadcasts cross bridges to reach every node on the network, they do not cross routers because the router forms a logical boundary for the network.
4.5 The TCP/IP Network Protocol

TCP/IP is a family of communication protocols named for the main protocols in the group: Transmission Control Protocol (TCP) and Internet Protocol (IP). In 1973, work first began on what was to become the TCP/IP protocol set. The goal of the project was to develop a software-based set of protocols that could allow any system to connect to any other system regardless of the network topology used. The creation and widespread use of the TCP/IP suite produced a major change in the way computer networking was handled. Before TCP/IP, networks used a hardware-based system to send data through the network. This meant that all data had to pass through a central processing center to be examined before it could be sent to its final destination. TCP/IP allowed individual nodes to talk directly to any other node on the network. The advantage of this design is that it allowed devices to overcome most of their hardware-based incompatibilities and greatly increase application and resource sharing.
99
The design of the TCP/IP suite is based on the idea of encapsulation of data for different levels of use. TCP/IP is broken down into roughly four layers as follows: 1. 2. 3. 4. Application Protocols HTTP, SMTP, SSH, etc. Transport Protocols TCP, UDP Network Communication Protocols IP Network Topology Ethernet, Wi-Fi, Token Ring, etc.
The layers provide abstraction that allows lowers layers to provide basic services while higher layers handle more complicated functions. As can be seen in Figure 4.4 below, each lower layer encapsulates the information from the layer above it. When information in a particular layer reaches its destination, the headers are removed and the data is passed up to the next layer. For example, when a frame reaches its destination node, the frame encapsulation is removed and passed to the IP decoder.
Data T CP Header IP Header Frame Header TCP Data
Application Protocols
Transport Pr otocols
IP Data Frame Trailer
Internet Pr otocols
Frame Data
Network Topology
Figure 4.4 Network Protocol Layers
4.6 Application Protocols

Application protocols handle what the user sends and receives. The application layer is the top-most layer in the TCP/IP design. It is used mainly by programs for the end user and network communication. In this layer, data is formatted for a specific protocol. For example, most web page data will use Hypertext Transmission Protocol (HTTP). After the data is formatted, it is encapsulated into a transport layer protocol and passed down the TCP/IP hierarchy.
100
4.7 Transport Protocols

Transport protocols handle end-to-end message transfers independent of underlying network connections. The transport layer connects applications and provides flow control, error control, and session management. The two major transport protocols are TCP and User Datagram Protocol (UDP). TCP provides a "connection-oriented" protocol that is highly monitored and reliable. TCP tries to maintain a reliable byte-stream by making sure that data arrives in-order, duplicate data is discarded, and lost packets are resent. UDP is a "connectionless" protocol that provides a best-effort delivery system. UPD uses only a simple checksum algorithm for error detection. UPD is used mainly for applications like streaming media where on-time delivery is more important than reliability.
4.8 Network Communication Protocols

Network communication protocols are represented by IP. IP gets data packets from the source node to the destination node. Each device is assigned a 32-bit unique IP address. Devices on the same subnet share upper address bits. IP's responsibilities are tracking addresses of devices on the network, determining how IP datagrams are to be delivered, and sending IP packets from one node to another. IP only provides best effort delivery of packets and it does no error checking or tracking.
4.9 Network Topology

The network topology is simply the path connecting the nodes in the network. It is the physical medium that provides the base layer for TCP/IP to move across. This layer is made up of cables, network cards, hubs, repeaters, and other connection devices.
4.10 Software support for Networking

Ethernet hardware controllers automatically buffer and transfer packets. When input packet buffers fill or output packet buffers empty, an interrupt is generated by the Ethernet controller. Direct Memory Access (DMA) is often used to transfer packet data in these buffers to/from system memory. A device driver specific to the network interface hardware typically handles these issues. Low level software routines are needed to assemble/extract data in packets, compute error codes, and initiate the transfer of packets to/from the Ethernet controller. The eBox 4300 contains a Realtek 8100B 10/100Mb single chip Ethernet controller that attaches to the PCI bus. Operating systems that provide support for networking implement the higher level protocols (such as TCP/IP, UDP, FTP, HTTP) in software and provide the appropriate function calls for use in user applications. Many operating syst ems support networked file systems. The support provided for networking represents a significant portion of the code in an operating system. Some common network related applications programs such as web browsers and ftp clients may also be provided with the operating system or available from third party vendors.
101
Windows Embedded CE supports Windows Sockets ( Winsock). Winsock specifies a programming interface based on the "socket" interface from the University of California at Berkeley. There are many Windows Sockets applications available. A number of the utilities that ship with Windows Embedded CE are based on Windows Sockets, including the FTP, DHCP, and Telnet clients. There are also higher-level programming interfaces that rely on Windows Sockets, such as the Windows Internet API ( WinInet) used by Internet Explorer that provide support for FTP and HTTP services. A sample browser, media player, and messenger application is included with CE.
4.11 Wireless Networking Standards

Several wireless standards are already in widespread use in embedded devices. These wireless technologies include WiFi, Bluetooth, and ZigBee. The features and capabilities of these three main wireless standards are summarized in Table 4.1. Drivers for selected WiFi and Bluetooth devices are available for CE. 4.11.1 WiFi or IEEE Standard 802.11x (www.wifialliance.com) is currently the most widely available wireless local area networking standard. It was intended to provide a wireless alternative to a hardwired Ethernet connection. 802.11b and 802.11g use the 2.4GHz band and 802.11a uses the 5GHz band. WiFi has the longest range, the highest bandwidth, and the highest power requirements of the three wireless standards. 4.11.2 Bluetooth or IEEE Standard 802.15.1 Bluetooth wireless technology or IEEE Standard 802.15.1 (www.bluetooth.org) is a short-range communications system intended to replace the cables connecting portable and/or fixed electronic devices. It was originally developed by the cell phone industry for a personal area network. Bluetooth operates in the unlicensed band at 2.4GHz. 4.11.3 ZigBee or IEEE Standard 802.15.4 ZigBee or IEEE Standard 802.15.4 (www.zigbee.org) is the name of the specification for a suite of communication protocols using small, low-power digital radios for wireless personal area networks (WPANs). ZigBee is intended for use in embedded devices requiring low data rates and low power consumption. ZigBee can be used to setup a low-cost self-organizing mesh network using very low power levels, so that battery operated devices can have long lifetimes. ZigBee operates in several of the industrial, scie ntific and medical radio bands (868 MHz in Europe, 915 MHz in the USA and 2.4 GHz in most countries worldwide). Most wireless devices use the same unlicensed frequency bands and these bands are also used by other devices such as cordless phones and microwave ovens. WiFi and Bluetooth use frequency hopping techniques and different channels to minimize interference. Interference can still be a problem, if a large number of active wireless devices are in very close proximity to each other. Numerous other new wireless standards are also appearing rapidly such as Wireless USB, WAVE, and WiBree. Cell phone data modems are also available.
102
Table 4.1 Features of the three major wireless network standards. Feature Application Area Target Cost Memory Requirement Battery Life Network Size Peak Data Rate 802.11b/WiFi Web, Email, Video $25 1MB+ .5-5 Days 11,000+ 1, 2, 5.5, 11, (54-802.11g) Mbps 802.15.1/Bluetooth Cable Replacement $15 250KB 1-7 Days 7 1Mbps 802.15.4/ZigBee Control & Monitoring $5 4KB - 32KB+ 100-1000 Days 20-250 250 Kbps @ 2.4 GHz 40 Kbps @ 915 MHz 20 Kbps @ 868 MHz 60 mW active @ 0 dBm 52000 mW sleep (mode dependent) 0 dB 85 dBm 92 dBm @ 868/915 MHz ~50 m @ 0 dBm ~10 m @ 0 dBm
Power Consumption (targeted) Adjacent Channel Rejection Receiver Sensitivity Range Line of Sight Range Indoor (approx.) Number of Channels Modulation Technique
1.5 W active @ 20 dBm 45 mW sleep >35 dB 80 dBm
80 mW active @ 0 dBm 100 mW sleep 0 dB 70 dBm
~200 m @ 11 Mbps ~500 m @ 1 Mbps ~40 m @ 11 Mbps ~100 m @ 1 Mbps 11 - DSSS 79 - FHSS GFSKFHSS BPSK/QPSKDSSS 20 dBmFHSS 30 dBmDSSS
~30 m ~100 m, Class 1 ~10 m ~30 m, Class 1 79
GFSK
Maximum Transmit Power
20 dBm
16 @ 2.4 GHz 10 @ 915 MHz 1 @ 868 MHz O-QPSK @ 2.4 GHz BPSK @ 868/915 MHz 30 dBm
103

The books TCP/IP Protocol Suite by Behrouz A. Forouzan and The Pocket Guide to TCP/IP Sockets by Kenneth L. Calvert contain more complete information on Ethernet networks, protocols, and programming with sockets. The book, Programming Microsoft Windows CE .Net, Third Edition by Douglas Boling published by Microsoft Press contains additional details on developing Windows Embedded CE application programs that use networking APIs in Chapter 14.

1. Install the free Ethereal Network protocol analyzer software on a desktop PC (http://www.ethereal.com). Capture a series of packets as you browse a simple web page. Explain the significance of each packet. Select one of the packets with data and describe the contents of the sub fields in the packet.
Figure 4.5 The free Ethereal Network Protocol Analyzer capturing and decoding network traffic on a desktop PC. The PC has just loaded a short web page from a remote server (see HTTP packets above).www.ethereal.com
CHAPTER 5
The eBox 4300 SoC Embedded Computer System
The eBox 4300 MSJK is a small low-cost X86 System on a Chip (SoC) based embedded computer system that will be used as a Windows Embedded CE target device. It has a full range of I/O features. Photograph courtesy of ICOP Corporation.
106
5 The eBox 4300 Embedded Computer System

The eBox 4300 seen in Figure 5.1 is one of a family of several small low-cost X86 embedded computer systems. The eBox 4300 is the newest member of the eBox family. Despite its small size of 4.5 by 4.5 inches, it contains many of the hardware features found in a desktop PC. The processor in the eBox 4300 is an X86 compatible 500Mhz VIA Eden processor. The processor is slower than current generation desktop PCs, but it draws significantly less power than a desktop PC and does not require any cooling fans. A typical desktop PC can require up to 700W maximum and the eBox is less than 15W maximum. It has 512MB of SDRAM system memory, a PC-style AMI Bios, and a 256MB internal Flash drive (ho lds the DOS boot loader and OS). Since the hardware is PC compatible, it is capable of running several of the popular operating systems including Windows XP, Windows CE, and Linux. It runs on external 5V DC 3A power provided by an AC wall adapter that comes packaged with the eBox.
Figure 5.1 eBox 4300 X86 Embedded Computer System. Photograph courtesy of ICOP.
5.1 Architecture of the eBox 4300

The eBox has all of the basic I/O devices typically found on a desktop PC. The I/O connectors on the back panel are seen in Figure 5.2. It has both a PS/2 keyboard and mouse input (requires a PS/2 Y cable), and a standard VGA output. A standard PC keyboard, mouse, and a VGA monitor would typically be connected to the eBox while debugging. The 4300 MSJK model has two RS232C serial ports (COM1 & COM2). It has 2 USB 2.0 connectors, a CF card slot, and AC97 audio on the front panel as seen in Figure 5.1. The power rocker switch on the back panel shown in Figure 5.2 turns off the eBox. One additional USB 2.0 connector is available on the back panel. The reset/power switch on the front also turns on and off the eBox, but it has wake on LAN activity set by default and this enables it to turn back on by itself unless the power rocker switch in the back is turned off. It has an internal
107
10/100Mbs Ethernet interface. A mini-PCI slot on the bottom on the processor board can support an optional internal wireless card with an external antenna.
Figure 5.2 eBox 4300 back panel view showing I/O connectors and power switch. Photograph courtesy of ICOP.
Inside the eBox with the top cover removed, you can see the computer board and main components in Figure 5.3. The bottom side of the board contains the flash drive, an internal mini PCI slot for the optional wireless board, and the other I/O chips.
PS/2, USB, VGA, serial, & Network connectors VIA Eden X86 Processor
Ethernet Controller
BIOS ROM CF card slot
VIA CX700 Media Processor 512MB SDRAM
Bottom of PCB: Flash, Mini PCI slot & other ICs
Figure 5.3 View inside the eBox 4300 with the top cover removed. The VIA Eden processor (right center) and larger CX700 media processor chip (center) are visible along with 512M RAM (lower right), network controller chip (upper right), BIOS chip (center left), and CF card slot (lower left).
108
The top cover of the eBox also serves as a heat sink for the processor which helps to eliminate the need for a power hungry and unreliable cooling fan. It is probably not a good idea to place a book or other object on top of the eBox for long periods of time while it is running since this would reduce the air flow to the heat sink. Fans are typically avoided whenever possible in embedded devices since they consume quite a bit of power and have a high failure rate over the life of a device. Cables are provided to connect the eBox to a desktop PC that serves as a software development system. Windows Embedded CE 6.0 running in Visual Studio 2005 can download and debug a new operating system and application programs over the network connection. A network crossover cable is provided with the eBox to connect the eBox directly to the desktop PC s network jack without the need for a hub or switch. If a hub or a switch is used to connect to the eBox, a normal network cable (without a crossover) will likely be required. In Windows Embedded CE, debug information is available from COM1 and a serial null modem cable is provided with the eBox to connect COM1 on the eBox to a COM port on the desktop PC to view this debug information. Additional I/O devices would typically be connected first to the COM2: port. On the eBox 4300, the CE serial debug messages are disabled by default. In a headless device when networking is not provided or functional the serial debug messages can still be very useful. The 500 MHz VIA Eden ULV X86 processor and CX700 System Media processor are used in the eBox 4300. A block diagram of a typical low-power X86 computer system built using the VIA Eden processor and the CX700 System Media Processor is seen in Figure 5.4. The CX700 combines the traditional Northbridge, Southbridge, and VGA video controller functions in a single chip. These two chips provide all of the features found on a typical PC motherboard. On a typical PC, the Northbridge and Southbridge chips are the two large chips found soldered directly to the motherboard. Note that it contains many of the busses and I/O devices that were discussed in earlier sections. LPC is the low pin count bus standard for circuit boards based on the ISA bus.
109
Figure 5.4 A block diagram showing all of the features possible and the basic architecture of the VIA Eden/CX700 Chipset. These two chips are used in the eBox 4300. Image courtesy of VIA.
The features of the VIA Eden/CX700 chipset that are implemented in the eBox 4300 are summarized in Table 5.1. The I/O features typically found on a traditional desktop PC are all present.
110
Table 5.1 Features of the eBox 4300. CPU BIOS System Chipset I/O Chipset System Memory Expansion Cards I/O Features 1 x EIDE (44-pin Ultra DMA 133) 2 x RS-232 (optional), 1x PS/2 for K/B and Mouse 1 x RJ-45 Ethernet Connector 1 x Type I/II Compact Flash slot 3 x USB 2.0 Ports (two in front) VIA Vinyl VT1708 AC97 2.2 Codec VIA Eden ULV 500MHz AMI BIOS VIA CX700M Winbond W83697 onboard 512MB DDR2 RAM 1x Mini-PCI internal slot (optional)
MIO
USB Audio VGA Display Chipset Resolution Display Memory Ethernet Interface Remote Boot ROM Chipset Power
Integrated VIA UniChrome Pro II 2D/3D Graphics with MPEG4/WMV9 decoding accelerator Up to 1920 x 1440 Up to 128 MB shared system memory
Built-in boot ROM function, supports PXE boot and Wake-up on LAN Realtek 8100B 10/100 Base-T 5V DC at 3 Amps max (<15Watts)
5.2 Booting the eBox

At power up, the eBox executes initialization code from the BIOS ROM just like a desktop PC. At the factory, several files were preloaded on the internal flash drive to boot Windows Embedded CE. The Flash drives files are setup to automatically load DOS and run an AUTOEXEC.BAT batch file that provides
111
the user with several menu options. The menu options include, load a local copy of the OS from the Flashs NK.BIN file, attempt a network boot from the desktop PC using DHCP, or attempt a network boot using a static IP address. For the network connection and boot process to work, the desktop PC and the eBox must be on the same subnet (i.e., only the last number in the IP address can be different, the others must be the same). The DOS program LOADCEPC then loads the new OS file over the network. Each eBox is assigned a unique network device name. If there are several eBoxes running on the same subnet in your lab, be sure to connect to the correct one. Be careful not to erase the files on the flash drive or your eBox will not connect and boot properly. It is possible to restore these files by using a specially formatted bootable external USB Flash drive to initially boot the eBox and then manually copy the factory default files back to the internal flash (see Appendix C for details). The NK.BIN file on the Flash can be replaced with a newer version for standalone operation, once a new design has been debugged and tested. It is a good idea to rename the old NK.BIN file first, so that you can restore it in case of problems.
Figure 5.5 The eBox VGA display output after successfully booting Windows Embedded CE 6.0.
The boot process for the eBox, while normal for a PC and great for software development work, is a bit atypical of what would be found in many embedded devices. In an actual deployed embedded device, the operating system would
112
likely load directly using a ROM boot loader program (i.e., no BIOS and no DOS). This boots faster, saves memory and storage, and costs less since license fees are not required to run BIOS and DOS on each device. Sample ROM boot loader code is typically provided with the OS and adapted for the each device by the OEM. Table 5.2 eBox 4300 Device Drivers for Windows Embedded CE 6.0 eBeBox-4300 Peripherals VIA CN/CX Display VIA HD Audio VIA UAM3059 Audio Ethernet (RealTek-8100) Serial Ports USB Ports (USB 2.0 Host) CompactFlash Card (not hot swappable on eBox) IDE Optional Devices for eBox Internal 802.11 Wireless Card (VIA VT6655 - US only) USB Flash Drive Enfora GSM1218 Cell Phone Modem USB Web Camera - optional (USB Video Class 1.1) Phidgets USB I/O, sensors and LCD Serial GPS receiver Xenarc VGA LCD USB touch panel VIA VT6655 (Driver provided by VIA & ICOP) USB Storage Class (CE Driver provided) Enfora (CE RIL Driver available in CEPC) Both CE and shared source code drivers are available Shared source code driver available CE GPS Intermediate Driver Touch Input Driver provided with LCD CE 6.0 Device Drivers eBox-4300 display driver (Driver included in eBox 4300 BSP) eBox-4300 HD audio driver (Driver included in eBox 4300 BSP) eBox-4300 Unified audio driver (Driver included in eBox 4300 BSP) RTL8139 (CE Driver provided) Com16550 (CE Driver provided) USB host drivers (CE Driver provided) ATAPI (CE Driver provided) ATAPI (CE Driver provided)
A full complement of I/O device drivers is available for the eBox 4300, as seen in Table 5.2. Many of the drivers are provided with CE 6.0 and some are provided by the semiconductor vendors, or with the free ICOP eBox Board
113
Support Package (BSP). The full details on obtaining, installing, and using the drivers available for the optional devices listed are provided later in this text.
5.3 Interfacing external hardware to the eBox

Many embedded devices need to interface additional external hardware and signals to the computer. These signals can be both analog and digital. Analog signals will need A/D or D/A converters to interface to a digital computer. The easiest way to interface external hardware to a computer is to use a GPIO port or a parallel port. Due to size and cost constraints, the small eBox does not have these types of interfaces available externally. The remaining two options available are USB and Serial devices. We will examine some of the commercial general purpose I/O devices available that support USB and serial interfaces.
5.4 Interfacing external hardware using USB

USB devices will typically need a device driver specific to each device. For Windows Embedded CE 6.0, the device driver needs to be available in an X86 CE 6.0 compatible version. This limits current choices a bit since the new CE 6.0 R2 version was recently released, but more options will appear in time. Fortunately, there are two existing USB devices with a shared source community code project for the required CE USB device driver.
Figure 5.6 Phidgets support digital and analog I/O with a wide range of sensor modules.
Phidgets are a family of USB-based digital and analog I/O interfaces and sensors designed for robotics and electronics hobbyists. A shared source code driver is available for Phidget devices. The more common Phidget modules include devices for both analog and digital I/O. Sensors and modules provide support for radio control (R/C) servos, rotation sensors, motion sensors, temperature sensors, humidity sensors, RFID, and GPS. Other sensors can be interfaced to the general purpose digital and analog I/O card. For additional
114
information on this and other shared source code projects for CE, see http://msdn2.microsoft.com/en-us/embedded/aa731151.aspx Another option is a USB device that functions using a virtual com port driver. Several devices containing FTDI chips operate in this manner that have both analog and digital I/O features with firmware that responds to commands sent out on a virtual communications port. The 245PBT module shown below includes a USB microcontroller and a PIC microcontroller mounted on a 40-pin DIP adapter module (www.DLPdesign.com/usb). It supports digital I/O and analog inputs. It can plug into a standard electronics protoboard.
Figure 5.7 The DLP D245PB-G has a USB microcontroller and a PIC I/O microcontroller.
5.5 Interfacing a USB Web Camera

Many embedded devices need still images or video camera inputs. A shared source community project with a USB driver for Windows Embedded CE is available for the low-cost Logitech QuickCAM Pro 5000 USB web camera. This driver was originally developed using the Logitech QuickCam Pro 5000, but it is reported to work on the QuickCam Fusion, MP, Ultra Vision, Pro 9000, Pro for Notebooks, Communicate Deluxe, Orbit/Sphre AF, Deluxe for Notebooks. The driver can capture still images and video stream over 10 frames per second in a 320x240 pixel resolution.
Figure 5.8 There is a CE shared source code community driver project for this Logitech Camera. Several of the Logitech USB QuickCam models are supported. It uses the USB 1.1 Video Standard.
115
For additional information on this 9 and the other community projects for Windows Embedded CE including the Phidget sensor modules, see http://msdn2.microsoft.com/en-us/embedded/aa731151.aspx. Additionally, a new CE 6.0 USB Camera driver was also recently released at www.microsoft.com/downloads. It enables still and video capture from cameras which comply with the USB Video Class version 1.1 standard. It uses the DirectShow multimedia framework API.
5.6 Interfacing external hardware using the Serial Port

Serial devices have a slight software ease of use advantage in that no special device driver is needed since drivers to support serial devices are included in the OS. Unfortunately, the I/O bandwidth of serial vs. USB transfers is lower. Serial boards will also require their own power source, unlike small low-cost USB boards that can use 5V DC 500MA power available from the USB cable. The Cypress Programmable System on a Chip (PSoC) boards are one of the more interesting and easy to use low-cost customizable serial I/O options. The single chip PSoC device contains a microcontroller, A/D, D/A, programmable gain blocks, digital I/O, and serial I/O. First using a graphical software tool, the analog and digital blocks needed are selected, placed, and interconnected inside the chip to provide a wide range of I/O features. Second, the microcontroller firmware is programmed in assembly or C. Using a desktop PC with a USB cable, a special adapter programs the firmware into flash memory inside the device. Development tools and a small low-cost PCB with the chip, an LCD display, I/O connectors, and a small protoboard area are available for schools with an academic discount (www.cypress.com/CUAP ). A USB version of the board is also available, but no USB device drivers for it are currently available for CE from Cypress.
Figure 5.9 The Cypress PSoC CY3210 Evaluation Kit board has an LCD, a serial interface, and a small protoboard area.
The USB web camera driver project source code is available at www.codeplex.com/cewebcam
116
5.7 Low-cost Sensors for Embedded System Projects

A wide variety of low-cost sensors are available for embedded systems design projects. Some of the more popular sensors for small robots and hobbyist projects are shown in Figure 5.6. The line follower module detects a dark line on the floor and can be used in a line following robot. IR proximity sensors can be used to detect the presence of obstacles within a couple feet. Low cost shaft angle encoders can be used for speed and position feedback on servos and DC motors. GPS satellite receivers can determine the location of an outdoor device to within several feet. Low-cost Sonar modules send out an ultrasonic sound chirp to measure the distance to the closest object. Range is typically from several inches to around 20-30 feet. They time the arrival of the return signal and by using the speed of sound in air, the distance is calculated. IR distance sensors return the distance to the closest object by detecting the angle of infrared (IR) light reflected off an objects surface and typically have a range from several inches to a couple feet. Electronic compass modules can determine the orientation of a device using the earths magnetic field. Solid State CMOS camera modules can be used to capture still pictures and video. The Omnivision camera module shown uses an I 2 C interface for control and the image data is transferred out on an 8-bit parallel port. Low-cost MEMs gyros and accelerometers can be used to provide a sense of balance by measuring the acceleration of gravity (i.e., vertical 1G vs. horizontal 0G). Unfortunately, the noise levels on these low-cost motion sensors are still a bit too high to perform integration over time to determine a devices exact location as it moves around. Numerous other solid state sensors are also available that measure temperature, humidity, PH, and selected chemical gas levels present in the air. Sensors come with analog and/or digital outputs. Digital sensors can be connected to a GPIO port. To interface to sensors with analog outputs, an A/D chip is needed to convert to digital signals or one of the USB or Serial I/O boards described earlier with analog inputs can be used. The USB and Serial I/O boards with analog inputs have their own internal A/D converters and some even have a D/A converter for analog outputs. Small low-cost 8-16 bit A/D chips are also available with SPI or I 2 C interfaces. Often, additional signal conditioning circuits are needed for analog sensor signals to scale the voltage level of signals, to drive (i.e., buffer or impedance match), and to low-pass filter analog inputs going to A/Ds and outputs coming from D/As. A low-pass filter is used to remove the higher frequency components of the signal that are above the A/Ds or D/As sampling rate. A lowpass filter reduces the signal distortion due to aliasing problems in sampled data. Typically, you will need to sample and filter data at a rate at least twice the highest frequency component that will be used in the sampled data. This is termed the Nyquist rate. Oversampling well above this rate is often done to reduce noise, average data for a few more bits of resolution, and allow the use of digital low pass filters instead of analog low pass filters.
117
Figure 5.10 Low-cost sensors from left to right: Line following, IR proximity, optical shaft encoder, GPS, Sonar, IR distance, Electronic Compass, CMOS Camera
Analog Devices (www.analog.com) makes a wide variety of A/D and D/A converter ICs with both SPI and parallel interfaces. They also make MEMs gyros, accelerometers, and other sensors. Sample devices can be requested at their website.
Figure 5.11 Special adapter boards make it easier to prototype with surface mount devices. A small 10-pin surface mount 16-bit SPI A/D chip is shown mounted on a special surface mount to DIP adapter board. The adapter board allows it to plug directly into a .1 inch student protoboard.
Many new devices and sensors are only available in surface mount packages. For projects using low-pin count surface mount devices, small low-cost adapter boards are available with pins that plug into a standard .1 inch protoboard. Adapters such as the one seen in Figure 5.11, are available for many of the
118
more common surface mount package styles at www.winslowadaptics.com and www.beldynsys.com. The surface mount device must be carefully soldered to the adapter board. If a printed circuit board (PCB) is needed for custom hardware design with sensors or other simple devices, a number of low-cost web-based PCB fabrication services are available. CAD tools are provided to design the PCB, and the design files are sent over the web to the PCB vendor. The vendor then provides a free on-line cost estimate, makes the boards, and express mails them back to the customer in a couple days. Two such web-based PCB fabrication services are www.expressPCB.com and www.4PCB.com. Anyone new to PCB design should only attempt simple double-sided PCB designs, until they are familiar with the process and tools. Complex boards with processors, memory and other high-pin count devices will require multiple layer PCBs. Multilayer PCBs have very-high initial fabrication setup costs in low quantities. Expensive soldering equipment or an outside vendor will also be needed to solder high-pin count surface-mount devices to a new PCB design. If a device prototype needs a custom enclosure, there are also low-cost webbased enclosure fabrication services that allow users to custom design a case and front panel using a free CAD tool. The CAD tool has cutouts for many of the standard computer connectors and allows the user to add custom labeling on the front panels. After an order is placed on the web, a computer numerical control (CNC) machine automatically cuts out the panels. One such web-based fabrication service is available at www.frontpanelexpress.com.
Figure 5.11 This custom designed enclosure and front panel was fabricated for a student project using a low-cost web-based electronic enclosure fabrication service (www.frontpanelexpress.com ). Inside it contains one of the Cypress PSoC boards seen earlier in Figure 5.9.
119
5.8 Using Servos for Embedded System Projects

Low-cost radio controlled (R/C) servos as seen in Figure 5.12, are often used to build robots and other moving and rotating devices. These devices are found in many radio controlled model cars and plans. They are also sold separately through hobby stores and web sites. A typical servo rotates around 280 degrees. R/C servos are controlled with a 1bit digital pulse width modulation (PWM) signal and they are setup to operate off a 5V DC supply. A 1-2ms pulse is sent every 20ms to set the angular position for the servo to maintain. The PWM control signal is compatible with 5V logic signals.
Figure 5.12 A low-cost radio control (R/C) servo motor. Inside the case are a DC motor, reduction gears, PWM control, and driver circuitry. They can also be mechanically modified and used as robot drive motors for small robots. A 1-bit digital Pulse Width Modulation (PWM) signal is used to control servos. A USB-based Phidgets servo controller board is also available.
By cutting a small mechanical stop inside a servo it can be converted into a small high-torque continuously rotating drive motor for a small robot. After conversion, the PWM signal commands the drive motor to stop, go forward, or reverse instead of setting it to a particular rotation angle. Modified continuous rotation servos are used in many low-cost hobby robots. Servos are also available now that have already been modified for continuous rotation. All R/C servos have three wires (power, ground, and PWM signal) but different brands change both the order and color of the three wires in the connector. Some larger robots and R/C vehicles use a servo for steering and a PWM speed controller module for the motors. A Phidget USB module is available that outputs the PWM signal to control servos and the Cypress PSoC processor can also be programmed to generate PWM signals. Using timers, the PWM signals can also be generated using a GPIO pin with some additional processor
120
overhead. Some processors and support chips also have built-in hardware support for several PWM output pins.
5.9 Wireless support for the eBox

An internal 802.11 WiFi wireless card is available for the eBox along with a driver for CE 6.0 from VIA and ICOP. It fits into the internal mini PCI card slot and includes the antenna as seen in Figure 5.13. USB wireless adapters for WiFi and Bluetooth can be used, if they have CE 6.0 drivers available. Wireless game system adapters that attach to the standard Ethernet connection can also be used to provide a wireless connection for the eBox.
Figure 5.13 The internal 802.11 wireless kit for the eBox 4300 MSJK. Photograph courtesy of ICOP.
5.10 Cell Phone Modems

Cell Phone modems can also be attached to the eBoxs serial port and used for projects that require voice and data transmission using the local cell phone network. Windows CE 6.0 includes a driver for the Enfora SA-GL GSM/GPRS Stand Alone Modem10 seen in Figure 5.14. A SIM card with an active cell phone account is required. CE includes APIs for handling SMS text messages and voice calls in the Cellcore/RIL libraries.
Described in more detail in Mike Halls articles, Using CellCore with Windows Embedded CE 6.0 and CE 6.0 - Sending an SMS Message (http://blogs.msdn.com/mikehall/)
10
121
Figure 5.14 The Enfora SA-GL GSM/GPRS Stand Alone Cell Phone Modem can be used with CE and the eBox. It attaches to the serial port. (www.enfora.com) .
5.11 Low-cost robot bases for the eBox

The new iRobot Create robot case can be used as a low-cost robot base for the eBox. It is based on the popular Roomba robot vacuum cleaner. The Create robots internal microcontroller reports back sensor status and accepts motor commands over the serial port. The serial port can be attached to the eBox, and the eBox can be mounted on the base in the open cargo bay. A sheet of plastic needs to be specially fabricated to mount the eBox on the robot 11. The iRobot Create robot with an eBox and web camera is shown in Figure 5.15.
11
Detailed instructions for mounting the eBox and a web camera on the iRobot Create are available at http://msdn2.microsoft.com/en-us/robotics/bb403184.aspx
122
Figure 5.15 The iRobot Create robot base can be used as a low-cost robot base for the eBox. An eBox, the Logitech web camera, and an extra battery pack are seen mounted to the Create robot base above (www.irobot.com). Photograph courtesy of Microsoft.
Figure 5.16 The Stinger is a commercial robot kit that was designed to be used as a low-cost robot base for the eBox (www.roboticsconnection.com). Photograph courtesy of Robotics Connection.
123
The Stinger educational robot kit from Robotics Connection seen in Figure 5.16 was designed as a low-cost robot base for the eBox. It includes electronics to provide power to the eBox, and a microcontroller board called the Serializer that interfaces to the robots sensor s and controls the motors. Additional support for these robots is also available in Microsoft Robotics Studio. Microsoft Robotics Studio is a Windows-based environment for hobbyist, academic, and commercial developers to create robotics applications for a variety of hardware platforms. Microsoft Robotics Studio includes a lightweight service-oriented runtime, a set of visual authoring and simulation tools, as well as tutorials and sample code. It supports robots running CE. 12
5.12 Supplying power to the eBox in robots and mobile devices

A 5 volt DC 3 Amp regulator circuit and an eBox power connector are also required to run the eBox off battery power in a robot or other mobile device instead of the usual AC wall adapter. Switching regulators like the one seen in Figure 5.17 cost a bit more, but they are more efficient (typically 80 to 90% vs. 50%) than low-cost linear regulators. With increased efficiency, switching regulators will provide longer battery run times. For even longer run times, a separate battery for the eBox can also be added. Typically, the battery voltage needs to be at least two volts higher than the regulator s output voltage. To power the eBox in cars, a 12VDC to AC power inverter could be used instead of a regulator, and the eBox s standard AC power adapter can be plugged in into the inverter. This approach would not be as power efficient but it would not require any additional cables and regulators.
Figure 5.17 This small 5V 3A switching voltage regulator can be used to power the eBox off of battery power (www.roboticsconnection.com ). Photograph courtesy of RoboticsConnection.
12
Additional information and downloads for Microsoft Robotics Studio can be found at http://msdn2.microsoft.com/en-us/robotics/default.aspx and the recent textbooks, Programming Microsoft Robotics Studio by Sara Morgan and Professional Microsoft Robotics Developer Studio by Kyle Johns and Trever Taylor.
124
5.13 Example Student Projects using the eBox

The eBox running CE 6.0 makes an excellent platform for student design projects. Several examples can be seen in the following figures. Projects include an eBox with a Phidgets LCD that displays live news from Internet RSS feeds as seen in Figure 5.18. Channels can be selected using a standard TV IR remote. The IR remote is decoded by a Cypress PSoC board (seen on left side of Figure 5.18) that communicates over a serial port to the eBox (seen in upper right corner of Figure 5.18).
Figure 5.18 This project displays scrolling RSS web news feeds on the Phidgets LCD display.
Students built the Voice over Internet Protocol (VoIP) phone system using two eBoxes shown in Figure 5.19. A low-cost USB HID numeric keypad is used to dial the number. A Phidgets LCD module displays the call status, and the eBoxs AC97 audio I/O is used for voice input and output. To place a call, the user types in the destination IP address.
125
Figure 5.19 VoIP Phone system using two eBoxes running CE 6.0.
The web-based temperature control system shown in Figure 5.20 used an eBox with a Phidgets temperature sensor. Digital outputs from a Phidgets board turn on the heater, A/C, and fan. The eBox runs a web page server to provide remote control and monitoring over the internet.
Figure 5.20 A web-page based remote temperature control and monitoring system built using an analog temperature sensor connected to a Phidgets 8/8/8 interface board attached to the eBox running CE6.0. Phidget digital outputs seen in the red LEDs control relay signals for the heat, AC and fan.
126
Figure 5.21 This student robot project was controlled by an eBox running CE 6.0. The battery powered eBox has the wireless option and can be seen on the top left of the robot.
Students built the mobile robot seen in Figure 5.21. An eBox and Phidgets LCD interface board was used to control the robot. It has encoders on the motors, and a laser rangefinder system (Ladar). The laser rangefinder interfaces to the eBoxs serial port. The motor controller signals use the CAN bus standard.
Figure 5.22 Digital I/O from the Phidgets LCD 8/8/8 interface board attached to the robots control and sensor signals. The laser rangefinder is seen in the upper left.
127
As seen in Figure 5.22 several digital I/O lines from the Phidgets LCD & interface board were attached to a protoboard to interface to the robots motor and encoder signals. The project seen in Figure 5.23 is a GUI application running on the eBox that monitors and controls analog and digital I/O devices on a Cypress PSoC board with a USB interface. Students developed a CE 6.0 USB Human Interface Device (HID) driver for their new device. Custom firmware on the Cypress USB board responds to USB commands received from the eBox. The Cypress boards LEDs can be turned on and off, button statu s read, data written to the LCD display, and analog inputs can be read back on the eBox. The USB driver was based on the shared source code project for the USB web camera.
Figure 5.23 This student project consisted of a CE USB HID driver and GUI for a USB PSoC board. The GUI can monitor and control all of the I/O features on the PSoC board.
128
Figure 5.24 This eBox Phidget project is a scanner built using an IR distance sensor with pan and tilt servos. Note the clever use of the eBoxs mounting holes and a plastic sheet to attach the external hardware on top of the eBox. Photograph courtesy of Dan Slaeker.
The eBox Phidget IR scanner project 13 seen in Figure 5.24 uses two Phidget controlled R/C servos with a commercial pan and tilt R/C servo mounting bracket designed for solid state cameras or distance sensors, and an analog IR distance sensor attached to a Phidgets interface board. The servos attach to a Phidgets servo controller board. Special pan and tilt brackets are available for R/C servos. As seen in Figure 5.24, The eBoxs four existing VESA mounting holes with screws and spacers are used to attach a clear plastic board used to mount the external hardware. The top of the eBox is a heatsink so some clearance is needed to allow for proper air flow to cool the eBox. The eBoxs VESA mounting holes can also be used to attach it to the back of larger LCD displays that have VESA standard mounting holes.
This IR scanner project is described in more detail in the article, Creating a Windows CE 6.0 OS Design For Development With Phidgets Devices by James Y. Wilson (search for title at http://www.academicresourcecenter.net)
13
129
Figure 5.25 Students mounted an eBox on this R/C plane along with a GP S receiver and a small battery. They recorded flight data and displayed the data using web-based satellite imagery.
Students built a flight data recorder for the R/C airplane seen on the left in Figure 5.25. The plane has an eBox mounted above the wing in a small enclosure (near the center of gravity for balance). A GPS receiver is attached to the serial port on the eBox. It is setup as a headless device (i.e., no monitor or keyboard) and a Phidgets LCD module displays system status info. Flight data is saved in flash memory. Data recorded from a flight is reformatted and was used to generate the flight path image using web-based satellite imagery as seen on the right in Figure 5.23. A small 7.4V LiPo battery pack connected to a 5 Volt 3 Amp voltage regulator IC powers the eBox. In this configuration, the eBox required around 1.5 Amps and the battery could run the eBox for around 40 minutes. Most small R/C planes only carry around 10-15 minutes of fuel in their tanks. If all three additional external USB devices are attached to the eBox and the internal wireless card is active, it can draw up to the maximum rated current of 3 Amps. Using the eBox with a GPS receiver and a Cell Phone modem, students designed the vehicle location reporting system seen in Figure 8.26. A GPS enabled Windows Mobile cell phone can send it an SMS text message with the phones current location. The car responds with an SMS text message that contains the cars current location and the phones distance from the car. While moving, the phone constantly updates the distance and direction to the car in a GUI display. A low-cost automobile 12V DC to 120V AC 100 watt power inverter was used to power the AC adapters for the eBox and the cell phone modem in the car. So no custom cables or regulators were required since the inverter plugged into a
130
cigarette lighter in the car (12VDC) the standard AC power wall adapters just plugged into AC power inverters output (120VAC). A 5V DC switching regulator could also be used and would likely be more power efficient, but in that case custom power cables would be needed to connect 5V DC power to the devices.
Figure 5.26 Students mounted an eBox in this car along with a GPS receiver and a cell phone modem. An AC inverter was used for power. The car c an report its location to any phone via SMS text messages.
The Phidgets modules seen in Figure 5.27 were assembled on a Bud plastic mini box (Bud #PC11404) for use in a wide variety of student laboratory projects. Each Phidget modules printed circuit bo ard has pre-drilled screw holes that were used along with machine screws and spacers to mount them on the box. All of the Phidget interconnect wires feed through drill holes behind each module and are neatly hidden away inside the mini box. An R/C servo controller is used along with a pan & tilt servo bracket that holds an IR distance sensor. Low-cost MaxBotix Sonar sensors can also be used for distance measurements with the Phidgets analog input modules.
131
Figure 5.27 Several Phidgets mounted on a plastic case for CE eBox student lab projects. It includes an LCD, 8 LEDs, 8 switches, ADC with 8 different analog sensors, and 2 R/C servos on a pan & tilt mount with an IR distance sensor. Sensor wires are hidden inside the case.
Since the default USB 1.0 based Phidgets sensor update rate is around 50 to 125 times a second, they need to be used for signals that do not require very high data sampling rates. In some cases, the Cypress PSoC board will be better suited for higher data rates since the microcontroller firmware can be written by the user and designed to handle higher data rate signals. The eBox serial port interface can then be used to transfer higher level commands and status information with the PSoC microcontroller firmware. The microcontroller firmware performs the higher data rate lower-level operations locally. As an example, the microcontroller firmware could generate PWM signals at several kilohertz for servos or motor speed control, and the high-level serial commands from the eBox could send the servo angle or motor speed setting to the microcontroller over the serial interface at a much slower rate.
132
To sample higher frequency analog input signals, the AC97 stereo audio input on the eBox can be used. Sample rates up to 44 kilohertz are possible. The microphone s audio input expects around a 1V peak to peak input, so signal conditioning circuits would likely be needed to adjust the signal to the proper input voltage levels. CEs audio APIs can then be used to sample the signal. One such student project is seen in Figure 5.28. Students developed a portable electrocardiogram (EKG) recorder using the eBox. An EKG records the electrical activity of the heart versus time. The eBox runs off a battery in a small backpack, so EKGs can be taken while the patient is moving around and exercising. Even though EKG signals have a fairly low bandwidth, the Phidgets analog input sample rate was still too low for an accurate representation of the signal, so the AC97 audio input was used instead. Sensor signals were scaled to a 1V peak to peak level using an operational amplifier and filter circuit. A recorder program using wavein audio APIs saves the EKG heartbeat data samples in a *.wav audio file. The *.wav file is uploaded periodically using a wireless network connection to a desktop PC for permanent storage and further data analysis. A GUI display of the EKG data collected by the eBox is seen in Figure 5.28.
Figure 5.28 This EKG data was sampled using the AC97 microphone audio input on the eBox. Audio APIs can be used to sample a 1V peak to peak signal at up to 44 KHz .
Other USB-based, Network-based, or mini PCI A/D and D/A devices could also be used in projects that need higher sampling rates or more analog channels, but they would increase device cost and require device driver support for CE 6.0.
133

For additional eBox 4300 information and data sheets www.embeddedpc.net and www.ece.gatech.edu/~hamblen/Ebox. check:
Phidget interface kits, CE drivers, and sensor modules are available from:
Phidgets USA http://www.phidgetsusa.com A division of Trossen Innovations, LLC or http://www.phidgets.com One Westbrook Corporate Center Suite 910 Westchester, IL 60154 877-898-1005
Several interesting robot kits including the Stinger, a voltage regulator, Sonar modules, and other robot parts are available from:
Robotics Connection 4355 Cobb Pkwy Suite J148 Atlanta, GA 30339 770-314-1577 http://www.roboticsconnection.com
The iRobot Create robot base is available from:

iRobot 63 South Avenue Burlington, MA 01803 800-727-9077 http://www.irobot.com/create
For sensors, servos, and other robot parts for embedded system design projects here are some suggestions. IR Proximity, Line Tracker, Sonar sensors, Servos, Wheels, brackets, and Robot kits can be obtained from:
Lynxmotion, Inc. 104 Partridge Road Pekin, IL 61554-1403 309-382-1254 http://www.lynxmotion.com
Sensors & Robot kits, Servo wheels for robots, and Servo wheel encoder kits can also be obtained from:
Acroname P.O. Box 1894 Nederland, CO 80466 303-258-3161 http://www.acroname.com
134
A wide array of interesting low-cost sensor modules is available from:

Devantech Ltd (Robot Electronics) Unit 2B Gilray Road Diss Norfolk IP22 4EU England http://www.robot-electronics.co.uk
Sensor, wireless, GPS, and cell phone radio modules are available from:
Spark Fun Electronics 2500 Central Ave. Suite Q Boulder, CO 80301 http://www.sparkfun.com
Additional details on the eBox student projects described including complete source code is available on the web at: http://www.ece.gatech.edu/~hamblen/489X/projects

1. Develop a design project idea using the eBox and other hardware that may be available. Draw a system level block diagram of the design project. Identify the hardware and software tasks required to complete the project. Estimate the time required for each task in a Gantt chart, include a parts cost estimate and a realistic labor cost estimate assuming 100% overhead on salaries. Identify how any additional parts needed for the project can be obtained in a short time period. 2. Design a smart I/O peripheral for use with the eBox using the Cypress PSoC board. Interface an interesting new sensor to the PSoC processor chip using the small protoboard area provided on the PSoC board. Program the PSoC microcontroller to read in the sensor data (analog or digital), send the data to the on-board LCD display, and send the data out on the serial port periodically. Using a cable, the PSoC serial port would be connected to the serial port on the eBox, which would then read in the sensor data from its serial port. The PSoC software also supports PWM, SPI, and I2C devices. 3. Use the Cypress PSoC board with the appropriate motor driver circuitry and PWM to develop a speed controller for a small DC motor. It should respond to high-level motor speed setting commands that are sent to the microcontroller using the eBoxs serial port.
CHAPTER 6
Architecture of a Real-Time Embedded OS CE 6.0R2
The Motorola Q Phone runs Windows Mobile. The core technology of Windows Mobile Smart Phone and Pocket PC devices is Windows Embedded CE. Photograph courtesy of Motorola Corporation.
136
6 Architecture of a Real-Time Embedded OS - CE 6.0 R214

To better understand the features and capabilities of a Real-Time Operating System (RTOS), we will examine the architecture and features of a commercial RTOS designed for use in embedded systems. It is assumed that the reader already has some familiarity with general purpose operating systems. General purpose operating systems such as the ones typically used in desktop PCs do not provide the real-time response rates needed, require more hardware support, and higher power levels than are typically found in the majority of current embedded devices. Windows Embedded CE is a popular commercial real-time operating system used in many embedded devices. CE is not just a modified version of the Windows desktop operating systems, it is a totally different OS. It was originally developed from scratch starting in the mid 1990s to provide a realtime OS for embedded devices with less memory and processor power than a desktop PC. CE is also the core technology behind both Windows Automotive and Windows Mobile devices including the Smart Phone and Pocket PC.
CE Kernel
2 GB Kernel Space
File system GWES Drivers

User VM Memory Mapped files
2 GB per Process
User DLLs Process Code User VM
......
Up to 32 K Processes
Figure 6.1 The Windows Embedded CE 6.0 Virtual Memory Space Model.
14
The material presented in this Chapter was obtained from or is derived from the CE 6.0 on-line help files, MEDC 2006 conference presentations by members of Microsofts CE design team, and Microsofts Windows Embedded CE Professional Training Materials. Reprinted with Permission of Microsoft Corporation.
137
We will use CE as the OS for our eBox 4300 embedded computer system in laboratory projects. In this chapter, we will limit our discussions to CE 6.0, the newest version. CEs Real-time response times are faster and kernel size is typically smaller than a general purpose desktop OS. CE 6.0 can run a maximum of 32,000 simultaneous processes, each with 2 GB of virtual memory address space as seen in Figure 6.1. Recall that the amount of physical memory present in a computer is independent of the virtual memory address space (a device running CE does not need 4G of Physical RAM). CE includes C/C++ and C# cross compilers, a build system, and extensive debug tools that run on a desktop PC. These tools can also be used by OS or application developers. A browser, WordPad, messenger, media player, and several games are also included. The desktop PC is typically connected to the target system for development work. A special GUI-based tool called Platform Builder that runs in Visual Studio is used to generate new OS kernels. Several different families of popular embedded processors are supported including X86, ARM, SHx, and MIPS. The CE system architecture is shown in Figure 6.2. Items in blue are provided with the OS, the OEM typically provides the items shown in green, and applications programs provide the items shown in yellow.
Applications
User Space SHELL
SERVICES.EXE
Services Services Services Services
UDEVICE.EXE
User Mode Services Drivers Services Services
COREDLL / WINSOCK / COMMCTRL / WININET / COMMDLG DEVICE.. DLL FILESYS GWES NETWORK Drivers OAL. DLL Boot Loader KCOREDLL DLL Hardware
Figure 6.2 Windows Embedded CE 6.0 Architecture.
Kernel Space
KERNEL. DLL
The CE architecture is designed around two modes of privilege, Kernel and User. The fundamental system components providing basic services to the operating system run in the privileged Kernel mode, while user processes (applications) and dlls run in the unprivileged User mode. Privileged components include the kernel, device manager, file system manager, and
138
GWES. The privileged kernel components are always present no matter what user process happens to be running. A single user mode process is resident at one time, isolated from other user mode processes and from the kernel. Threads running in user mode processes make system API calls that are handled by another component often residing in the kernel. Threads must migrate to the server process residing in the kernel or another user process to complete the API call. This transition out of the unprivileged user mode process into another process requires expensive kernel support. Memory buffers passed between processes or into the kernel must be validated and marshaled for proper access which also requires kernel overhead. Components running in the privileged kernel mode do not incur the overhead of a kernel trap and some of the data marshalling requirements because they are always present and already privileged. Calls between kernel mode components are done directly without kernel intervention. Many API calls require support from a number of different system servers (filesys, device, kernel, etc) to complete a single call. These system servers have been moved from separate user mode processes into the kernel in CE6, eliminating much of the overhead. This change is responsible for significant performance increases in many system API calls compared to previous versions of the operating system.
6.1 User Applications

The top level in Figure 6.2 consists of the user applications running on the device. User applications are typically developed in C/C++ or C#. Windows CE supports a subset of the desktop Windows Win32 API system call interface. This means that applications developed for CE can be recompiled to run on desktop windows, but the reverse is not true. CE supports a couple thousand API calls and the latest desktop OS has around twenty thousand. API calls were added only when needed in order to develop a small but sufficient subset of the Win32 API. This helped reduce the kernel size for CE. The standard GUI and user interfaces have a look and feel similar to the desktop Windows OS. In addition to Win32, CE provides support for several Microsoft programming interfaces including, COM, ActiveX, MFC, and ATL. Microsoft Component Object Module (COM) offers a standard for creating components that can be reused and assembled into larger systems. COM defines binary objects that can be queried at run time. The COM model is language independent. An ActiveX control is a specific type of COM object used for extensible controls. An ActiveX control typically presents a user interface and exposes properties, methods, and events. The Microsoft Foundation Classes (MFC) is a class library for developing Windows applications in C++. It has much the same functionality of the Win32 API, but within an object-oriented application framework. The Active Template Library (ATL) is a C++ template library designed to create ActiveX controls and other COM components. Applications can be developed that run on a CE-based device along with the kernel OS development as a subproject, or applications can be developed based
139
on an imported Software Development Kit (SDK). Applications developers using an SDK can work at the application programming interface (API) level and do not need to understand the low-level details of OS and driver development for the new device. In either case, applications are developed using the Visual Studio 2005 IDE. Application development and code examples will be discussed in more detail in Chapter 8. All applications based on CE consist of a process and one or more threads: A process is a single instance of a running application. A thread is the basic unit that the CE OS allocates processor time to. A thread can execute any part of the process code, including parts that are being executed by another thread. The OS provides process and thread API functions and structures to perform operations such as creating and terminating a process or thread and retrieving information about a process or thread. A number of synchronization methods are provided including critical sections, mutexes, events, and semaphores. Many APIs are implemented in dynamic-link libraries (DLL). Dynamic linking allows a module to include only the information the system needs at load time or run time to locate the code for an exported dynamic-link library (DLL) function. Dynamic linking differs from static linking, in which the linker copies a library function's code into each module that calls it. The codedll.dll library is automatically linked to each application to provide support for basic APIs. Some APIs will require linking the application to additional DLLs. Check the on-line help information on specific APIs to see if additional DLLs are required. .NET Compact Framework provides support for C# and Visual Basic applications running in CE.
Application
Kernel
Service
Figure 6.3 CE 6.0 System Calls
140
6.1.1 System API Calls Application programs use system API calls to utilize OS services and features. A system call is a function that resides in another process and that the kernel, NK.exe, is notified about. The kernel then calls the proper server process to handle the system call. As seen in Figure 6.3, when a CE 6.0 Application makes an API system call A protected server library (PSL) jump to the Kernel is performed The application stays mapped during the call The CE Kernel then Validates the API system calls parameters Calls into to the appropriate service Finally, the required Service Runs And Returns directly to the app Every system call causes an exception that is caught by the kernel. When a process calls a system call, it calls into a wrapper function for that system call that is defined in Coredll.dll. That function prepares the function's parameters for the kernel and causes a software exception to occur. The exception can be an undefined address exception or a CPU trap. The kernel then handles this exception and determines the correct destination process to send the function call request to or which .exe file can fulfill the request. The process that owns the function executes it using the same stack and register values that the original thread contains in the calling process. Because the function call exists in another process, the existence of that process must be verified in order to successfully execute the system call. During the whole process, the user mode thread is the same thread that executes in the process space for the system .exe file. As a thread migrates, its access rights change to reflect the process in which it is operating.
6.2 The Kernel

The kernel, which is represented by the (New Kernel) NK.exe module, is the core of the CE operating system (OS). The kernel provides the base OS functionality for any CE based device. This functionality includes process, thread, and memory management. The kernel also provides some file management functionality. Kernel services enable applications to use this core functionality. Figure 6.4 shows the general structure, emphasizing the kernel as the conduit for the rest of the core OS. Use the kernel process and thread functions to create, terminate, and synchronize processes and threads, and to schedule and suspend a thread. Processes, which represent single instances of running applications, enable users to work on more than one application at a time. Threads enable an application to perform more than one task at a time. Thread priority levels,
141
priority inheritance, interrupt support, and timing and scheduling are all included in the CE kernel architecture. Together, they provide real-time application capability for time-critical systems. The CE kernel uses a paged virtual-memory system to manage and allocate program memory. The virtual-memory system provides contiguous blocks of memory, in 4,096-byte pages along 64-kilobyte (KB) regions, so that applications do not have to manage the actual memory allocation. For memory requirements of less than 64 KB, an application can use the local heap provided for all CE applications or create separate heaps. The kernel also allocates memory to the stack for each new process or thread. Use the kernel memory functions to allocate and deallocate virtual memory, use memory on the local heap, create separate heaps, and allocate memory from the stack. Your code can use the unused memory from the static data block that is allocated to load the application. Processes also can use memory-mapped objects to share data.
Figure 6.4 CE 6.0 Kernel Architecture.
6.3 Memory Architecture

In any CE based device, ROM is used to store the entire operating system (OS), as well as the applications that come with the OS design. Virtual memory
142
mapping is used to reduce memory fragmentation and provide memory protection. Virtual memory with demand paging to a hard disk swap file is typically not used, unlike the popular desktop operating systems. Many devices do not have a hard disk and it would also require more power. Flash memory also has a limited write cycle lifetime making it a poor choice for a swap file device. Virtual memory with demand paging using swap files can also have negative effects on the real-time performance of an OS, especially when the computer runs low on physical memory and excessive thrashing occurs between RAM and the disk swap file. In CE, when a process initializes, the OS maps the following DLLs and memory components: Some execute-in-place (XIP) dynamic-link libraries (DLLs) Some read/write sections of other XIP DLLs All non-XIP DLLs Stack Heap Data section for each process DLLs and ROM DLL read/write sections are loaded starting at the top of the address space. DLLs are controlled by the loader, which loads all the DLLs at the same address for each process. The stack, the heap, and the executable (.exe) file are created and mapped from the bottom of the address space. The bottom 64 KB of memory always remains free. For CE 6.0, the kernel process resides in the upper 2 GB of the 4 GB (32 bit) virtual memory space, and the bottom 2 GB is unique for each process. There is a limit of about 32,000 processes due to the number of handles that can be created. The practical limit on the number of processes is bounded by the amount of physical memory. Because virtual memory access is translated into hardware access through the memory management unit (MMU), virtual memory code is CPU dependent. ARM and x86 CPUs use hardware page tables, so the content of virtual memory is accessed directly by the hardware, while other CPUs use a software translation look-aside buffer (TLB) miss handler where the content of virtual memory needs to be filled for the TLB to be in effect. Figure 6.5 shows the internal virtual memory address space mapping for a user process.
143
0x80000000
Shared System Heap 255 MB RAM Backed Mapfiles 256 MB Shared User DLLs 512 MB User Space 2 Gigabytes Each process has its own mapping
R/W for OS components Read only for user process

RAM Backed Map files Mapped at fixed location for better backwards compatibility All DLLs code and data Same mapping across all processes Data pages are unique physical pages Code pages are shared
0x40000000
Process space 1 GB per process
0x00000000
Figure 6.5 User Space Virtual Memory Mapping
The design goals for virtual memory management in CE 6.0 include: Large amount of virtual memory per process No preset number of processes limit Protection between processes Minimized CPU dependent code Efficient virtual memory allocation Efficient TLB miss handling
144

0xFFFFFFFF CPU Specific VM
System Trap Area Kernel Virtual Memory Shared by all kernel Servers and drivers
Kernel VM (if supported by CPU) 256 MB Kernel VM 256 MB
Kernel Space 2 Gigabytes Fixed mapping independent of user space
Object Store (128MB) Kernel XIP DLLs (128 MB)
All XIP DLLs in kernel Uncached access to physical memory
Static Mapped Uncached 512 MB Static Mapped Cached 512 MB
0x80000000
Figure 6.6 Kernel Space Virtual Memory Mapping.
Figure 6.6 shows the internal virtual memory address space mapping for the kernel. Table 6.1 shows the CE 6.0 virtual memory map and describes each region in more detail. Table 6.1 CE 6.0 Virtual Memory Map. Mode Kernel Kernel Range 0xF0000000 0xFFFFFFFF 0xE0000000 0xEFFFFFFF 0xD0000000 0xDFFFFFFF 0xC8000000 0xCFFFFFFF 0xC0000000 0xC7FFFFFF 0xA0000000 0xBFFFFFFF Size 256 MB 256 MB 256 MB 128 MB 128 MB 512 MB Description CPU specific VM Kernel VM, CPU dependent Kernel VM Object store Comments System call trap area. Kernel data page. Kernel space virtual memory, unless disallowed by the CPU, such as SHx. Kernel space virtual memory, shared by all servers and drivers loaded in kernel. RAM based storage for RAM file system, CEDB databases, and RAMbased registry. Legacy data store. XIP DLLs for the kernel and all servers and drivers loaded in the kernel. Direct access to physical memory bypassing the CPU cache.
Kernel Kernel
Kernel Kernel
Kernel XIP DLLs Statically mapped Uncached
145
Kernel
0x80000000 0x9FFFFFFF 0x7FF00000 0x7FFFFFFF 0x70000000 0x7FEFFFFF
512 MB 1 MB 255 MB
User
User
Statically mapped Cached Unmapped for protection Shared system heap
Direct access to physical memory accessed through the CPU cache. Buffer between user and kernel spaces.
User
0x60000000 0x6FFFFFFF
256 MB
RAM backed map files
User
512 MB
User mode DLLs Code and data
User
1 GB
User
0x00000000 0x00010000
64 KB
Process User allocatable VM CPU dependent user kernel data
Shared heap between the kernel and the process. Kernel and kernel servers can allocate memory in it and write to it. Read only for user processes It is a system optimization that allows a process to get data from a server without having to make a kernel call. RAM backed mapfiles are mapped at fixed location for backward compatibility. RAM backed map files are memory mapped file objects that do not have an actual file underneath them. They are acquired by calling CreateFileMapping with hFile equal to INVALID_HANDLE_VALUE. This region provides backward compatibility for applications that used RAM-backed map files for cross-process communication, expecting all processes to map views at the same virtual address. DLLs loaded at bottom and grow up: Based starting at 0x40000000. Code and data are intermixed. A DLL loaded in multiple processes will load at the same address in all processes. Code pages share same physical pages. Data pages have unique physical pages for each process. Executable code and data. User VM (heap) virtual allocations. VM allocations start above the exe and grow up. User kernel data is always r/o for user. Depending on CPU, it can be kernel r/w (ARM), or kernel r/o (all others).
146
Users can only call VM functions on the memory they allocate with VirtualAlloc, they cannot perform VM operations on kernel allocated VM in user space, such as stacks, memory-mapped file views, and DLL code/data. The kernel can read and write to the shared heap area, and user processes can only read to the shared heap area. The purpose of this area is to allow the system server to communicate with client processes more efficiently. However, because all processes can read information from the shared heap, do not store any security sensitive information (such as a password) in the shared heap. There is always an unmapped area of size at least 64K between the regions to protect access span regions.
Figure 6.7 Example of Virtual to Physical memory mapping on a device.
Figure 6.7 is an example of how addresses are mapped from physical memory space to virtual memory space. This particular example shows a set of addresses that are statically mapped in the kernel. Memory that is mapped statically is always available, while memory mapped dynamically will be paged in by the operating system on demand. Paging saves memory resources because it limits the amount of physical memory required for mapping tables used by the MMU.
147
Demand paging causes a kernel exception to perform the correct mapping to allow a particular memory access to complete. This exception is transparent to applications, but it takes time and requires that the operating system be in a state where it can handle the exception. Statically mapped addresses are necessary to handle situations where a page fault exception would cause a system crash, for example accesses by the kernel when it is already in an exception handler and during low level kernel initialization. All RAM/ROM in the system must have a static mapping, as well as any memory location that might be accessed by an ISR since ISRs also run in the context of an exception. This example demonstrates another feature of a virtual memory architecture. Notice that the physical memory is mapped into two different virtual addresses simultaneously. The MMU in a virtual memory architecture does more than just provide a mapping from physical to virtual addresses. The mapping operation also includes information on what type of access is permitted (read/write/execute/noaccess), what CPU privilege mode is required in order to perform the access, and whether the access should be cached. The same physical memory can be mapped to multiple virtual addresses with different access qualifiers in each mapping. The two virtual address ranges in this example differ in their use of the system cache. Access to the virtual memory addresses marked as cached will possibly hit in the cache and not actually make it out to physical memory. Accesses to memory in the region marked as uncached will bypass the cache and go directly to physical memory. Cached accesses are faster because there is the potential to hit in the faster cache memory inside the CPU. Hardware device registers are an example of a memory address that needs to be done as uncached because reads and writes to those device must always access physical hardware; most other virtual address mappings will be marked as cacheable.
6.4 Core operating system (OS) services

The core operating system (OS) services consist of the CE kernel and other features common to all CE OS designs. Core OS services enable low-level tasks, such as process, thread, and memory management. Basic device drivers are also part of the CE core OS services. Core OS services give applications access to the resources of the computer and the features of the underlying OS, such as memory, file systems, devices, processes, and threads. An application uses these services to manage and monitor the resources it needs to complete its work. Applications can share code or information with other applications. Networking functions read from and write to communications ports as well as control the operating modes of these ports. Applications handle special conditions during execution. For example, they can handle errors, log events, and handle exceptions. Applications can also use special functions to debug code and improve its performance. For example, the debugging functions permit single-step control
148
of the execution of other processes, and the performance monitoring functions provide detailed information on process execution.
6.5 File systems

CE supports two kinds of file systems: file systems that are controlled by file system drivers and registered file systems. Because FSD-managed file systems are the preferred file system type, CE includes File System Drivers (FSD) for a variety of file systems. In addition, embedded systems developers can create and register proprietary file systems. Regardless of the type of storage, all of the file systems are accessed through the Microsoft Win32 file-system application programming interface (API). The registered file system drivers include the Release-Directory File System (RELFSD), the Object Store (RAM) File System, and the ROM File System. The object store in Windows Embedded CE provides persistent storage for applications and their related data even when the main power supply is lost, provided there is a backup power supply. One or more memory storage chips, which typically are nonvolatile RAM chips, compose the physical object store. Although file systems, databases, and the system registry share a single memory heap, they do not necessarily reside physically in the object store. They can reside in ROM, on separately installed systems, or on an external device, such as a flash memory device. Data is created and retrieved according to the storage type, independent of the actual storage device. The operating system uses the object store to perform the following tasks: Manage the stack and memory heap Compress and expand files as necessary Seamlessly integrate ROM-based applications and RAM-based data
Both the File System and the Registry will be discussed in more detail. Table 6.2 describes the File Systems and Storage Management Catalog items that can be selected for the OS when using the Platform Builder tool to generate a new kernel.
149
Table 6.2 File Systems and Storage Management Catalog.

Catalog Item name Compression Database Support Bit-based Description An application programming interface (API) that compresses the data in the RAM and ROM file systems, as well as the database volumes. An API that provides built-in CEDB database support. A feature that helps identify what changes have occurred in a database or RAM file system on the device and therefore must be replicated on the desktop. This model relies on four bits per object to replicate the data. A file system driver capable of reading data from the ROM file system and the RAM file system in the object store. A file system driver capable of reading data from the ROM file system. A registry system that stores data inside files, or hives, which can be kept on any file system. A system that stores all registry data within the object store. The Storage Manager is responsible for all external storage items, such as file systems, file system filters, and partitioning. A Catalog item that is used to load a portion of an OS image from persistent media into RAM for execution. This Catalog item uses demand paging to load additional modules as needed.. A file system driver that supports both Compact Disc File System (CDFS) and Universal Disc File System (UDFS) and reads compact discs (CDs), digital video discs (DVDs), and CD-ROMs. An API that provides enhanced database functionality, including support for transactions, access by multiple users, multiple sort orders, key properties and databases. A file system driver that supports the file allocation table (FAT) file system. A file system driver that supports the Extended FAT file system. A driver that interprets the partitions on a storage device for the Partition Manager. A control panel application that allows a user to manipulate storage devices. A transaction-safe FAT file system that ensures the file allocation table is not corrupted during power cycles. An API that provides support for authentication on a device to prevent unauthorized access. A functionality that provides support for the Release Directory File System Builds the Fatutil.dll file for a device with no graphical user interface (GUI) components.
RAM and ROM File System ROM-only File System Hive-based Registry RAM-based Registry Storage Manager Binary Rom Image File System CD/UDFS File System EDB Database Engine FAT File System Extended FAT File System Partition Driver Storage Manager Control Panel Applet Transaction-safe FAT File System (TFAT) System Password Release Directory File System Silent FATFS UI
150
The internal file system in your target device controls access to ROM. The file system can also provide file storage in the object store, which is in RAM. Two internal file system options are available: the RAM and ROM file system and the ROM-only file system. These have different properties and you will want to select the correct one for your target device. Both internal file systems provide the ability to mount additional external file systems, such as file allocation table (FAT). The RAM and ROM file system provides file storage in the object store, as well as access to the ROM. The object store is the root of the file system, and all data under the root is stored in the object store, with the exception of external file systems, which are mounted as directories under the root. Data in ROM is accessible through the Windows directory. The RAM and ROM file system is most useful in target devices that continuously power RAM because the object store is lost when RAM is not refreshed. The ROM-only file system does not allow applications to place files in the object store. Data in ROM is accessible through the Windows directory, and external file systems are again mounted as directories under the root. Additionally, with the ROM-only file system, you have the option of choosing an external file system to be placed at the root of the file system. If you mount a file system as the root, all data below the root directory is stored in that file system, with the exception of other external file systems.
6.6 Graphics, Windowing, and Events Subsystem (GWES)

CE combines the Win32 application programming interface (API), user interface (UI), and graphics device interface (GDI) libraries into the Graphics, Windowing, and Events Subsystem (GWES) module. GWES is the interface between the user, your application, and the operating system (OS). GWES supports all the windows, dialog boxes, controls, menus, and resources that make up the CE user interface (UI), which enables users to control applications. GWES also provides information to the user in the form of bitmaps, carets, cursors, text, and icons. Even CE based devices that lack a graphical UI use GWES basic windowing and messaging capabilities and power management functions.
6.7 Processes and Threads

All applications in CE consist of a process and one or more threads: A process is a single instance of a running application. Processes enable users to open and work in several applications at the same time. For example, a user can edit a file in a word processing application while another application is recalculating a spreadsheet. As a preemptive multitasking operating system, CE supports multiple processes running simultaneously within the system.
151
A thread is an independent portion of a process and is the basic unit that the OS allocates processor time to. Threads enable an application to perform more than one task at a time, even though applications cannot execute more than one thread at a time. A thread can execute any part of the process code, including parts that are being executed by another thread. Although one thread is designated as the primary thread for the process, a process can also create an unspecified number of additional threads. Available system resources limit the number of threads. CE provides 256 priority levels that you can set on a thread. To assign priority levels, CE uses the CeSetThreadPriority and CeGetThreadPriority functions. CeSetThreadPriority sets the priority for a specified thread. CeGetThreadPriority returns 0 (zero) as the highest priority and 255 as the lowest priority. Because CE supports preemptive multitasking, it creates the effect of a process simultaneously executing multiple threads. When a process has more than one thread running, the OS rapidly switches from one thread to another, so that the threads appear to run simultaneously. A thread is a path of execution within a process. Every time the OS creates a process, it also creates at least one thread. The purpose of creating a thread is to make use of as much of the CPU's time as possible. For example, in many applications, it is useful to create a separate thread to handle printing tasks so that the user can continue to use the application while it is printing. Each thread shares all resources of the process, including its address space. Each thread has a stack. The linker sets the stack size for all threads that are created in a process (/STACK). An individual thread can have its own stack size by calling CreateThread and using the STACK_SIZE_PARAM_IS_ A_RESERVATION parameter. A thread also contains the state of the CPU registers, known as the context, and an entry in the execution list of the system scheduler. You can use the GetThreadContext function to retrieve the context of the specified thread and the SetThreadContext function to set the context of the specified thread. Each thread in a process operates independently. Unless you make the threads visible to each other, they execute individually and are unaware of the other threads in a process. Threads sharing common resources must coordinate their work by using a synchronization method. An application starts when the system scheduler gives one of its threads execution control. The system scheduler determines which threads should run and when they should run. Threads of lower priority might need to wait while higher priority threads complete their tasks.
152
Threads can be in one of the following states: Running Suspended Sleeping Blocked Terminated When all threads are in the blocked state, CE enters idle mode, which stops the CPU from executing instructions and consuming power at high levels. From idle mode you can switch into suspend mode if there is no user activity. Suspend mode can be controlled by the OEM and applications. To conserve power, use synchronization objects to block threads that are waiting, instead of creating a thread that polls for status, such as the PeekMessage function.
6.8 Multitasking and Scheduling

Scheduling is an important issue in any RTOS. During scheduling, the kernel maintains a priority list of each thread in the operating system (OS). Each process can contain multiple threads, and each thread is a path of execution. The scheduling system controls the order in which these different paths of execution are sequenced, and allows the paths to interact with each other in a predictable fashion. When interrupts occur in the scheduling system, the scheduler takes the interrupts into account and reprioritizes the threads accordingly. An application developer can create a miniature custom scheduling system internally in a thread through the use of fibers in that thread. The time slice is used by the scheduler to make scheduling decisions.
Figure 6.8 Example of Thread scheduling. Thread 1 has the highest priority and runs to completion, Threads 2 & 3 have the same priority and execute in a round robin manner.
153
CE uses a priority-based time-slice algorithm to schedule the execution of threads as seen in Figure 6.8. Threads with the same priority run in a roundrobin fashion: when a thread stops running, all other threads of the same priority run before the original thread can continue. Threads at a lower priority run only after all threads with a higher priority finish or are blocked. If one thread is running and a thread of a higher priority is unblocked, the lowerpriority thread is immediately suspended and the higher-priority thread is scheduled. A thread gets to run for set length of time, called a quantum. Typically 100 milliseconds A quantum of 0 means the quantum never runs out The thread can run until blocked or interrupted OEMs can specify a different quantum. A Thread runs until: Its quantum runs out It is interrupted by a higher priority thread Its blocked by a resource contention, such as access to a critical section, a semaphore, or a mutex After a thread has used up its quantum, and if any thread with the same priority is ready to run, the current thread is suspended and another thread is scheduled to run. The only exception to this is if a thread is a "run to completion" thread, which means that the thread quantum is equal to 0. Threads with a quantum set to 0 will never expire and will never be preempted by threads of the same priority. In CE 6.0, the default time slice is 100ms. The time slice can be configured between 1 and 100ms. The scheduler runs the highest priority task. Tasks with the same priority will execute in a round robin manner. No aging algorithm is used in the scheduler, so starvation (low priority threads or processes that never run) is possible. Users need to design application programs carefully and assign priority levels judiciously to prevent starvation. 6.8.1 Priority Levels CE offers 256 priority levels, with zero being the highest priority and 255 being the lowest priority. Many higher priority levels (247 through zero) are assigned to real-time applications, drivers, and system processes. To prevent random applications from degrading the performance of the system, an OEM can restrict all priority levels between 247 and zero to OEM-specified applications. Use CeSetThreadPriority and SetThreadPriority to assign a priority level to a thread. Use CeGetThreadPriority and GetThreadPriority to retrieve the priority level of a thread. The priority level system has four ranges, shown in table 6.3.
154
Range 0 through 96 97 through 152 153 through 247 248 through 255 6.8.2 Priority inversion
Table 6.3 Priority Levels Description Reserved for real-time above drivers. Used by the default CE-based device drivers. Reserved for real-time below drivers. Maps to non-real-time priorities.
Priority inversion occurs when a mutex or critical section held by a lowerpriority thread delays the execution of a higher-priority thread when both are contending for the same resource. For mutexes and critical sections, to correct this situation and free the hig herpriority thread, with priority inheritance, CE enables the lower-priority thread to inherit the more critical thread's priority and run at the higher priority until it releases its use of the resource. Priority inheritance does not apply to semaphores, which do not have a specific owner associated with them. Because an unbounded amount of time is needed to relinquish the inverted thread and it is out of the control of the kernel, the OEM loses control of the scheduling process. To guarantee real-time performance, OEMs should ensure that a priority inversion condition does not occur.
Figure 6.9 Priority Inversion Example.
Consider the example seen in Figure 6.9 that shows how a system without priority inheritance could lead to poor thread scheduling.
155
Suppose an application has three threads: Thread 1 has high priority Thread 2 has medium priority Thread 3 has low priority Thread 1 and thread 2 are sleeping or blocked at the beginning of the example. Thread 3 then runs and enters a critical section. At that moment, thread 2 begins running, preempting thread 3 because thread 2 has a higher priority. So, thread 3 continues to own a critical section. Later, thread 1 begins running, preempting thread 2. Thread 1 tries to enter the same critical section that thread 3 owns, but because it is owned by another thread, thread 1 blocks, waiting for the critical section. At that point, thread 2 would begin running because it has a higher priority than thread 3, and thread 1 is not running. Thread 3 would never release the critical section that thread 1 is waiting on because thread 2 would continue running. So, the highest-priority thread in the system, thread 1, becomes blocked waiting for lower-priority threads to execute. To resolve the threading issue, CE enables priority inheritance to a depth of one level. In the preceding example, when thread 1 is blocked as it waits for thread 3 to complete, CE boosts the priority of thread 3. When the priority of thread 3 is boosted, it runs and eventually releases the shared resource to thread 1. After the shared resource is released by thread 3, CE restores thread 3 to its original priority and thread 1 then runs. However, if thread 3 is blocked and waiting for another thread, X, to release an object, CE does not boost the priority of thread X, which might be the lowest priority thread. Supporting multiple levels of priority inversion would have a negative impact the real-time performance. If the priority of a thread is inverted, the thread receives a fresh quantum when its priority is no longer inverted.
6.9 Real-Time Performance

Real-time performance is defined for the CE operating system (OS) as follows: Guaranteed upper bound on high-priority thread scheduling only for the highest-priority thread among all the scheduled threads. Guaranteed upper bound on delay in executing high-priority interrupt service routines (ISRs). The kernel has a few places where interrupts are turned off for a short, bounded time. Fine control over the scheduler and how it schedules threads.
A real-time system is a set of all system elements, the hardware, operating system, and applications that are all needed to meet the system requirements. A real-time operating system (RTOS) is one element of that system. A real-time application is designed to manage time-critical systems, such as manufacturing process controls, high-speed data acquisition devices, or
156
telecommunications switching equipment. The unique characteristic of a realtime application is that it not only provides the correct response, but also responds within a specified period. The CE kernel contains functionality that improves its performance as an RTOS. The following list shows the kernel capabilities that CE supports as an RTOS: Support for up to 32K processes and 256 thread priority levels Support for handling priority inversion with priority inheritance Support for nested interrupts to ensure that high-priority events are not delayed Support for one-millisecond system tick timing Advanced thread timing and scheduling Support for semaphores The CE kernel achieves real-time performance by the following design of the kernel and the drivers: The majority of the kernel and driver code can be interrupted The uninterruptible parts are in small discrete units so interrupts can be handled quickly The length of the largest part determines the maximum latency
Response times seen in table 6.4 have been measured and published for CE 5.0 and times for CE 6.0 are stated to be the same or slightly improved. The test system included the following hardware and software: Samsung SMDK2410 development board 200 MHz ARM with 16x16 cache Windows CE 5.0 with full UI Running a WMV video Table 6.4 Windows CE 5.0 Real-Time Test Interrupt ISR Response Times starts Minimum 1.2 s Average 3.3 s Maximum 13.3 s Results IST starts 31.7 s 67.2 s 103.0 s
The response times in Table 6.4 are around 10 times faster than Linux according to a recent study15. As seen in Figure 6.10, these response cycle times are several orders of magnitude faster than would typically be seen in a general purpose desktop Windows OS, and fall well within the response time range of a hard real-time OS.
MEDC 2006 Conference Presentation EMB213, Windows CE vs. Linux, Claus Rohde, Garz & Fricke GmbH.
15
157
100 ms
Response Cycle Time
Soft Real-Time
20 ms 10 ms 5 ms
Hard Real-Time
Windows CE
Hard Real-Time Linux?
Windows XP
1 ms 500 us 0
100 s
1,000 s
5,000 s
10,000 s
Cycle Variation or Jitter (s)
Figure 6.10 CE Real-Time Performance Measurements. Soft and Hard Real-Time categories are based on OMAC study and OS times are without any third-party real-time extensions to the OS.
6.10 Synchronization Primitives

In an OS where several threads run concurrently, it is important to be able to synchronize the activities of various threads. Recall that any processes or threads that share global variables or resources require the use of synchronization techniques (i.e., mutual exclusion in critical code sections that access global variables, bounded waiting, and progress conditions must all be met) or errors will result. CE provides several synchronization objects that enable you to synchronize a thread's actions with those of another thread. These objects include critical sections, mutexes, events, and semaphores. Critical sections are data structures allocated by the application (often statically allocated) that are initialized before use. This means the OS does not actually own the object instance and it cannot be shared across processes. Critical Sections are extremely efficient when the code normally does not need to block. In this case there is no transition to the kernel so there is little actual overhead involved. If it does need to block, a critical section actually resolves to the equivalent of a Mutex so is not as efficient if a lot of blocking is expected. Profiling code with the Kernel Tracker will help to reveal how your code behaves under real conditions.
158
Mutexes are, as the name implies, Mutual Exclusion objects and are similar to Critical sections. The principal difference is that Mutexes are true OS Kernel Objects with a handle and can be named for use across processes. It is therefore important to Close the handle to a Mutex when it is no longer needed to prevent leaking a kernel resource. Mutexes have more overhead than Critical Sections because they require a call into the kernel. The state of a semaphore object is signaled when its count is greater than zero and non-signaled when its count is equal to zero. The InitialCount parameter of CreateSemaphore () specifies the initial count. Each time a waiting thread is released because of the semaphore's signaled state, the count of the semaphore is decreased by one. Use the ReleaseSemaphore () function to increment a semaphore's count by a specified amount. The count can never be less than zero or greater than the value specified in the MaximumCount parameter. Multiple processes can have handles of the same semaphore object, enabling use of the object for inter-process synchronization. To share an object, a process can specify the name of a semaphore object in a call to the CreateSemaphore () function. Events objects are typically used to indicate that something has occurred, as opposed to synchronizing access to a shared resource. The initial state of the event object is specified by the InitialState parameter. Use the SetEvent function to set the state of an event object to signaled. Use the ResetEvent function to reset the state of an event object to nonsignaled. When the state of a manual-reset event object is signaled, it remains signaled until it is explicitly reset to nonsignaled by the ResetEvent function. Any number of waiting threads, or threads that subsequently begin wait operations for the specified event object, can be released while the object's state is signaled. When the state of an auto-reset event object is signaled, it remains signaled until a single waiting thread is released; the system then automatically resets the state to nonsignaled. If no threads are waiting, the event object's state remains signaled. Events can also be pulsed, which will always reset the event object back to its nonsignaled state. The state of a manual-reset event object signaled by SetEvent remains signaled until it is set explicitly to the nonsignaled state by the ResetEvent function. All waiting threads, or threads that subsequently begin wait operations for the specified event object by calling one of the wait functions, will be released while the object's state is signaled. The state of an auto-reset event object signaled by SetEvent will remain set until a single waiting thread is released, at which time it will transition to nonsignaled. A manual-reset event object signaled by PulseEvent will release all waiting threads and immediately transition back to nonsignaled. An auto-reset event object signaled by PulseEvent will release at most one waiting thread and immediately transition back to nonsignaled. If no threads are waiting the event will still transition to nonsignaled releasing nothing. Use the CloseHandle function to close the handle. The system closes the handle automatically when
159
the process terminates. The event object is destroyed when its last handle has been closed. Each object type, such as memory maps, semaphores, events, message queues, mutexes, and watchdog timers, has its own separate namespace. Empty strings, "", are handled as named objects. On Windows desktop-based platforms, synchronization objects all share the same namespace. Additionally, you can use interlocked functions to synchronize a thread. Regardless of the synchronization method you use, a thread synchronizes itself with another thread by releasing a synchronization object and then entering a wait state. The synchronization object tells the OS what special event must occur before the thread can resume execution. When the event occurs, the thread is again eligible to be scheduled for CPU time. After it is scheduled, the thread continues executing. The thread has now synchronized its execution with the occurrence of the event. All processes must protect against the casual exchange of data. However, occasionally two processes might also need to communicate with each other. One method that enables processes to communicate is called interprocess synchronization. Because multiple processes can have handles to the same event or mutex object, these objects can be used to accomplish interprocess synchronization. The process that creates an object can use the handle returned by the CreateEvent or CreateMutexfunction. Other processes can open a handle to the object by using the object's name in another call to the CreateEvent or CreateMutex functions. Named objects provide a way for processes to share object handles. After a process creates a named event or mutex object, other processes can use the name to call the appropriate function, either CreateEvent or CreateMutex, to open a handle to the object.
160
6.11 Interprocess Communication

CE supports both the shared memory and message passing models for interprocess communication. There are many instances where memory sharing takes place. The most common is buffer passing between user processes, drivers, and servers. It is also possible for user applications to share memory with each other. In CE, CeRemoteHeapCreate and CeRemoteHeapTranslatePointer let you create a heap that is shared only between a kernel or user mode server, and a client, where the server can allocate, free, read, and write, while the client can read and write but cannot corrupt heap metadata. Memory mapped files allow multiple processes to communicate using a file object as the underlying communication medium. The file can be real or memory backed, and the mapping allows data to be accessed with regular pointers. The operating system takes care of ensuring all processes see the same data. For memory mapped pointers in CE, use the functions, CeOpenCallerBuffer with CeCloseCallerBuffer , CeAllocAsynchronousBuffer , and CeFreeAsynchronousBuffer. Use ReadProcessMemory along with WriteProcessMemory. Pair the pointer with a process identifier, and pass them around together. Use the VirtualAllocEx, VirtualCopyEx , and the VirtualAllocCopyEx functions to alias memory between processes. These mechanisms are typically implemented by drivers or user/kernel mode process servers. CeOpenxxx/CeClosexxx are actually implemented using Read/WriteProcessMemory . These are helper functions typically used by drivers or kernel/user mode servers to access a client process memory buffer. Read/WriteProcessMemory can be used by any process, but requires a handle to the target process. VirtualAlloc/CopyEx functions also require a handle to the target process. VirtualCopyEx can only be called from kernel mode. Point to Point message queues allow processes to pass messages efficiently. This is not a true shared memory implementation, but is low overhead and useful in many scenarios. Message Queue Point-to-Point Functions The following message queue functions are provided in CE: CreateMsgQueueCreates or opens a user-defined message queue. OpenMsgQueueOpens a handle to an existing message queue. CloseMsgQueueCloses an open message queue. ReadMsgQueueReads a single message from a message queue. WriteMsgQueueWrites a single message from a message queue. GetMsgQueueInfoReturns information about a message queue.
The WM_COPYDATA message is sent when an application passes data to another application. The WM_SYSCOPYDATA message is sent when a system component passes data to another system component.
161
Message Queuing (MSMQ) is a completely different type of messaging system that is used for high level communications between devices over a network. MSMQ is not used for interprocess communication on the same device.
6.12 Interrupt Processing

Real-time applications use interrupts to respond to external events in a timely manner. To do this, CE breaks interrupt processing into two steps: an interrupt service routine (ISR) and an interrupt service thread (IST). The ISR runs right away, the IST can take the time it needs to do its work. Each interrupt request (IRQ) is associated with an ISR. An ISR can respond to multiple IRQ sources. When interrupts are enabled and an interrupt occurs, the kernel calls the registered ISR for that interrupt. Once finished, the ISR returns an interrupt identifier. The kernel examines the returned interrupt identifier and sets the associated event. When the kernel sets the event, the IST starts processing. The exception handler is the primary target of all interrupts. When an interrupt occurs, the microprocessor transfers control to an exception handler in the kernel. The exception handler then calls the ISR registered to handle the current interrupt. The ISR is responsible for translating the interrupt into a logical interrupt identifier, a SYSINTR, which it passes to the kernel as its return value. The kernel sets an event associated with the logical interrupt, which causes an interrupt service thread (IST) to be scheduled. Code in the IST is responsible for servicing the device interrupt. The servicing of an IRQ in Windows Embedded CE 6.0 begins with the kernel, which traps all exceptions and then determines the appropriate action. In the case of an IRQ, the kernel traps the IRQ, saves the registers supported for the ISR, and calls the ISR you specified. Examples of a hardware IRQ could be change of state on a serial com port or the push of a button on a bar code reader. The ISR is located in the OAL. An interrupt service routine (ISR) is code that handles interrupt requests (IRQs) on your target device. The ISR is core to the OAL and is responsible for locating an interrupt source, masking it, and returning a unique identifier to the Windows Embedded CE 6.0 kernel to indicate which driver needs to be used to handle the event. When support for other interrupt sources are added to the ISR, there are other interrupt support routines which will need to be implemented for mapping hardware interrupts to unique identifiers IRQ to SYSINTR mappings, enabling and disabling interrupts, and so on. Using the OAL code, CE associates each IRQ with an ISR. When an interrupt occurs, the kernel's exception handler calls the registered ISR for that interrupt. Using the HookInterrupt function in the OAL, you can register only one ISR for each IRQ line. However, you can associate an ISR with one or more interrupt identifiers. When the ISR returns to the kernel, the kernel examines the returned interrupt identifier and sets the associated event. The corresponding IST in the device driver is waiting on the event and is released to handle the interrupt when it becomes the highest priority thread in the system. To manage
162
ISRs, you must implement the ISR management functions that allow the kernel to begin, service, and complete interrupt processing. The interrupt service thread (IST) is a thread that does most of the interrupt processing. The OS wakes the IST when the OS has an interrupt to process. Otherwise, the IST is idle. A device driver or the OAL can associate the interrupt identifier with an event by creating an IST and calling the InterruptInitialize function. The IST then waits for the event. The IST calls functions in the hardware platform-dependent driver layer to read from and write to the target device. For the OS to wake the IST, the IST must associate an event object with an interrupt identifier. Use the CreateEventfunction to create an event object. After an interrupt is processed, the IST should wait for the next interrupt signal. This call can be inside a loop. When the hardware interrupt occurs, the kernel signals the event on behalf of the ISR, and then the IST performs necessary I/O operations in the device to collect the data and process it. When the interrupt processing completes, the IST should inform the kernel to reenable the hardware interrupt. Usually, IST threads run at above-normal priority. They can boost themselves to a higher priority before registering their event with the kernel by calling CeSetThreadPriority .
Figure 6.11 Processing an Interrupt in CE with an ISR and IST.
163
Figure 6.11 shows the steps involved in interrupt processing in CE: 1. The hardware generates an interrupt request (IRQ). 2. The Interrupt Service Handler (ISH) is the target for all interrupts and exceptions. It operates with interrupts off. The support handler sets up the stack etc. for the callable ISRs and determines the appropriate ISR to call. 3. The ISR examines the hardware to determine if it is a valid interrupt and returns the logical ID for the interrupt (SYSINTR_xxx) or SYSINTR_NOP. The ISR typically disables the interrupt for this IRQ at the interrupt controller to prevent further interrupts until processing is completed. 4. The interrupt support handler looks up the SYSINTR in an internal table and finds the event associated with that ID. It sets that event so the scheduler may schedule and run it. 5. The interrupt support handler re-enables interrupts for all interrupts. 6. Once the IST associated with the IRQ is the highest priority runnable thread the scheduler switches to that thread to process the interrupt. 7. The IST exits its WaitForSingleObject() call on the interrupt event and processes the interrupt. It should minimally clear or disable the interrupt at the device then call InterruptDone() before further processing. 8. InterruptDone() re-enables the IRQ at the interrupt controller for other interrupts to occur. This is why it should be called as soon as possible since other devices sharing the interrupt are blocked. 9. The IST continues processing and clears and re-enables the interrupt at the device and goes back to wait for another interrupt. The enabling of higher priority interrupts is the responsibility of the ISR in the OAL. It is also the responsibility of the OAL/ISR to disable the interrupt being handled or to clear the interrupt at the source to allow further interrupts to be processed correctly. One of the most important aspects of kernel real-time performance is the ability to service an IRQ within a specified amount of time. Interrupt latency refers primarily to the software interrupt handling latencies; that is, the amount of time that elapses from the time that an external interrupt arrives at the processor until the time that the interrupt processing begins. If paging does not occur, CE interrupt latency times are bounded for threads locked in memory. This makes it possible to test for the worst-case latencies the total times to the start of the ISR and to the start of the IST. The total amount of time until the interrupt is handled can then be determined by calculating the amount of time needed within the ISR and IST.
164
Latency for an ISR includes the time required for the kernel to vector to the ISR handler (normal) saving registers, etc., and the amount of time that interrupts are turned off (varies). ISR latency is the interval that begins when an IRQ is set in the CPU and ends when the ISR begins to run. The start of the ISR that is being measured can be calculated based on the current status of other interrupts in the system. If an interrupt is in progress, calculating the start of the new ISR to be measured must account for two factors: the number of higher-priority interrupts that will occur after the interrupt of interest has occurred and the amount of time spent executing an ISR. To prevent the loss and delay of high-priority interrupts, the CE kernel uses nested interrupts. Nested interrupts allow interrupt requests (IRQs) of a higher priority to preempt IRQs of a lower priority. Nested interrupts are allowed in conjunction with the Real-Time Priority System. ISRs of a higher priority might preempt ISRs of a lower priority. The kernel handles the details of saving an ISR's state when a higher priority interrupt occurs and restoring it after the high priority ISR has completed. In most cases, a preempted ISR does not detect that it has been preempted. The level of interrupt nesting is limited solely by what the hardware platform can support. An ISR that uses too much time can cause other interrupts to be missed entirely, resulting in erratic or sluggish performance of the whole system. By separating interrupt processing into a very short ISR and a longer interrupt service thread (IST), interrupts can be masked for as little time as possible. ISRs only mask interrupts of equal or lower priority than themselves. CE can nest as many ISRs as the hardware platform supports. Other than a possible delay in completion, an ISR is not affected by a kernel interrupt reprioritization.
165
6.13 Device Drivers

A device driver is software that abstracts the functionality of a physical or virtual device. A device driver manages the operation of these devices. Examples of physical devices are network adapters, timers, and universal asynchronous receiver-transmitters (UARTs). An example of a virtual device is a file system. Implementing a device driver allows the functionality of your device to be exposed to applications and other parts of the operating system (OS). While developing a device driver, take advantage of the basic services provided by the OS. The CEDDK library functions should be used whenever possible for low level operations in device drivers. Many CE device drivers implement the stream interface. The core stream interface entry points are XXX_Open , XXX_Close , XXX_Read , and XXX_Write. Network adapters, display adapters, mouse devices, keyboards, and other special-purpose devices do not use the stream interface. These devices use an interface that suits the device's functionality. Different processes will load different device drivers. Although CE device drivers are privileged modules, they do not have to run in kernel mode. Most CE device drivers consist of a platform dependent driver (PDD) and a model device driver (MDD). A monolithic driver combines all PDDs and MDDs into one driver. A layered driver does not combine them. MDDs have the following characteristics: Contain code that is common to all drivers of a given type. Call PDD functions to access the hardware. Link to the PDD layer and define the device driver service provider interface (DDSI) functions that the MDD expects to call in that layer. Expose device driver interface (DDI) functions to the operating system (OS). Other parts of the OS can call these functions. Related devices can share the same DDI. Monolithic drivers also expose the DDI functions. Handle interrupt processing. Provide for reuse by developers. Can link to multiple PDDs. Generally require no changes. If changed, you might have trouble migrating drivers to future versions. Contain any interrupt service threads (ISTs). PDDs have the following characteristics: Consist of hardware platform specific code. Might require modification for your hardware platform. Are designed to work with specific MDD implementations. Expose the DDSI functions that the MDD calls. Monolithic drivers do not expose the DDSI functions.
166
The following list shows considerations for choosing between implementing a layered driver or a monolithic driver: A layered driver might only require modification to the PDD. (i.e., a device with several identical COM ports) A layered driver adds overhead to function calls in a device driver because the MDD calls into the PDD. A monolithic driver improves driver performance because it combines the MDD and PDD into one layer, which removes the MDD's function calls into the PDD. A monolithic driver is more difficult to migrate to future versions of CE because most device drivers that CE includes are divided into a PDD and an MDD. A monolithic driver can be simpler and more efficient, if the capabilities of your device are well matched to the tasks that the functions in the MDD layer perform. In CE 6.0 sample source code is provided for a number of drivers and a wide assortment of commonly used device drivers are provided. More detailed information on device driver development will be presented in Chapter 9. The Device manager loads all drivers into kernel space as ker nel mode drivers unless the DEVFLAGS_LOAD_AS_USERPROC flag is set in the registry. Kernel mode drivers provide the best performance since they can call kernel APIs directly using the kernel version of coredll called k.coredll.dll . Kernel drivers can synchronously access user buffers very quickly because user memory is directly available. Kernel mode drivers must be robust because they have unlimited access to memory. A fault in a kernel mode driver could corrupt kernel memory causing a system crash.
6.14 User Mode Drivers

The purpose of the User Mode (Device) Driver Framework is to allow an intermediate driver to load into user mode. A User Mode Driver will not be able to access hardware directly. For some drivers, this method of interaction will increase system stability. Virtual memory mapping is used to protect the kernel from user mode programs. Memory protection of the kernel is provided since the driver runs in user mode. The User Mode Driver Framework is divided into two physical components. The first component is the User Mode Driver Reflector, which resides inside the device manager. The second component is the User Mode Driver Host, which is a user mode application that is launched and managed by the User Mode Driver Reflector. From the user perspective, the reflector makes the user mode drivers work as if they were kernel mode drivers. When a driver is flagged as a User Mode Driver in the registry, the device manager will access the User Mode Driver Reflector. The User Mode Driver Reflector launches the appropriate User Mode Driver Host process and
167
forwards I/O requests to it. The User Mode Driver Host process in turn forwards I/O requests to the User Mode Driver.
User Mode Driver Host Process User Application
4
User Mode Driver udevice.exe
User Mode 1 Kernel Mode Device Manager
3 2
5
Reflector Service
1
Parent Bus Driver
Figure 6.12 User Mode Driver Architecture
The process of using a User Mode Driver begins with a user application or with a parent bus driver. User applications and parent bus drivers can load User Mode Drivers by calling ActivateDevice or ActivateDeviceEx . User applications and parent bus drivers can unload User Mode Drivers by calling DeactivateDevice . Once loaded, any user application or driver can access the User Mode Driver by using the device handle. If the driver is a User Mode Driver, the call to ActivateDevice or to ActivateDeviceEx will result in the device manager calling the User Mode Driver Reflector function as well. A driver is recognized as a User Mode Driver when the FLAGS value is set to the setting DEVFLAGS_LOAD_ AS_USERPROC (0x10) in the registry key of the device. The User Mode Driver Reflector, which is aware of the original process and the destination process, uses CeFsIoControl to forward the device manager's request to the User Mode Driver Host. The User Mode Driver Host then parses the request to either load, unload, or call the parent bus driver's entry. The User Mode Driver has restricted access rights to the hardware, which prevents it from being able to accommodate requests such as mapping physical memory or calling interrupt functions. To accomplish these types of requests, the User Mode Driver calls the User Mode Driver Reflector, and enables the User Mode Driver Reflector to handle the request. The User Mode Driver Reflector then checks the user request against the registry settings to determine
168
whether it should perform the requested action. Unlike with interrupts and the mapping of physical addresses, the User Mode Driver can, via the device handle and without the aid of the User Mode Driver Reflector, access the parent bus driver regardless of where the parent bus driver is located.
6.15 The Registry

The registry is a system database that stores configuration information for applications, drivers, and the operating system (OS). For application programs, the registry is most commonly used for storing state information across invocations. For example, an application might have windows that a user can move and resize. Before exiting, the application could store its windows information in the registry. Then when the application starts again, it could retrieve the information and position its windows accordingly. The OS also uses information in the registry to locate and load device drivers, when a new hot-pluggable device appears. User applications written to run on multiple devices can query the registry to determine what hardware is present on a device. The structure of the CE registry is similar to the registry in the desktop versions of Windows. The registry contains a forest of data subtrees. Each subtree is composed of branches called keys, and each key can contain subkeys and/or entries. Entries are stored as name/value pairs. At the base of each subtree is the root, which is identified using a well-known constant value, or HKEY. Table 6.5 shows the root constants supported by CE and gives a brief description of each:
Table 6.5 Registry Root Constants Root key constant Description HKEY_CLASSES_ROOT Stores file type matching and OLE configuration data. HKEY_CURRENT_USER Stores user-specific data for the user who is currently logged in. This root points to the relevant key of HKEY_USERS. Changes made are automatically made in the user's key under HKEY_USERS. HKEY_LOCAL_MACHINE Stores machine-specific data and configuration information for device drivers and applications. HKEY_USERS Stores data for all users including a default user. The basic piece of data that is stored in the registry is called a value. A value can be a variety of types, including string or binary. Each value has a name and an associated piece of data. For example, a device that is running the CE Handheld PC, Professional Edition, software uses the value name Wrap to Window in the HKEY_LOCAL_MACHINE\Software\Microsoft\Pocket
169
Word\Settings key to store an integer piece of data for the Pocket version of Word. Most registry operations require the use of registry functions. The CE registry exports the Win32 registry functions for applications to call to record and access run-time and other data. Use the registry to store data that your application needs for each session. For example, you can save the state of your application during the shutdown process. Upon startup, your application can reinstate the previous settings. Registry space is limited, so users should minimize the use of the registry by their applications to just a few keys and pack data into bit fields if necessary to minimize the number of keys required. CE supports two types of registries, RAM-based and hive-based. By default, CE 6.0 implements the hive-based registry. The registry type is invisible to applications, but changes the persistence, boot sequence and speed, and memory usage on a target device. The choice of registry type and registry settings also affects the behavior of user profiles. A special tool called Regedit is provided to edit the registry in Platform Builder. Platform Builder generates initial registry entries for the target device along with the OS image code. User profile support is present in all file system configurations. No components need to be added to use user profiles. 6.15.1 RAM-Based Registry The RAM-Based Registry stores all registry data within the object store. This is efficient in terms of speed and size in devices that have battery-backed RAM. Devices that do not power the RAM while turned off must back up the registry during power off and restore the registry when power is restored. The RAMbased registry is intended for use on devices that experience warm boot often, but rarely or never cold boot. 6.15.2 Hive-Based Registry The Hive-Based Registry stores registry data inside files, or hives, which can be kept on any file system. This removes the need to perform backup and restore on power off. Removing this work during boot and power off makes the cold boot process faster. Each file or hive contains a collection of registry data. The hive-based registry is split into two hives: the system hive, which contains all system data, and the user hive, which contains all data pertinent to one particular user. A multi-user system will contain several user hives. A user's hive will be mounted on logon and unmounted on logoff. The hive-based registry is intended for use on devices that cold boot often, but rarely or never warm boot. It is also useful on devices that require support for multiple users.
170
A hive is a group of keys, subkeys, and values in the registry that has a set of supporting files containing backups of the data in the hive. A hive is treated as a single unit and is saved and restored as one file.
6.16 Device Manager

The Device Manager is loaded by the kernel, it runs continuously, and it manages loaded device drivers and their interfaces. When the Device Manager loads, it also loads the I/O Resource Manager to read a list of available resources from the registry. The Device Manager tracks interfaces advertised by drivers and supports searches for drivers based on a globally unique identifier (GUID). The IClass interface can associate an interface GUID with the driver's legacy name, its $device name, or its $bus name. For example, COM1:, $device\com1, or $bus\pci_0_3_0. Device Manager is a process that runs under the CE operating system tracking loaded drivers and their interfaces. It runs continuously and launches from the kernel. Device Manager can notify the user when device interfaces become available and unavailable. A user or the system itself can make device interfaces available or unavailable. Additionally, Device Manager notifies the kernel that a device interface supports file operations, such as CreateFile, to access devices that expose the stream interface. Device Manager sends power notification callbacks to device drivers and provides power management services. Device Manager controls the Active key in the registry. Only Device Manager should access the Active key for read or write access. You can indirectly access the Active key through a parameter to a device driver's initialization function. Device Manager searches the HKEY_LOCAL_MACHINE\Drivers\RootKey registry key to determine the key to begin the driver loading process. The default value of RootKey is Drivers, but it is usually equal to Drivers\BuiltIn. Device Manager calls ActivateDeviceEx to load the driver specified by the Dll subkey's value found in the key specified by the RootKey value. The Dll subkey's value is by default BusEnum.dll, also referred to as the bus enumerator. Loading BusEnum.dll causes all device drivers to load. A device loaded by ActivateDeviceEx can read its activation handle from its Active registry key. Device Manager associates a bus name with drivers. Unnamed devices can also have a bus name because even though applications might not be able to access the driver, the driver can be accessed by other drivers or system entities, such as the Power Manager. The bus name can have a different ACL from the regular device name. Drivers can programmatically advertise interfaces by calling DMAdvertiseInterface . DMAdvertiseInterface enables drivers to add more searchable GUIDs to their associated lists. DMAdvertiseInterface is exposed by Devmgr.dll , which also implements most Device Manager functionality. Because only the Device Manager can load Devmgr.dll, only device drivers can
171
call DMAdvertiseInterface . If a device driver does not advertise the unavailability of its interfaces when the driver is unloaded, Device Manager automatically cleans up the interface advertisement notification. 6.16.1 Device Manager Components Device Manager consists of Device.exe and Devmgr.dll. Device.exe contains Devmgr.dll, which implements the core Device Manager functionality. Because Device Manager consists of two separate modules, device drivers can link directly with Device Manager and invoke specific functions, such as DMAdvertiseInterface , without incurring the overhead of a system call. Table 6.6 shows the components of Device Manager. Table 6.6 Device Manager Components Component Description devcore Provides the core Device Manager functionality. iorm Provides the I/O Resource Manager functionality. Iorm is a required component and cannot be removed. pmif Pmif provides the interface to Power Manager DLL entry points. nopmif Nopmif provides the stubbed version of the Power Manager entry points. A device driver is software that abstracts the functionality of a physical or virtual device. A device driver manages the operation of these devices. Different processes load different drivers. Table 6.6 shows the processes that load drivers and what drivers each process loads. Table 6.6 Processes that Load Drivers. Drivers FileSys.dll loads file system drivers. For more information, see the section on File Systems. Device.exe loads audio drivers, battery drivers, keyboard drivers, mouse drivers, NDIS drivers, notification LED drivers, serial drivers, PC Card drivers, USB drivers, and any other driver that exposes the stream interface. Device.exe loads most of its drivers with ActivateDeviceEx, and these drivers expose a stream interface. GWES.dll loads a device driver if GWES is the only client of a driver. Device drivers loaded by GWES present a standard set of functionality for all similar devices. Drivers that GWES loads might expose the stream interface or they might expose other interfaces. Having alternatives make accessing the drivers much faster. GWES loads display drivers, printer drivers, and touch screen drivers.
Process File System (FileSys.dll) Device Manager (Device.exe)
Graphics, Windowing, and Events Subsystem (GWES.dll)
172
6.16.2 I/O Resource Manger When the system boots, the bus enumerator enumerates the registry and loads all the built-in devices based on this registry information. You can configure this registry information. The I/O Resource Manager then tracks the current state of resources available in the system and manages all further I/O resource requests and allocations by bus drivers. Consequently, all bus drivers should request I/O resources from the I/O Resource Manager when they load a client driver for installable devices or other types of devices. The I/O Resource Manager is an intrinsic part of Device Manager. The I/O Resource Manager tracks the available system resources initialized from the registry before any devices are loaded. Tracking these resources prevents accidental collisions when two or more device drivers attempt to use the same resources. The OAL and the registry usually pre-allocate IRQ and I/O space resources that bus drivers request. However, the I/O Resource Manager is not limited to managing I/O and IRQ spaces. The specific set of resources available can include any that you define. Bus drivers, such as the PCI bus driver, request IRQ and I/O space resources from the I/O Resource Manager as it loads device drivers for the devices it finds. The same is true for the PC Card bus driver and I/O resources required by PC Card client drivers. The PC Card bus driver releases resources as users remove PC Cards from the system. Every hardware platform has unique IRQs and I/O space available. IRQs for built-in and fixed devices should map to interrupt identifiers (SYSINTRs) in the OAL. The IRQs for built-in and fixed devices should be excluded from the available resources. IRQs used with the PCI bus are usually shared. IRQs and I/O space resources are predefined. The HKEY_LOCAL_MACHINE\Drivers\Resources\IRQ registry keys and HKEY_LOCAL_MACHINE\Drivers\Resources\IO registry keys provide the initial state of the I/O Resource Manager.
6.17 Loader
The CE loader is responsible for loading modules, which consist of both executables and dynamic-linked libraries (DLLs), into virtual memory so that they can be executed by the operating system (OS). Each module can have several flags associated with it in the Config.bib configuration file. The following properties can be set for each module: System file Hidden file Compress resources Compress everything Prevent a debugger from running Mark a module as untrusted Ignore the CPU type on a per-module basis Fix up the DLL to run properly
173
The loader also handles multiple execute-in-place (XIP) regions so that individual modules can be updated after the initial operating system image file has been written to the device.
6.18 Power Management

Embedded devices often run on battery power and even devices running on AC power need to be designed to be energy efficient. Long battery life is a major design consideration in devices like cell phones. Most operating systems include support for power management by shutting down portions of the hardware and perhaps slowing down the clock during periods of inactivity. The following illustration shows the power states and transitions in CE 6.0.
No power
Clear file system Yes Clean boot signaled? No Yes No Persistent storage file system? Warm boot Power-on reset Battery backup level reaches zero Power-on reset Critical battery-low event Critcal off Clear RAM No Yes Persistent storage file system? Yes Clean boot signaled?
On
Scheduler idle Any interrupt Activity timer time-out Wake-up events
Idle
Suspend
Figure 6.13 CE 6.0 Power States and Transitions.
The Power Manager allows you to manage devices simply and independent of the base CE power management model. In the base CE power model, devices receive notification that the OS is suspending and resuming. This notification occurs in an interrupt context, so devices are severely restricted regarding what they can do during a suspend state and how long they can take to do it. Figure 6.13 shows the power management architecture for CE. Table 6.7 describes the transitions between power states for a CE based target device.
174
Table 6.7 Power State Transitions. Transition Description Power-on Target device clears working RAM and initializes the file system. reset Cold boot First application of power, for example, when a backup battery is installed. Warm Transition from the On power state. A warm boot clears the working boot RAM. On-to-Idle Transition from a fully running state to a state in which the microprocessor is using little power. Idle-to-On Transition of the microprocessor from low-power to full-power operation. On-toTransition to a stopped microprocessor, as a result of certain events. A Suspend device driver's XXX_PowerDown function is called. SuspendTransition of a stopped microprocessor to full-power operation based to-On on specific wake-up events. A device driver's XXX_PowerUp function is called. On-toTransition when critically low battery power is detected. You must Critical off implement the function for transitioning to the Critical Off state for your device.
Notification Message Queue
Application Application APIs Power Manager APIs Driver APIs
Power Manager (pm.dll)
Drivers
Figure 6.14 CE 6.0 Power Manager Architecture.
175
Using the Power Manager, devices receive power state change notifications as I/O control codes (IOCTLs). Because IOCTLs execute in a thread context, driver developers have much more flexibility in how they implement the power state change. Using IOCTLs to manage power also enables separation of device power state from overall OS power state. Thus, some devices can be turned off while the OS is running, and others can be left on while most of the OS is suspended. In addition to managing device power, the Power Manager notifies applications about power-related events. For example, Power Manager informs interested applications when the OS resumes from a suspend state. The Power Manager is implemented as a dynamic-link library (DLL), called Pm.dll, which is linked directly with Device.exe. Device.exe invokes entry points in Pm.dll when power management application programming interfaces (APIs) are invoked. The source for Pm.dll is provided with Microsoft Platform Builder 4.0 and later, and OEMs may customize it for their CE-based device. The Power Manager acts as a mediator between devices, applications, and defined OS power states. It implements the following set of rules to communicate between those three parts: OS power states impose maximum power consumption limits on all devices. Applications impose minimum power consumption limits on specific devices to obtain minimum performance levels. The Power Manager will allow devices to intelligently manage their own power as long as they keep their power levels between the maximum and minimum limits. If the minimum power consumption limit is set higher than the maximum, the power of the device will remain elevated for as long as the application requires the device. Devices can implement one or more device power states. Device power states are limited in number. If the OS transitions to a suspend state, applicationimposed minimum power limits will be set aside while the OS is in a suspend state. System power states describe a maximum device power state for all devices. System power states are defined by the OEM, are described in the registry, and may optionally have code to support them in the Power Manager. The OEM may define any number of system power states. Within the Power Manager framework, OEMs define OS power states that establish maximum device power states. Devices call DevicePowerNotify to regulate their own power levels and applications call SetPowerRequirement to verify that the devices they need are running at an acceptable performance level. The Power Manager manages device power and improves overall operating system (OS) power efficiency, provides power management for each device, and coexists with applications and drivers that do not support t he Power
176
Manager. You can use power management to reduce the power consumption of a target device and to maintain and preserve the file system in RAM during the reset, on, idle, and suspend power states. The Power Manager also provides you with the following capabilities: A framework in which devices can intelligently manage their own power. A mechanism for decoupling the power state of a device from the suspend or resume state of the system. A module that has a global view of the system environment, power status and device power states. You can customize the Power Manager to make system-wide decisions about power that are suitable for your device. The Power Manager expects all managed devices to support one or more device power states. There are a limited number of device power states, and the device must inform the Power Manager of their power consumption characteristics. Device power states generally trade off performance with power consumption. The Power Manager manages device power states within the context of system power states that are defined by the OEM. System power states are described in the registry and any number can be defined. System power states impose an upper bound on device power states. Some applications may require that a given device be maintained at a certain device power level. For example, a streaming audio application might require that its network card and audio codec stay powered at a high level while music is playing. A streaming video application might need network and audio, plus it might want to keep the display from going into screen saver mode and possibly keep the backlight on. Applications can request that the Power Manager set minimum device power state requirements using the SetPowerRequirement and ReleasePowerRequirement APIs.
6.19 OS Security Features

Security services are an essential part of any modern operating system. Communication services, user applications, file systems and data store, and Internet services all require protection for sensitive information. CE provides a toolkit for enhancing the security of a device. However, it is the responsibility of the user to review the security of a device thoroughly and to select the OS components suitable for the device. When adding each new feature, designers should carefully consider the security implications. The following technologies are available for providing increased security in devices and applications: Cryptography and Certificates provide services for using cryptography. These services allow data encryption/decryption schemes, authentication using digital certificates, and encoding/decoding to and from ASN.1 to their applications. Application developers can use the
177
functions in CryptoAPI without detailed knowledge of the underlying implementation. The cryptographic service providers (CSPs) included with CE are RSA Base Provider, Diffie-Hellman/DSS Provider and RSA Enhanced Provider. Secure Socket Layer (SSL) versions 2.0 and 3.0 are supported. These are available through Windows Internet Services (WinInet) or directly from Windows Sockets (Winsock). SSL uses secure sockets to send and receive encoded data over the communication lines. The Credential Manager provides storage for cached credentials, and enables the sharing of common credentials. The Local Authentication Subsystem (LASS) is the infrastructure to provide user authentication independent of the invoking application and authentication mechanism. Password authentication provides only one option, a password, for verification. However, LASS allows you to support sophisticated authentication mechanisms, such as biometrics. In addition, you can use LASS functionality to specify event-based policies to authenticate users. It also supports policy-based authentication using the registry. To help protect sensitive information and to help prevent data tampering, the protected store application programming interface (API) provides a convenient solution to cryptography, key management, and user experience issues. The protected store APIs take the user's logon credentials to lock and unlock the private data. Security Support Provider Interface (SSPI) is a well-defined common interface for obtaining integrated security services for authentication, message integrity, and message privacy. It provides an abstraction layer between application-level protocols and security protocols. You can use one of several security providers without knowing the details of the security protocol. The security providers included with CE are Windows NTLM Security Support Provider (SSP), Schannel (SSL/TLS) and Kerberos SSP. The CE smart card subsystem supports CryptoAPI and the CEbased device driver model for developing smart card readers. Additional PC/SC support facilitates the porting of existing smart card reader drivers and service providers. To help secure your operating system from potentially unsafe operations, operating system developers can specify a trusted environment where only certified applications can run. OEMs can prevent unknown applications from loading, restrict access to system APIs, and prevent write access to certain parts of the system registry.
178
Figure 6.15 CE Security System Architecture.
6.20 OS Networking Features

Networking features and support is a critically important component of any modern operating system. CE provides a number of networking services and features. CE provides support for Internet-based applications. The following network features are provided: A TCP/IP Protocol Suite. This technology supports a set of protocols that allow cooperating computers and devices to share resources across a network. Windows Sockets (Winsock) for CE-based devices specifies a programming interface based on the familiar socket interface from the University of California at Berkeley. It includes a set of extensions designed to take advantage of the message-driven nature of CE. It supports Winsock 2.2, which provides easier access to multiple transport protocols. Following the Windows Open System Architecture (WOSA) model, Winsock defines a standard service provider interface (SPI) between the application programming interface (API) and the protocol stacks. Winsock 2.2, with its functions exported from Ws2.dll, is not limited to TCP/IP protocol stacks as is the case for Winsock 1.1.
179
The IPSec v4 Catalog item, which enables two client devices on a network to establish peer-to-peer communication using the IP Security (IPSec) protocol. This technology enables CE-based devices to participate in networks that are secured by IPSec. Domain Discovery enables a CE device to discover an Active Directory server to query. The Extensible Authentication Protocol implementation allows thirdparty authentication code to interact with the implementation of the Point-to-Point Protocol (PPP) included in the CEbased Remote Access Service (RAS). The Extensible Authentication Protocol (EAP) is also used with 802.1x and EAP over LAN (EAPOL) authentication. The IP firewall is typically used on an Internet gateway device. It can also be used as a host firewall. The firewall helps protect the device on which it runs and helps to protect devices on the private side of the gateway. The firewall blocks IP traffic at the IP and transport layers. Internet Connection Sharing (ICS) for CE consists of a collection of technologies and services that make it possible to connect multiple computing and information devices on a network located in a home, a small business, or a corporate branch office to the Internet through a single Internet connection. The Network Utilities feature for CE provides several tools that you can use to troubleshoot network connections. This includes widely used tools such as ipconfig and ping. Internet Protocol version 6 (IPv6) is a suite of standard protocols that is the next generation of network layer protocols for the Internet. IPv6 is a connectionless, unreliable protocol used primarily for addressing and routing packets between hosts. Connectionless means that a session is not established before exchanging data. Unreliable means that delivery is not guaranteed. IPv6 always makes a best-effort attempt to deliver a packet. An IPv6 packet might be lost, delivered out of sequence, duplicated, or delayed. IPv6 does not attempt to recover from these types of errors. The acknowledgment of delivered packets and the recovery of lost packets are done by a higher-layer protocol, such as TCP. The Windows Networking API/Redirector (SMB/CIFS) implementation in CE provides functions to establish and terminate network connections and to access files on servers supporting the Common Internet File System (CIFS). Access to this data is made possible by way of the networking API (WNet).
The CE operating system implements a Transmission Control Protocol/Internet Protocol (TCP/IP) Suite. The OS includes a standards-based TCP/IP stack, allowing CE based devices to participate as peers and servers on local area networks (LANs) and remote networks.
180
CE supports the following standard characteristics: The ability to bind to multiple network adapters with different media types, for example, 802.3 and 802.5. Logical and physical multihoming capabilities. Internal IP routing capability. Internet Group Management Protocol (IGMP) (IP Multicasting). Duplicate IP address detection. Multiple default gateways. Dead gateway detection. Automatic Path Maximum Transmission Unit (PMTU) discovery. Virtual Private Networks (VPNs). and also has the following performance improvements: Protocol stack tuning, including increased default window sizes. TCP Scalable Window sizes (RFC 1323 support). Selective Acknowledgments (SACK). TCP Fast Retransmit. Support is provided for both Internet Protocol version 4 (IPv4) and version 6 (IPv6). Table 6.8 summarizes the TCP/IP services that are provided. The architecture of the CE TCP/IP Protocol Suite is seen in Figure 6.16.
Service Dynamic Host Configuration Protocol (DHCP) client Windows Internet Name Service (WINS) Domain Name System (DNS) client Extended DNS Querying and Update
Table 6.8 TCP/IP Services Description DHCP clients are dynamically assigned with various configuration parameters, such as an IP address, subnet mask, default gateway, and other critical network configuration information. WINS is a NetBIOS name client that manages the name resolution process by maintaining an up-to-date list of NetBIOS computer names and their respective IP addresses.. CE does not support hosting a DNS server. However, CE queries a DNS server for name resolution if such a server exists on the network. This service provides the Dynamic DNS protocol that allows you to set the device name in a DNS server database. You can do this programmatically or you can configure the device to register its name in the database automatically when its name is changed or when a network adapter becomes available. CE also supports Secure DNS for more secure, dynamic updates. You can now modify or remove multiple resource record sets that are associated with a specific name. Dynamic Query and Modify allows you to query arbitrary records in a DNS Server.
181
Dial-up (PPP/SLIP) support. TCP/IP network printing
Simple Network Management Protocol (SNMP) extension agent Wide area network (WAN) support TCP/IP connectivity utilities
CE implements dial-up networking with Remote Access Service (RAS) and Point-to-Point Protocol (PPP). In CE, TCP/IP supports network printing through the Server Message Block (SMB) protocol. It does not provide the Windows Line Printer Remote (LPR) Spooler. However, independent software vendors (ISVs) and original equipment manufacturers (OEMs) can add this support. The SNMP extension agent provides an MIB-2 subagent that allows the state of TCP/IP to be monitored and controlled.
This service provides users with access to the Internet. Basic TCP/IP connectivity utilities, including File Transfer Protocol (FTP) and telnet servers. The telnet server allows remote administration through a standard telnet client. A sample FTP server is used for copying files to and from remote computer systems over a network using TCP/IP. Many network troubleshooting tools are available for CE, for example, ipconfig, iPv6, ipv6tun, netstat, ping route, and tracert. IP Helper provides application programming interfaces (APIs) that assist in the network administration of the local computer. Microsoft Remote Procedure Call (RPC) is used to creating distributed client/server programs. The RPC run-time stubs and libraries manage most of the processes relating to network protocols and communication. This enables you to focus on the details of an application rather than the details of the network. WinHTTP provides developers with a server-supported, highlevel interface to the HTTP/1.1 Internet protocol.. WinInet handles all communication between an application and Winsock. Applications access the TCP/IP stack through the Winsock interface.
Network Utilities Internet Protocol Helper (IP Helper) Remote Procedure Call (RPC)
Windows HTTP Services (WinHTTP) Windows Internet (WinInet) Windows Sockets (Winsock)
182
Figure 6.16 CE TCP/IP Networking Architecture.
6.21 OS Wireless Networking Features

Several OS features are provided to support wireless networking technologies. Bluetooth is supported in Windows Embedded CE by both Microsoft and third party stacks. Bluetooth is a wireless communication technology that allows devices, within a 10 meter proximity, to communicate with each other. The discovery process enables devices to query other devices about the services they offer. If a device offers more than one service, the user can select the service they want to use from that particular device. Windows Embedded CE supports an IrDA-compliant stack that enables two IR devices to communicate with each other. Many Windows Embedded CE based devices have an infrared port compliant with the Infrared Data Association
183
(IrDA). The IrDA specifies standards for hardware specifications and software protocols. Windows Embedded CE supports a IrDA-compliant stack that enables two IR devices to communicate with each other. Windows Embedded CE provides the framework for various wireless LAN technologies that enable you to implement a range of wireless networking scenarios. Wi-Fi Multimedia (formerly known as Wireless Multimedia Extensions) refers to QoS (Quality of Service) over Wi-Fi. QoS enables Wi-Fi access points to prioritize traffic and optimizes the way shared network resources are allocated among different applications. Without QoS, all applications running on different devices have equal opportunity to transmit data frames. That works well for data traffic from applications such as web browsers, file transfers, or email, but is inadequate for multimedia applications. Voice over Internet Protocol (VOIP), video streaming, and interactive gaming are highly sensitive to latency increases and throughput reductions, and require QoS networks. WMM prioritizes traffic demands from different applications and extends Wi-Fi's high quality end-user experience from data connectivity to voice, music, and video applications under a wide variety of environment and traffic conditions.WMM defines four access categories (voice, video, best effort, and background) that are used to prioritize traffic so that these applications have access to the necessary network resources. CellCore provides a basic set of wireless connection oriented services for cell phone radio technologies. This set of services includes the Radio Interface Layer (RIL), Short Message Service support (SMS), Wireless Application Protocol Support (WAP), Extended TAPI and TSP, Subscriber Identity vModule (SIM) card support. The SIM Toolkit is a set of command specifications which define how applications on a Subscriber Identity Module (SIM) card must interact with any Mobile Equipment (ME). ExTAPI, Assisted TAPI, and Telephony Service Provider (TSP) API. The Radio Interface Layer (RIL) handles the communication between the CellCore system software and the radio hardware. The Short Message Service (SMS) providers enable an SMS client determine the application that should receive an incoming SMS message. The Wireless Application Protocol (WAP) is the de-facto world standard for the presentation and delivery of wireless information and telephony services on mobile devices. It is an open specification that defines both a communications protocol and an application environment. It solves the transport and content problems of the constrained wireless environment, bringing Internet content and advanced data services to mobile devices. WAP is based on existing Internet standards, such as IP, HTTP, and Extensible Markup Language (XML). Additionally, WAP sits on top of existing bearer channel standards, for example, Code Division Multiple Access (CDMA), Global System for Mobile Communications (GSM), and General Packet Radio Services (GPRS).
6.22 The OS Build System and Platform Builder

In CE, the tool used to generate a new custom operating system kernel is called Platform Builder. Platform Builder is shown in Figure 6.17. In CE 6.0, it runs under Visual Studio 2005 with SP1. In Platform Builder, the designer selects
184
the various OS features and device drivers needed from the catalog items (on the left in Figure 6.17) using the mouse to select the items needed. Then the user selects Build from the top level menu to build a new OS kernel using the selected OS features. The new OS can be then run and debugged on an ARM emulator or can be quickly downloaded to a target device attached to the PC using network, USB, or serial connections.
Solution Platforms
Connectivity Status
Connectivity Device Name
Project Tree
Code Editor
Debug tool status indicators
Output Selection
Tabbed Output Windows
Figure 6.17 Platform Builder is the tool used to build a new OS kernel image.
6.23 Platform Builder Terminology

There are a large number of unique terms used in Platform Builder. Using Platform Builder and the various menus will be easier once you understand the following terminology: Catalog item : Any item that you can select from the Catalog Items View. Design template : A pre-defined selection of operating system (OS) components that Microsoft provides for a category of generic target devices. For most designs, a design template is just a quick initial starting point. When saved or modified, the design template becomes an initial OS design.
185
OS design : A selection of Catalog items that defines the characteristics of an OS. You can begin an OS design with or without a design template. Run-time image: Software to deploy on a target device, or the same software running on a target device. A run-time image contains the OS and its associated software. Board support package (BSP) : Software that is specific to a hardware board. This software typically includes the boot loader, OEM adaptation layer (OAL), and board-specific device drivers. Catalog: A container of individually selectable units of CE functionality. Component : The smallest unit of functionality that you can add to an OS design. Configuration : A selection of Catalog items and a selection of build options. Hardware platform : A hardware architecture for running a CE OS and associated software. Module: An EXE or a DLL that is a part of a CE OS. Subproject : A tracking mechanism for a collection of files that you can use to build and add functionality into a CE OS. OS Design Projects can contain multiple subprojects. target device, CE based device: An instance of a hardware architecture or an instance of a combined hardware and software architecture. Project: A container for all files related to an OS design.
6.24 Building a Run-time image

To build a run-time image, you must first create an operating system (OS) design that specifies the functionality that you want your run-time image to support. Several design templates for different device classes are provided as a quick starting point for a new OS design. You can begin an OS design by choosing a design template or you can begin an OS design without a design template. An OS design corresponds to a set of environment variables in the build environment for Platform Builder.
Figure 6.18 Steps in Developing a new OS Run-time image.
With each OS design, Platform Builder by default provides a configuration named Debug and a configuration named Release. You can select one configuration. A configuration specifies build options for the OS design. You can modify the build options for each configuration. For each OS design, only one configuration can be active at a time. The Debug option displays more
186
debug messages, but also requires around 40% more memory and additional time to boot since a lot of debug messages are displayed. After you build your OS design, you can then make a run-time image. A run-time image contains the OS and associated software to deploy to the target device. Next, the designer builds a new customized OS image for the device. In Platform Builder, when you choose to build a run-time image based on an operating system (OS) design, the build system seen in Figure 6.19 executes the following sequential phases: The Compile Phase The Sysgen Phase The Release Copy Phase The Make Run-Time Image Phase
Figure 6.19 The CE Build system.
The build system completes the following tasks during these phases: Generates header files Links modules Copies the resulting modules to a release directory Generates a run-time image
187
Target devices can include a variety of devices, including the ARM Device Emulator or a CEPC (a PC running CE) or actual system hardware using any of the processors supported. The new OS image can be rapidly downloaded to any of these target devices for additional debugging and testing. Novice users should use Platform Builders GUI interface to the build system. Expert users often directly invoke the build system from the command line to save time and minimize build times. Under the top-level build pulldown menu there is an option to open the build system in command line mode. Rebuild clears all files first, and then starts a new build.
6.25 Build System Configuration Files

The build system uses several types of configuration files to build the new OS image. These files are automatically setup, but you may have occasion to make changes to these files. Understanding the basics of the build system will also be helpful to understand and fix any errors in your OS builds. Source code configuration files give the Build tool (Build.exe) information about the following: The directories to traverse The C and C++ files to compile The type of binary file to build Based on this information, the Build tool builds the source code in a directory and specified subdirectories. Table 6.9 shows the source code configuration file types. Table 6.9 Source Code Configuration File Types. File type Description Dirs File Makefile File ModuleDefinition File Sources File Identifies additional subdirectories that contain more source code. Contains the variables needed to compile and link the source code. Contains the statements defining an executable or dynamic-link library.
Contains the macro variables needed to build the source code. It lists the include and library files needed to build the module. (one of the build files an application developer will often need to modify)
The Build tool traverses a directory tree, searching for dirs and then sources files. Dirs files specify the sources files that contain: Source code to be built Information on additional subdirectories that contain sources files When the Build tool locates a sources file in the current directory, it calls the Nmake tool (Nmake.exe), which does one of the following: Compiles the specified C or C++ sources file
188
Links an object module, according to the linking rules contained in the makefile file
The Make Binary Image tool ( Makeimg.exe) calls a number of applications and batch files, which use image configuration files to create a run-time image. Table 6.10 shows the run-time image configuration file types. Table 6.10 Run-time Image Configuration Files. Description Defines the modules and files to be included in the run-time image.
File type Binary Image Builder File (*.bib) Registry File (*.reg) File System File (.dat) Database File (.db) String File (.str)
Defines the registry keys and values for a run-time image created during a cold boot. Defines the RAM file system directories, files, and links for a runtime image created during a cold boot. Defines the databases to be included in the object store of a runtime image created during a cold boot. Defines locale-specific string replacements for text that is visible to a user in .reg, .dat, and .db files. Each line in the .str file must end with a <CR> to enable correct processing.
Specific run-time image configuration files apply to your hardware platform; others apply to the workspaces that contain CE-based modules and components. Regardless of scope, you can use IF and ENDIF conditional blocks and environment variables in any run-time image configuration file to modify the resulting run-time image. Table 6.11 shows the scope of the run-time image configuration files. Table 6.11 Scope of Run-time Image Configuration Files. File name Scope Common.bib, Common.reg, These files apply to the Common project, which Common.dat, Common.db, contains the core CE-based modules and Common.str components. IE.bib, IE.reg, IE.dat, IE.db, These files apply to the IE project, which contains IE.str the components that support the Microsoft Internet Explorer modules. Wceappsfe.bib, Wceappsfe.reg, These files apply to the Wceapps project, which Wceappsfe.dat, Wceappsfe.db, contains the components that support WordPad Wceappsfe.str word processing software and Inbox electronic messaging software. Wceshellfe.bib, Wceshellfe.reg, These files apply to the Wceshellfe project, which Wceshellfe.dat, Wceshellfe.db, contains the components that support the CE-based Wceshellfe.str shell modules.
189
Msmq.bib, Msmq.reg, Msmq.data, Msmq.db, Msmq.str Platform.bib, Platform.reg, Platform.dat, Platform.db, Platform.str Project.bib, Project.reg, Project.dat, Project.db, Project.str Config.bib
These files apply to the MSMQ project, which contains Message Queuing Server modules. These files apply to the hardware platform.
These files apply to the workspace that contains your CE-based run-time image. This file applies to your run-time image. It contains MEMORY and CONFIG sections for the run-time image.
A binary image builder (. bib) file defines which modules and files are included in a run-time image. Makeimg.exe uses .bib files to determine how to load modules and files into the memory of a target device. The Platform.bib file defines The hardware modules and files, such as driver files, for the target device The modules and file entries for the run-time image, such as .exe files and waveform audio ( .wav) files The Config.bib file contains the MEMORY and CONFIG sections for the runtime image. The MEMORY section of Config.bib defines the memory table for the run-time image by specifying the name, address, size, and type of the MEMORY regions within the run-time image. When updating either Platform.bib or Project.bib to include a file, specify the following items: The source and run-time image file name The region of the MEMORY section defined as RAMIMAGE type. The file attributes in the run-time image Use the Address and Size parameters in the memory table to define the section of memory devoted to RAM as well as ROM. The Address parameter specifies the address where the RAM section starts. Together, the Address and the Size parameters indicate the address where the RAM section ends. The MODULES section of the *.bib files specifies which CE-based modules are included in the run-time image, and how they are loaded into the memory table as established in the MEMORY section of the Config.bib file. It is modified to add *.dll files and subprojects to the OS image. This section can contain up to 2,000 modules, which consist of a two -part combination of source code and data. The following example shows the columnar format used by a MODULES section entry in a *.bib file:
Name MYDLL.DLL Path %_WINCEROOT%\RELEASE\MYDLL.DLL Memory block Section override Type NK SHC
190
The name parameter specifies the name of the MODULES section entry as it appears in the memory table. Usually, the Name entry is the same as the name of the file referenced by Path. The path parameter specifies the full path to the file, as specified in the MODULES section that Romimage.exe incorporates into the run-time image. Usually, the Path file name is the same as the Name MODULES section entry. The Memory block parameter specifies the RAMIMAGE section of the memory region into which Romimage.exe loads the object module. Romimage.exe places the object modules in the specified memory location in the order in which they appear in the MEMORY section. This memory location corresponds to the MEMORY section defined in the Config.bib file. There is only one RAMIMAGE per run-time image. The name used to specify the MEMORY section must be the same as the name specified in the Config.bib file. The section override parameter specifies what type of section entry Romimage.exe treats the entry as, and can be set to MODLES or FILES. When this is added to an entry, Romimage.exe ignores the section that the entry resides in, and treats the entry as a member of the specified section. This is optional. The type parameter specifies the file type and can be a combination of the following: S - to define it as a system file. H - to define it as a hidden file. R - to compress resources. Applies to the MODULES section only. C - to compress everything if applied to a module. D - to prevent a debugger from running. N - to mark a module as nontrusted. Applies to the MODULES section only. K - to signal that Romimage.exe must fix-up the module to a kernel address.
191

The on-line help system provided in Visual Studio for CE 6.0 contains descriptions of all API calls and has additional details on the OS and its features. Use the Windows Embedded CE 6.0 filter setting in the help system. To review any basic OS concepts such as virtual memory, processes, threads, scheduling, and synchronization methods any introductory OS textbook is useful. One suggestion is Operating System Concepts 6 th Edition, by Shilbershatz and Gavin. The textbook, Building Powerful Platforms with Windows CE by James Y. Wilson and Aspi Havewala although it was written for an earlier version of CE it is still an excellent source of information for additional details on the CE build system. The textbook, Programming Microsoft Windows CE.Net, Third Edition by Douglas Boling published by Microsoft Press contains additional details on developing Windows Embedded CE application programs using CE APIs. Inside Microsoft Windows CE , by John Murray is based on interviews with several members of the initial CE design team. It is an excellent source of information on the design goals and early history of the development of CE. Several Community sites and News Groups discuss Windows Embedded CE topics and issues: Windows Embedded Community: http://msdn.microsoft.com/embedded/community/ Platform Builder News Group: http://msdn.microsoft.com/newsgroups /default.aspx?dg=microsoft. public.windowsce.platbuilder Windows Embedded News Group: http://msdn.microsoft.com/embedded/community/community/newsgrp/ default.aspx Mike Halls Embedded WEblog: http://blogs.msdn.com/mikehall
CHAPTER 7
Building a customized CE 6.0 R2 Kernel
Using Platform Builder embedded systems designers can build a customized CE OS for their device that includes only the features needed. Platform Builder runs in the familiar Visual Studio IDE. A CE target device or emulator can download the new OS and then be used to debug the new OS and the devices applications.
194
7 Building a customized CE Kernel

Each new embedded device needs an Operating System that has been tailored for the devices unique requirements. By including only the drivers and services needed in a device, the kernel size is minimized. This results in a smaller memory requirement. Even if the savings are not large enough to enable the designer to switch to smaller less expensive memory devices to build the device, any memory saved still results in more memory available for application programs and storage. In some cases, memory savings can be substantial. The smallest Windows Embedded CE kernel runs around 400K bytes and the largest kernel with C# s .NET Compact Framework, a full range of I/O devices, and full debugging support runs over 40M. That is over two orders of magnitude difference in size. Each new device is also likely to need a few device drivers that have been developed and/or customized for that particular device. OS licensing fees can also be substantially less for systems that do not require some important features and services (i.e., a headless device with no display and no OS bundled applications). The process of building a new operating system kernel is sometimes called a sysgen. Sysgen is short for system generation. Keep in mind that this process is a lot more involved than just compiling and linking a simple applic ation program. It needs to copy, check, compile, and link together hundreds, if not thousands, of different modules and files, so be patient when the process takes a few minutes. In Windows Embedded CE, a special graphical OS development tool called Platform Builder that runs in Visual Studio is used to generate a new customized kernel.
7.1 Videos & Virtual Labs: An introduction to the CE tools via the web
Several short introductory videos on using CE are available on the web at http://msdn.microsoft.com/embedded. They can be played on the desktop in media player. A series on introductory virtual lab exercises for CEs Platform Builder using the ARM Device Emulator are available on the Internet (http://msdn.microsoft.com/en-us/virtuallabs/default.aspx in the Windows Embedded link). The CE tools run on a remote server using Virtual PC and the displays image is exported back to your web browser. This means that no software needs to be installed on your computer, no target hardware is needed, and all you need is a network connection and Internet explorer. These labs are an excellent way to initially gain hands on experience with the CE development process and tools on any PC without spending a couple hours installing all of the software required. These labs are also a useful initial option for anyone that does not have their own target device. The Virtual Labs require only that you install a small active X control to import the images into your browser. A free Microsoft passport account is required. Before you start each lab, it is helpful to print out or save the laboratory manual
195
*.pdf file. You will be reading instructions from the manual and typing commands into the tools. A small *.pdf link can be found in the upper right of each lab on the final screen before starting each lab. Each lab session sets up a new virtual PC disk image on the server with all of the tools installed and 90 minutes of continuous lab time is allowed to complete each lab before the server times out, so be sure you have a block of time available before starting. You will not be able to save any files or transfer files back from the server to your PC. Several virtual labs are available, but three of the virtual labs are especially relevant for anyone new to CE. The first lab builds an OS and runs it on an emulator and the last two go through all of the steps for C/C++ and C# application development and introduce the debug tools. Detailed descriptions of these three virtual labs are listed below: Windows Embedded CE 6.0 Platform Builder Tools This virtual lab steps through the process to create, customize, build and debug a Windows CE OS Run-time Image and introduces Platform Builder s features. The new run-time image is then run on the ARM device emulator provided with CE. Writing MFC/Native Applications for Windows Embedded CE 6.0 This virtual lab steps through the process of creating a CE 6.0 operating system image that supports Win32 and MFC (Microsoft Foundation Classes) application development, this includes building a custom SDK (Software Development Kit) to support application development against your custom operating system image and will also use Visual Studio 2005 to write and deploy a simple MFC application to an operating system image running on the ARM emulator. Writing C# Managed Applications for Windows Embedded CE 6.0 This virtual lab steps through the process of creating a CE 6.0 operating system image that supports .NET Compact Framework application development and uses Visual Studio 2005 to write and deploy a simple .NET Compact Framework application to an operating system image running on the ARM emulator. Virtual labs are a quick and easy way to initially learn the tool flow for CE on any PC. Users without the eBox target hardware can run and debug many of the examples that follow on the ARM emulator using the instructions provided in the Virtual labs to compile code for an ARM processor and connect to the ARM emulator to download new OS Design and code. Any examples that require external hardware not supported by the emulator such as the Phidgets USB I/O devices will not function correctly. Next, we will build a new OS with Platform Builder and start running CE on a real hardware device, the eBox 4300.
196
7.2 Software Installation Instructions

Before starting the tutorials, several software packages need to be installed on the development system PC. The development system needs Windows XP or Vista with 512K to 4G RAM and at least 18 GB of free disk space available before installing all of the software. This will leave enough disk space to support several new OS build projects. The following items are needed and they should be installed in this order: Visual Studio 2005 (NOTE: VS 2008 does not currently support CE 6.0) Visual Studio 2005 Service Pack 1 (SP1) must be installed if not already present in the version initially installed. SP1 is required to support code deployment of standalone C# and C++ projects from Visual Studio. You can download VS 2005 SP1 directly from Microsoft at www.microsoft.com/downloads. If you are using Windows Vista, the Visual Studio 2005 SP1 update for Vista is also needed. Windows Embedded CE 6.0 R2 (add-on for VS 2005) Install both ARM and X86 processor support and use the default install locations, if at all possible. If disk space is tight, you can install only X86 processor support, but you will not be able to use the ARMbased emulator. ICOP eBox4300 60DS BSP (Board Support Package)16 for CE 6.0 Available at www.embeddedpc.net and click the download link on that page (just unzip and run program to install). If a newer version is available, it can be used, but the BSP names shown in the tutorials will appear somewhat different. ICOP eBox4300 WinCE600 SDK (Software Development Kit) for CE 6.0. Available at www.embeddedpc.net and click the download link on that page (just unzip and run program to install). If a newer version is available, it can be used, but the SDK names shown in the tutorials will appear somewhat different. ICOP VS2005 CoreCon x86 WINCE600 catalog add-on for CE 6.0 Available at www.embeddedpc.net/academic and click the download link on that page (unzip and run program to install). If you have the optional internal wireless networking card and want to use it in your eBox, download and install the latest version of the CE 6.0 VIA VT6655 wireless driver from www.embeddedpc.net . (if the internal wireless card is installed you will have a gold antenna connector showing on the back panel of the eBox). The driver package installs automatically. This driver from VIA is currently working on the eBox for non-debug (i.e., release) OS builds only.
16
The Rev C version BSP (60CS) that may still be found in other locations can also be used, but it has the COM ports reversed.
197
Install the new Windows CE 6.0 Service Pack 1 (SP1) (if SP1 was not initially installed) at www.microsoft.com/downloads. CE 6.0 with SP1 is required for Windows Vista. All of the books examples were developed using Windows Vista and were run earlier on Windows XP. If you are using C# for application development, install .NET Compact Framework 2.0 SP2 available at www.microsoft.com/downloads. This fixes several debug and COM port issues. The current CE 6.0 installation software only installs .NET Compact Framework 2.0. Dont confuse this with the .NET Framework package used on desktop PCs. (NOTE: To install the new SPx versions you may find that you have to search to find, and then manually browse to the original netcfsetupv2.msi file location, if a cant find file dialog box appears. This file is needed so that it can uninstall the older version first. The default location for the original 2.0 file is C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0 \CompactFramework. All of the versions 2.0, 2.0 SP1 and 2.0 SP2 have the same *.msi install file name.). As an alternative you can use the new .NET Compact Framework 3.5 instead. The update to .NET Compact Framework 3.5 is included in the CE monthly update for January 2008. If you will be using a USB Camera, install the CE camera driver at www.microsoft.com/downloads (search for CE 6.0 USB Camera Driver). More information on the camera driver options will be presented later including code examples. Update Windows Embedded CE 6.0 to R2 (if R2 was not initially installed earlier) and install all of the monthly CE updates. Start Visual Studio 2005 and use Tools Platform Builder for CE 6.0 CE Update Check and then click Verify Updates to confirm that all updates have been installed. A green check box will appear as seen in Figure 7.1, if all of the relevant CE monthly updates for all of the installed processor types have been applied.
NOTE: Microsofts automatic web update tool does not check for and include the CE monthly updates. Automatic updates without any user initiated action are probably not a good idea anyway, if you are in the middle of developing and testing a large OS and software development project for a CE target device! Installing the complete set of software takes several hours, so if identical laboratory machines are being setup, using a fast disk image copy software utility such as Ghost will save hours of setup and maintenance repair time for laboratory PCs. Even if a network server is not available for this purpose, a low-cost USB 2.0 external hard drive can be used and moved to each machine to install the disk image.
198
Figure 7.1 Checking for all of the CE monthly updates. A green checkoff is needed.
If you do not see the green check box as shown in Figure 7.1 and see a yellow caution triangle symbol instead, the list can be expanded to show the missing updates. The CE monthly updates can be found at http://www.microsoft.com/windows/embedded/downloads/default.mspx and click on the CE Update link found there. There is a cumulative annual update that can be used to save time for the previous year(s), but the current year will require all of the missing monthly updates for each processor type installed. Install the oldest missing updates first. Watch for a pop up confirmation window near the very end of each install (it displays a final list of source files changed). You will need to find and click this window to finish each install. On some systems, it tends to hide behind other windows and is easy to miss. Check at www.microsoft.com/downloads for any more recent updates to Visual Studio 2005, Windows Embedded CE 6.0, and .NET Compact Framework 2.0 or 3.5.
Each additional new OS build project can use almost 2GB of disk space, so you may need to clean or delete older OS build projects at some point to free up disk space, if your disk space is limited. Cleaned OS build projects (i.e., Build Clean Solution ) are relatively small (just a few MB) and they can always be rebuilt. This is also a handy way to backup or move a build project to another PC using a Flash drive. The initial installation of Visual Studio 2005
199
and the required VS 2005 SP1 requires a fair amount of time, so only start these install processes when you have an adequate block of time to complete it. After installing all of the software listed or verifying that it is already installed on your development system, you will be ready to start the tutorials. OTHER IMPORTANT INSTALL AND SETUP NOTES Be sure to disable any on-access file virus checking software . Disable onaccess scanning, or at a minimum exclude on-access checking of the main CE file directory. The default main CE directory is C:\WINCE600 and on-access file virus scanning of this directory is the main issue. Each OS build copies, creates, and opens several thousand files and checking every one of them for a virus makes the long OS build process run very slow indeed. If you have a firewall running on your development system PC, it may need to be set, adjusted or disabled to allow the eBox to attach and communicate with your desktop PC over the network. The network connection is used to download new code and support remote debug operations. If you have the firewall turned on in Windows, firewall exceptions will need to be added for the following programs: Platform Builder CE Service Host Platform Builder Platman Service Manager Remote File Viewer Remote Heap Walker Remote Process Viewer Remote Registry Editor Remote Zoom In Windows Embedded CE 6.0 Test Kit
These firewall settings can be changed in the Security Center Firewall settings exceptions tab in Windows Vista. If you need to use the CE remote display application, add a firewall exception for the Platform Builder CE Remote Display Host, if not already enable d. This option may not appear in the firewalls list of programs until CERHOST is run the first time. Assuming a default install setup for CE, CERHOST can be found on the development system PC in the directory, C:\WINCE600\PUBLIC\COMMON\OAK\BIN\I386. Your development PC and the eBox network connection must be on the same subnet to allow remote booting and debugging on the eBox. The eBox will need to have DHCP enabled on the network or have a static IP address. More details on the network setup options are provided later. An account with administrator privileges is needed both to install and run the CE development tools.
200
7.3 Tutorial I: Building a new OS kernel using the eBox BSP

In this tutorial, we will describe all of the steps in detail needed to develop a full featured CE kernel that runs on the eBox 4300 computer. If you are using the older eBox 2300, the tutorials found in Chapter 7 of the first edition of this text will be more relevant 17. The large kernel we will develop will include the OS features and drivers needed to run all of the demo programs in this textbook. For specific applications that do not use all of these features, the OS options not used could be removed and the kernel size can be reduced. The tutorials are for Windows Vista. Windows XP can also be used but the appearance of the windows screenshots will be slightly different. 7.3.1 Start the Visual Studio 2005 IDE The CE development tools run as a plug-in to Visual Studio. To start the process, run Microsoft Visual Studio 2005. When Visual Studio starts, you should see a screen similar to Figure 7.2.
Figure 7.2 The Visual Studio 2005 IDE

17
These files are available on the text s CD -ROM, or search for the author at: http://www.msdnaacr.net/curriculum/facetmain.aspx
201
Depending on the default development environment you selected during the install process, you may see a slightly different information screen. For CE, the VS 2005 IDE provides support for several different project types, including Console Applications, Windows Applications, and OS kernel builds. 7.3.2 Creating a new OS Design Project Next start a new OS kernel build project by selecting File New Project. In the left column of the New Project window that pops up, click to highlight the Platform Builder for CE 6.0 option. The screen image shown in Figure 7.3 should appear.
Figure 7.3 Creating a new OS Design Project.
On the right side of the New Project window, click OSDesign to highlight it. Enter MyOS as the name of your new project. Confirm that Create directory for solution is checked. Click OK to continue.
202
After several seconds, the Windows Embedded CE 6.0 Design Wizard starts running as shown in Figure 7.4. It will ask you several questions and then create a new OS design project along with the required files and directories. Click Next to continue.
Figure 7.4 The Windows Embedded CE 6.0 Design Wizard.
203
7.3.3 Selecting the BSP for the eBox Next the wizard prompts you to select a board support package (BSP) for your target hardware as shown in Figure 7.5. Recall that a BSP contains the basic drivers and other OS features need for a specific hardware platform. For the eBox 4300, select ICOP_eBox4300_60DS: X86. Confirm your selection and then click Next. NOTE: If this BSP does not display as one of the options, the BSP folder will need to copied into the WINCE600/PLATFORMS directory. The eBox 4300 BSP is available free from ICOP and is also available on the CDROM provided with the eBox. Be sure to use the RevD BSP (not Rev C).
Figure 7.5 Selecting the eBox 4300 BSP in the Design Wizard.
204
7.3.4 Selecting an initial Design Template Next the design wizard prompts you to select an initial design template. A design template sets up the OS options to match a generic device type. Each design template automatically selects the features and drivers typically needed on that type of design. You will still need to add or delete a few features from each generic device type, but selecting the closest device type speeds up the OS configuration process later on. Select Industrial Device as the Design Template. An Industrial Device contains a full range of features that are a good match with the eBoxs hardware functionality. Click Next to continue.
Figure 7.6 Selecting a Design Template in the Design Wizard.
205
7.3.5 Selecting the Design Template Variant Next the design wizard prompts you to select a design template variant. The options shown vary based on the design template selected. Figure 7.7 shows the options that are displayed for the Industrial Device design template. Select the Internet Appliance variant. An Internet Appliance automatically includes networking support. Click Next to continue.
Figure 7.7 Selecting a Design Template Variant in the Design Wizard.
206
7.3.6 Selecting Applications and Media Options The design wizard then prompts you to select several applications and media options as seen in Figure 7.8. Since we are building a large full-feature kernel, we will need most of the options on this screen. Verify and/or Select the following options: .NET Compact Framework 2.0 or 3.5 (needed for C# code) Internet Explorer 6.0 Windows Media Audio/MP3 Windows Media Player Application Windows Media Player OCX Windows Media Video/MPEG-4 Video WordPad XML MIME Viewer
Click Next to continue.
Figure 7.8 Selecting Applications and Media options in the Design Wizard.
207
7.3.7 Selecting Networking and Communications Options The design wizard then prompts you to select several networking and communications options as seen in Figure 7.9. The default options are OK here, unless you need support for 802.11 Wireless in your device. For 802.11, you would need to add Wireless Local Area Network (802.11) under Local Area Network. Click Next to continue. The current eBox wireless driver does not work in an OS debug build like this one, so leave it out for now and only add it in a release build.
Figure 7.9 Selecting Networking and Communications options in the Design Wizard.
In the Project Wizard complete notification window that appears, just click Finish and the wizard in a few seconds the wizard will have created the initial project directory and files.
208
7.3.8 Acknowledge Security Notifications As the OS Design Wizard finishes setting up the new project files, it will issue security warnings for any components selected that can pose a security risk. Many common networking features can pose a potential security risk to the OS. Click Acknowledge to continue. If you click Cancel, it will remove the feature.
Figure 7.10 A Security Warning is issued based on a selected OS option .
209
7.3.9 Customizing the OS Design At this point an initial OS Design project has been setup. The project files reside under the main OS Design directory in a folder under your project name. For this design they can be found in the directory, ..\WINCE600\OSDesign \MyOS. The top-level solution allows an OS Design project to be combined with several C/C++ & C# applications (these are called subprojects and C# applications will appear as projects). The next step is to select any individual components still needed for your OS design. Make sure the catalog items view is selected as seen in Figure 7.11 in the left column. Note that the tabs at the bottom of this window select different views of the project.
Figure 7.11 The Catalog Items View (left column) is used to select individual items for the OS.
There are still a number of useful items you will want to add to your new OS kernel. To add a new item you just need to locate it in the Catalog Items View Window and click on it. Anytime you cannot find the Catalog Items View window, it can be reopened using View Other Windows Catalog Items View. When an item is added a green check box appears. Other items that a newly selected item may require are added automatically and these are indicated with a green square. Items that cannot be added are indicated with a red exclamation mark. For example, a few items are only available on a particular processor type.
210
In many cases, you will need to expand the view to find items by clicking on a + box. Note that there is also a very useful search feature at the top of the catalog items view window. By right clicking on each item, you can display the items properties or view a list of the other items it depends on. Click on the + box to expand the view as needed or use the search feature to find each item to select. Find each of the following catalog items and select them to be added to the OS (green check mark) using the catalog view window: Under Third Party BSP ICOP eBox4300_60DS: x86 Device Drivers confirm the following three items that are required to support the video display and audio on the eBox: o VIA CN/CX Display Driver o VIA HD Audio Driver o VIA UAM3059 Audio Driver Under Third Party select the ConMan_x86 Files Component . This adds the Corecon files needed to setup communications to deploy C# code to the eBox and debug applications. If it is not there, it has not been installed (if it is missing, see Section 7.2 for details). Under Core OS CEBASE add the following two items: o Applications-End User CAB File Installer/Uninstaller. This item is needed to support C# application development using VS 2005. o Applications and Services Development .NET Compact Framework 2.0, confirm/ add .NET Compact Framework 2.0. It is needed for C# applications. (.NET Compact Framework 3.5 can be used instead, if it has been installed.) Under Core OS CEBASE File Systems and Data Store add the following two items that are used to support a hive-based registry. A hive-based registry will save registry settings when a device powers down. (i.e., the network setup) o File System - InternalROM-only File System o Registry Storage Hive-based Registry
Under Core OS CEBASE Core OS Services USB Host Support USB Storage Class Driver. This item is needed to support external USB Flash drives plugged into the eBox. Under Device Drivers Storage Devices notice that the ATAPI PCI Support driver is pre-selected. This item is required to support the use of the internal Flash drive and a CF storage card plugged into the slot on the front of the eBox. CF cards will need to be formatted for FAT16 (not FAT32). Plug in a CF card before booting the OS and do not remove them while running the OS (i.e., eBox CF cards are not hot pluggable). Leave this item out for this debug build to avoid errors, but for to use the optional internal wireless card in a later release build, select the
211
VNT VNWLC6 Wireless LAN (VIA) driver is found under Third Party Device Drivers. If it is not there, it has not been installed (see Section 7.2 for details). If you installed the CE 6.0 USB Camera Driver and need to add it, it is listed under Third Party Device Drivers. If it is not there, it has not been installed (see Section 7.2 for details).
7.3.10 Configuration Manager and the Debug & Release Build Start the Configuration Manager using Build Configuration Manager. The Configuration Manger Window should appear as in Figure 7.12. Make sure that ICOP_eBox4300_60DS_x86 Debug is selected as the active configuration. Two types of OS Builds are supported for each project. The Debug Build includes many debug and status messages that are useful when first bringing up the OS on a new device. The option without debug messages is called the Release Build. A Debug Build requires around 40% more memory and boots significantly slower since it displays so many messages, but the messages can be extremely useful when any problems are encountered. In the final deployed system, the Release Build would be used. You can switch to a Release Build by selecting the Release configuration in the configuration manager. The final OS Build step must be repeated for each configuration, if you need both. For a release build, some of the other debug options would likely not be included. Close the Configuration Manager window.
Figure 7.12 The Configuration Manager can be used to select Debug or Release OS Builds.
212
7.3.11 Setting Project Build Options Before Building the OS, there are still several build options that need to be selected. In the left column near the bottom, select the Solution Explorer tab to display the solution view of the project. Select MyOS, right click and select Properties. When the property page window pops up, expand Configuration Properties and select Build Options. In the Property Page window that appears as seen in Figure 7.13 select the following build options: Enable eboot space in memory (IMGEBOOT=1) This option adds support for Ethernet debugging by bundling the Ethernet boot loader in the image. Enable kernel debugger (no IMGNODEBUGGER=1). Select before building the run-time image to allow the debugger to connect and pass debugging information from the target device back to the host device. Enable KITL (no IMGNOKITL=1) KITL, short for Kernel Independent Transport Layer, provides a debug/download link between the target Windows CE device and the development station. KITL needs to be included with the image in order to use the remote tools within VS2005 and Platform Builder. NOTE: Whenever the target system does not remain attached to the PC development system, be sure to leave KITL out. The target system will lock up forever trying to use KITL to talk to the missing PC.
Do not enable Run-time Image Can be Larger than 32 MB, this only uses 64M of RAM, not all 512M. This will be set later when the IMGRAM512 environment variable is set to 1. Do not click OK yet! There are still some additional operations to perform in this window.
Figure 7.13 The Property Pages Window is used to set Build Options and Environment Variables.
213
7.3.12 Setting OS Environment Variables The Build system Environment Variables are used to include & exclude various items from the image and to setup memory configurations. Next select Environment instead of Build Options in the Property Page window from the previous step. There are several critical environment variables that now need to be added as seen in Figure 7.14. Click on the New button, enter IMGRAM512 for Variable name, and enter 1 for Variables value and click OK. By setting the IMGRAM512 variable, the resulting image will enable all 512M of memory, the total amount of RAM that is provided in the eBox 4300. Out of memory errors and a host of other strange problems could appear, if this setting is not correct. Follow the steps just described above and add three more environment variables PRJ_ENABLE_FSREGHIVE, PRJ_BOOTDEVICE_ATAPI, and PRJ_ENABLE_FSMOUNTASROOT all set to 1. Take a minute to double check carefully for any typos in the variable names. Any minor error here could keep the OS from booting and take an extra twenty minutes later on to go back and fix!
Click Apply and then OK to complete the configuration.
Figure 7.14 Adding an Environment Variable using the Property Pages Window.
214
Another example of an environment variable you might have occasion to add is IMGENFORA=1 . This includes the cell phone modem driver for the Enfora SA-GL GSM/GPRS Stand Alone Modem18. Many of the environment variables are setup automatically to default values by your initial design template selections and manual catalog item selections. Whenever initially changing from a debug build to a release build, you will need to repeat these last two steps to enter the build options and environment variables. Each type of OS build (debug or release) maintains its own unique set of environment variables and build options. Now that all of the build options and settings have been selected, a new OS image can be built. From the top-level menu select Build Build Solution . Platform Builder will now build a new OS image along with any subprojects it may include (i.e., a solution). The process needs to check, compile, and link thousands of files. Dont forget that an active virus checker doing on access scans will really make it run slow. At the bottom of the VS 2005 window, output messages will appear from the Build system. The very bottom of the window displays the following small animated bitmap icon showing that the build process is still running: It is probably a good idea to not try to do anything else in VS 2005 or the OS directories and perhaps even on the PC during a long build. It is very easy to lock a file or resource by doing something else and this can produce build errors. If this happens, you need to do a ReBuild. ReBuild cleans out the files first from the last Build and starts over on a new Build. Even not stopping the Debugger first, before starting a new Build will cause Build errors since it locks some symbol files. It will take ten to twenty minutes for the complete build operation. By default, the build process will use all available processor cores. To anyone that is used to compiling fairly short application programs, the build process seems very slow, but keep in mind that in the OS there are almost 4 million lines of code distributed in around twenty thousand files! When the Build process completes, you should see the final Build succeeded with no errors message in the Output window area at the bottom of the VS 2005 window as seen in Figure 7.15.
Described in more detail in Mike Halls articles, Using CellCore with Windows Embedded CE 6.0 and CE 6.0 - Sending an SMS Message (http://blogs.msdn.com/mikehall/)
18
215
Figure 7.15 The OS Build has succeeded with no errors.
When the build process is completed, the resulting files are generated and placed in the following build directories (assuming the default install locations were used): For a Debug image:
C:\WINCE600\OSDesigns\MyOS\MyOS\RelDir\ICOP_eBox4300_60DS_x86_Debug
For a Release image:
C:\WINCE600\OSDesigns\MyOS\MyOS\RelDir\ICOP_eBox4300_60DS_x86_Release
After a successful build, there will be a large NK.BIN file in the directory listed above. This is your new Windows Embedded CE 6.0 OS image. Congratulations, you just finished building your first OS run-time image for the eBox 4300. Next, we will see if it loads and runs correctly on the eBox.
216
7.4 Tutorial II: Downloading a new OS kernel to the eBox 4300

If you have not done so already, connect the power supply, display, keyboard, and mouse to the eBox. Any PC keyboard, mouse, speakers, and display should work with the eBox. A Y cable is provided to connect the keyboard and mouse. Pay attention to the small keyboard and mouse icon printed on the Y cable, so that you plug each one into the correct connector. Switch on the eBox using the power switch on the back (below power cable) and then hit the switch on the front panel. The green LED should light up to the right of the front panel switch. Verify that it starts up, displays BIOS messages, starts MS DOS, and displays the boot startup menu options. Power off the eBox using the front panel pushbutton. Whenever you need to remove the power cable from the eBox, retract the black slider on the power cable first , to release the connector from the eBox. If you do not have an extra display and keyboard for the eBox or are setting up a headless device, the CE Remote Display Application can export the display back to a window on the development system PC. A full set of instructions can be found in Appendix B. 7.4.1 Network Setup Options for the eBox For fast downloading, the eBox is typically downloaded using a network connection. It can be downloaded using a static IP address or with DHCP (server assigned IP address). A network crossover cable is provided with the eBox that can directly connect to network connection on the back of the development PC. This is assuming you connect directly to the eBox using a static network IP address on both the eBox and the development system PC. If the PC is currently setup for DHCP, you will need to assign it a static IP address for the direct network crossover cable connection or it will lockup once the normal cable is unplugged. This happens in a few seconds when it loses its connection to the DHCP server. The eBox can also connect through a network hub using either DHCP or a static IP address, but in most cases a hub requires a normal cable (no crossover cable). Using a hub setup has advantages, since any network applications running on the eBox such as a browser can still connect to the Internet. In any case, the eBox and the development PC need to be on the same subnet (only last three digits of IP address can be different) to support the BOOTME network request and to deploy application code. Duplicate IP addresses cause big problems on networks and will lockup computers, so be sure you do not select any IP addresses that are already in use. You may need to contact your network administrator to assign a static IP to the eBox, if you attach it to a hub and not directly to the development system PC. If you use DHCP to connect to the eBox, some secure DHCP servers require that each MAC addresses be enabled before they will respond to a new computer. If this is the case, you will need to obtain the MAC address for the
217
eBox and contact your network administrator to request that DHCP be enabled for the new device. You can run several programs on the eBox to determine the MAC address. Here is one way to get the MAC address. Turn on the eBox. Boot the local OS kernel (select boot option 1), wait for the OS to boot, Select Start Run, type CMD, select OK, and then type ipconfig /all on the console command window and the MAC address should be displayed. It is also possible to setup the eBox network connection by using a second network card in the development system PC. In either case, static IP or DHCP setup, be sure to disable any firewall program or set it up to allow any access from the eBox. An active firewall can prevent the eBox from communicating with the development system PC. Debug and status messages are sent out over the network connection. In most cases, these debug messages are sufficient to diagnose problems. The serial null modem cable provided with the eBox can be used to display the additional debug messages that can be sent out over the eBoxs COM1: serial port. These can be very handy when debugging a device with no networking. On the eBox 4300, the serial debug messages are turned off by default, but they can be turned back on with the LOADCEPC /C:1 command option in the eBoxs Autoexec.bat file. To view the debug messages output on COM1:, attach the null modem serial cable to COM1: on the eBox and any available COM port on the development system PC. Run Hyperterminal or another terminal emulation program on the development system to display the additional debug messages. Setup the terminal emulation program for whichever COM port you plugged the cable into on the development system PC. Use settings of 38400 Baud, 8 data bits, no parity, no handshaking, and 1 stop bit. Since COM1: is now sending out debug messages, it cannot be used by applications programs. 7.4.2 Setting the Target Device Connectivity Options Once the various IP/DHCP network connection issues have been resolved, the Target Device Connectivity options need to be setup in Visual Studio 2005 so that the new OS image can be downloaded to the target device. Select Target Connectivity Options and the Target Device Connectivity Options window should appear as seen in Figure 7.16.
218
Figure 7.16 Setting up the target device connectivity options.
Turn on the eBox-4300. The LED should turn on and it will boot and run a DOS Autoexec.bat files and provide menu selections similar to the following:
1. 2. 3. 4. Load nk.bin OS image from local storage Load OS image from development station with DHCP service Load OS image from development station with Static IP 192.168.2.232 Clean Boot (no commands)
Option 1: The eBox-4300 will load NK.bin (CE 6.0 OS image) from its local Flash memory storage. A factory default OS image is there already. Option 2: The eBox-4300 will load eboot.bin which in turn will send a request to an available DHCP server to assign an IP address. Then, it sends a bootme request to the Platform-Builder development station to download the nk.bin OS image from the current OS project. Option 3: The eBox-4300 will load eboot.bin with a static IP address (192.168.2.232), and sends a bootme request to the Platform-Builder development station to download the nk.bin OS image. Option 4: Boots DOS and exits to a DOS prompt. Useful for modifying the default autoexec.bat and config.sys startup files using Edit.
If the development station and eBox-4300 are connected to a LAN with DHCP service, select option 2. If the eBox-4300 is connected directly to the development station using a cross-over Ethernet cable, select option 3. If you
219
need to use a different static IP address for the eBox, exit to DOS and edit the eBoxs Autoexec.bat file to set the static IP address. Return to the Target Device Connectivity Options window still running on the development system and click on one of the Ethernet settings buttons. The Ethernet Download Settings window should appear as seen in Figure 7.17. Each eBox has a unique device name CEPC XXXX. Where XXXX is a different number unique to each eBox. When an eBox sends a BOOTME that is detected by the development system PC, it appears in the Active target devices window. When you see it appear there select it and it should become the Target device boot name. Then click OK. If it does not appear, restart the eBox and select a boot option. If it still does not appear, double check IP addresses and any firewall settings. It needs to show up here before you will be able to download to it.
Figure 7.17 Detecting and Selecting the CEPCxxxxx target device to download.
If several eBoxes are all active on the same subnet, it is possible to connect to the wrong one since several could appear in the active target device window. If you are working in a lab environment with a large number of active eBoxes, you might want to label each eBox with its CEPC XXXX number to avoid any confusion in large lab areas. Once you see the eBoxs CEPCXXXX number and select it, click OK to exit. Then select Apply and Close.
220
7.4.3 Downloading the Image to the eBox 4300 At this point, you are ready to download your new OS image to the eBox. In the Visual Studio IDE select Target Attach Device. After a few seconds of windows popping around, the window shown in Figure 7.18 should appear. This window may quickly disappear behind the Visual Studio IDE and you may need to bring it back to the front by selecting the Download item on the Windows taskbar at the very bottom of your display. After a few seconds, the target device should start downloading and the green progress bar should start moving as seen in Figure 7.19. If nothing happens after several seconds, restart the eBox and select the appropriate boot option again. The BOOTME process times out quickly after around three minutes. If nothing happens again, double check the network cable connection and setup. On some systems, the Firewall security settings may need to be changed to allow the eBox to connect. If the device remains attached and hangs up, use Target Detach Device to reset everything on the PC development system side. There are also two handy small Target Attach Device and Target Detach Device clickable icons on the left side of the VS 2005 toolbar just to the right of the device pull down box.
Figure 7.18 Attaching the target device for downloading.
221
Figure 7.19 The target device is downloading the new OS image.
If you are using Windows Vista, and the target system consistently stops in the middle of a network download (green progress bar seen in Figure 7.19 starts and then stops moving before finishing completely), the EBOOT.BIN program on the eBoxs internal Flash memory may need to be updated to the newest version. You can copy the newer file over by booting CE using the local NK.bin file and then using a USB Flash drive. Check the file date to confirm this problem. The newest version has a file creation date of 9/7/2006 and a file size of 103KB. The new version of EBOOT.BIN can be found in C:/WINCE600/PLATFORM/CEPC/SRC/BOOTLOADER/EBOOT/BIN . After copying over the newer EBOOT.BIN code, reset the eBox and exit to DOS. Edit the DOS AUTOEXEC.BAT file and change the lines that say LOADCEPC /C:0 to LOADCEPC /C:4 . The /C:0 option is not supported on the new Vista version of EBOOT.BIN and without this last change, the eBox will no longer boot CE. After the device downloads the entire OS image, you should see debug messages appearing back in the Visual Studio 2005 IDE Output Window. Make sure that the Output window is setup to show output from Windows CE Debug. These messages can display for a few minutes as the OS boots completely and before the display initializes late in the boot process. Once CE completes booting on the eBox you should see an image on the eBox display similar to Figure 7.20. Occasionally, during the first initial boot operation a new OS debug build will stop at a breakpoint because of some inconsistent data that still persists in flash memory from the previous (i.e., different) version of the OS. This typically shows up initially as DEBUGCHK ..\btrees.c message in the output window.
222
An assembly language debug window may also pop up along with a window asking for the location of a symbol debug file. You can easily work through this first boot problem by closing or canceling the pop up windows and clicking Debug Start each time it stops during the initial boot. The OS will then boot successfully. If the eBox is shutdown properly after booting so that it writes new data out to Flash, it usually does not occur again on subsequent boot operations with the same build.
Figure 7.20 The target device display is seen running the new OS image.
Once the display appears, you can select items with the mouse and keyboard. Debug messages are very helpful but they can really slow things down a bit, so dont try to do things too fast or you may get ahead of the debug messages. If the mouse stops moving for a few seconds or if you dont see keys that you typed in for awhile it is often the case that debug messages from the last operation are still being displayed back on the development system PC.
223
7.5 Tutorial III: Creating, compiling, and debugging a C/C++ Subproject

Now that a working OS Design Project has been developed for the eBox, a hello world C/C++ subproject will be added. Switch back to the Solutions View in the left column of the Visual Studio IDE. Highlight the last entry labeled Subprojects. Right click and select Add New Subproject . In the window that appears, select WCE Console Application and enter MyHelloWorld in the subproject name box as shown in Figure 7.21 below.
Figure 7.21 Adding the C/C++ MyHelloWorld Subproject to the OS Design Project.
Click Next to continue. A new window similar to Figure 7.22 will appear. Select A typical Hello World application , then click Finish and all of the code will automatically be generated and placed in a new MyHelloWorld subproject folder. The new folder will appear in a few seconds back in the Solution Explorer window.
224
Figure 7.22 Select a typical Hello World C/C++ application and generate the code.
Disconnect the target device, if it is attached to enable builds. Next highlight the MyHelloWorld subproject entry back in the Solution View window in the left column of the Visual Studio 2005 IDE. Right click and select Build from the menu that pops up in response to the right click ( Important Note: Do not select Build from the top-level menu, it will rebuild everything including the OS and will take at least 10 minutes longer). The Build option selected by right clicking the subprojec t, compiles only the subprojects code and links it to the existing OS image in short order. Check the output display window to confirm that the build has succeeded. If you do have errors in the debug window, you can click on the error message to move to that line in the code.
225
Assuming everything is still connected and running, select Target Reset Device. The device should respond by downloading the new OS kernel with the subproject. If not, use Target Detach Device, turn the eBox off and then on, and then repeat all of the initial steps to select a boot option on the eBox and download the new OS run-time image to the device. Once the kernel runtime image has downloaded and booted, the display should appear again. At this point, our hello world application code is on the eBox and we can run it. The following code is generated for the hello world console application:
// MyHelloWorld.cpp : Defines the entry point for the console // application. #include "stdafx.h" int _tmain(int argc, TCHAR *argv[], TCHAR *envp[]) { _tprintf(_T("Hello World!\n")); return 0; }
This code can be opened for edits in Visual Studio by expanding the MyHelloWorld subproject and then expanding the Source Files entry. Doubling clicking on the MyHelloWorld.cpp entry will open the code in the Visual Studios edit window. _tprintf prints Unicode messages on the console window. The console window appears only when the first printf executes. The console window closes automatically whenever the program exits. This program exits right away, so we need to set a breakpoint right after the _tprintf statement. To set a breakpoint, left click on the shaded bar immediately to the left of the line after return statement with the }. A small breakpoint icon should appear on the shaded bar. If the icon does not appear you may still be debugging from the previous build tutorial, so use Debug Stop Debugging and try again .
226
Figure 7.23 Setting up a breakpoint in the Hello World C/C++ application.
To run the hello world program, select Target Run Programs. Scroll down it the windows that pops up and find the MyHelloWorld program. Highlight the MyHelloWorld.exe line and click Run. After a couple seconds, the console window should pop open on the eBox display and Hello World should eventually appear in small type at the top of the console window as seen in Figure 7.24.
227
Figure 7.24 The eBox console display while running the Hello World C/C++ application.
The breakpoint should be encountered at this point and you should see a display similar to Figure 7.25 in the Visual Studio 2005 IDE. Notice that the icon associated with the breakpoint has changed. This new icon indicates that the code has hit the breakpoint. Enabling kernel debugging slows everything down a bit. Once the kernel development has stabilized a bit, you may want to disable debugging and run release builds for application testing. Release builds will boot and run much faster. When you encounter difficult problems, you could always switch back to a debug build for further testing.
228
Figure 7.25 Stopping at the breakpoint in the Hello World C/C++ application.
After the program stops at the breakpoint, select Debug Start to continue after the breakpoint. Once the program exits, the console window should close on the eBox. Once you find problems to fix, dont forget to stop debugging with Debug Stop Debugging before starting any new Build. The debugger locks some symbol files while it is running that will cause Build errors. When you stop debugging, you will probably need to reset the eBox before downloading a new run-time image. You have now successfully added, compiled, debugged, and run a C/C++ application program that was added as a subproject to the OS design project.
229
7.6 Tutorial IV: Creating a MyOS Release Build

Now that the MyOS project developed in the earlier tutorials is working correctly and it runs applications, we will switch to a MyOS Release Build instead of the larger, slower Debug build. This will make booting and running applications go a lot faster and the kernel will be around 40% smaller without all of the OS debug messages. Start Visual Studio and open your MyOS project . Under the main menu Tools item find the leftmost pull down combo box and select ICOP_eBox4300_60DS Release as seen in Figure 7.26. This switches the MyOS project to a Release build. If the combo box is shaded out, you will need to first detach the eBox and stop debugging.
Figure 7.26 Switching the MyOS project to a Release build.
Next the Build Options need to be selected for a Release Build. In the left column near the bottom, select the Solution Explorer tab to display the solution view of the project. Select MyOS , right click and select Properties. When the property page window pops up, expand Configuration Properties and select Build Options. Setup the Build Options as seen in Figure 7.27. Enabling WINCESHIP eliminates even more debug messages. If you want to always leave the target system attached to the PC and use the debugger, select Enable KITL and the kernel debugger. Whenever the target system will not remain attached to the PC development system, be sure to leave KITL out, otherwise the target system will lock up trying to talk to the missing PC using KITL.
230
Figure 7.27 Setting the Build Options for a Release build.
You will now need to re-enter the environment variables for a Release build using the same procedure described earlier in the Debug build in Section 7.3.12 as seen in Figure 7.28.
Figure 7.28 Setting the environment variables for a Release build.
231
To build the release version, select Build Build MyOS. After several minutes, the Build should be successful with no errors as seen in Figure 7.29. Follow the steps described earlier to attach the eBox and download your new kernel image (Release version) to the eBox. It should be smaller and boot faster than the debug image. The main Windows CE window should appear on the eBox display once it boots. Keep Visual Studio running, but detach the eBox. VS and the MyOS project will be needed again after a few steps, if you intend to continue with the tutorials at this time.
Figure 7.29 A successful Release build for the MyOS project. Note the smaller size of the OS kernel in NK.BIN. A release build of the OS will also boot and run faster.
If you experience major errors or other problems in a Release build, you can always switch back to a Debug build temporarily to see the additional error messages in the output window. The additional debug messages slows down the OS response time and a Debug build may run too slow to be used with external hardware devices that have critical real-time response constraints.
232
7.7 Tutorial V: Generating a new SDK for use by application developers

After you create a custom OS design, you can develop a software development kit (SDK) based on that OS design for distribution to application developers. An SDK is a set of headers, libraries, connectivity files, run-time files, OS design extensions, and Help documentation that developers can use to write applications for a specific OS design. Application developers that use an SDK do not need to understand the details of generating a new OS kernel. The contents of an SDK allow developers to create and debug an application on the run-time image built from a pre-existing OS design. Platform Builder can be used to develop an SDK based on your custom OS design for installation on another development workstation. During the SDK development process, Platform Builder tracks the core OS modules that belong to an OS design, eliminating the need for you to describe the modules and components containing the technologies that the associated SDK should support. Instead, Platform Builder includes the headers and libraries associated with the modules and components in your OS design in your SDK. The SDK is used to determine which menus, files, and debugging applications to display to an application developer who is creating software targeted for your custom OS design. These tools also use connectivity components to determine how to transfer information from the development workstation to the target device through the transport layer. To help developers use your SDK, when you create an SDK, the SDK development tool automatically creates and includes an HTML Help file containing documentation showing which APIs are supported by your specific OS design. When the SDK is installed in Visual Studio, this documentation does not appear in the table of contents, but is installed on the developer's hard drive. Before you can build an SDK, you must create a new SDK for the OS design. To use CE 6.0 SDKs, make sure that you have already installed Microsoft Visual Studio 2005 SP 1 or greater. The following steps will build a new SDK: 1. Start VS and Open your MyOS Design Project. If you have not built a run-time image for your OS design or if you modified your OS design after configuring the SDK, you must build a new run-time image. 2. The SDK entry appears in the Solution Explorer view window right above Subprojects. If an SDK has not already been added to the OS Design Project, use Project Add New SDK to create an SDK in the OS design project. Fill out all information in the dialog boxes and make both the SDK and product name and MySDK as seen in Figure 7.30. Do not click OK, other pages need to be changed first.
233
Figure 7.30 Setting the SDK property page names to MySDK.
3. Select Install in the left column. On the install page, change the *.msi (install) file name to MySDK as seen in Figure 7.31. Do not click OK yet, one other page needs to be changed first.
Figure 7.31 Setting the install file name to MySDK.
234
4. To support C# (managed code) you will need to change the new SDK default properties the first time it is created. In the Solution Explorer window, select the Development Languages page to include managed development support (i.e., C#) as seen in Figure 7.32.
Figure 7.32 Including managed code (C#) support in the new SDK.
5. In Solution Explorer, select the SDKs folder and then, right click and choose Build All SDKs. It will take a couple minutes to build the new SDK. 6. If a Warning dialog box appears, read the warning and choose OK. After several seconds the SDK should build without errors. Platform Builder displays the location of the Microsoft Windows Installer (.msi) file for the SDK and information about the build process. 7. For future reference, note the location of the*.msi file. It appears on a line in the output window several lines above the Build succeeded message. This is the SDK install file needed by application developers. They need to install this file in Visual Studio 2005 to enable SDK-based application development for the new OS design.
235
8. To setup for the next tutorial on C#, we will need to install your new SDK on the development PC. It is suggested that Visual Studio be closed before installing the new SDK. Save the MyOS solution and exit Visual Studio. Run the MySDK.msi install program. Restart Visual Studio, open the MyOS project and download the MyOS Release project to the eBox. See Section 7.3, if you need to review the steps to download. Once the new SDK is installed in Visual Studio you can develop standalone C/C++/C# applications projects for the target system, compile code, and deploy (download) application code to the target device running the existing OS using a network connection. After creating the project, under Tools Options, the platform and target device selected for each project must be the name of the platform used when generating the new SDK in this case MySDK. On target devices without networking hardware support, the ActiveSync communication program can be used on a serial or USB port to deploy code from the host development system to the target system. This tutorial will use a faster network connection. Before you can deploy and run code developed using an SDK you will need to boot the OS on the target device and configure the communications setup used to deploy code to the target device. This is a different setup than was used to initially download the OS over the network, since the OS is already running in this case. These steps are explained in detail in the next section after developing a simple C# application to use for testing.
236
7.8 Tutorial VI: Creating and Building a C# Project

In this tutorial we will go through the steps needed to create and build a C# (C# is pronounced C sharp) project using your new SDK. This new C# project will be deployed to the MyOS project created in the previous tutorials. Using an SDK, you can create standalone C/C++/C# application development projects that do not exist as part of an OS project, but you also need to have the new OS already installed in the devices non -volatile memory, or download the OS to the target system and have the OS running first. Two instances (copies) of VS 2005 are required to support both C/C++ and C# debugging. C# code is deployed (downloaded) after the OS boots, unlike the earlier C/C++ subprojects which were pre-installed in the NK.BIN kernel file. 7.8.1 OS Build Requirements to Deploy Applications To support C# applications and code deployment, the OS build must include several items. To automatically deploy code developed as projects, a different networking communications setup is used called Corecon. Corecon requires that the following 5 support modules installed in the OS kernel: ConmanClient2.exe CMaccept.exe eDbgTL.dll TcpConnectionA.dll ClientShutDown.exe The Corecon catalog component appears under Third Party in the catalog view. Select the Corecon_X86 Files component to include these modules in your OS build (The Corecon component was previously installed as a separate item if it is not there see Section 7.2). The Corecon component modules are part of VS 2005 SP1, but they are added to the OS build using the Corecon_X86 catalog item. Corecon was included in the earlier MyOS project build tutorial. As an alternative on devices without any networking support, the ActiveSync program can be used to deploy code. ActiveSync can use a serial or USB port for communication. If ActiveSync is used, a version is installed on both the target device and the PC development system. ActiveSync is widely used on Windows Mobile Pocket PCs and Smart Phones. This tutorial will use Corecon and the network interface to deploy code since it is supported on the eBox and is faster. The IP address of the eBox also needs to be read when using DHCP or set in the case of a static IP address. So the OS build needs to include TCP/IP networking support and the network utilities catalog item (i.e., ipconfig and ping). C# uses .Net Compact Framework to execute code. You can specify to download .Net Compact Framework when code is deployed, but the OS still needs to include the dependencies for Compact Framework catalog item. In most cases, it is easier and faster to just include the .Net Compact Framework
237
catalog item in the OS build to support C# applications and not re-deploy the 8MB .NET Compact Framework module each time. If .NET Compact Framework is deployed to the device, a CAB file is used. In this case, the CAB File installer/uninstaller catalog item must be included in the OS build. Assuming that you followed the suggested steps earlier in building MyOS it should already include all of the preceding components needed to support C# deployment and .NET Compact Framework, so you will not need to rebuild it. 7.8.2 Creating and Writing a C# Project We will now go through the steps to create a simple C# Project. Start a second instance of VS 2005 and select File new project . The new project screen seen in Figure 7.33 will be displayed. On the form that appears in the left column, under Project types expand Other Languages, then expand Visual C#, expand Smart Device, and finally select Windows CE 5.0 (dont wo rry 5.0 works in 6.0). On some system installs, the Window CE 5.0 option may appear as just Windows CE. Under Templates on the right, select Device Application . Enter HelloCSWorld for the new project Name. Double check the settings just entered and then click OK.
Figure 7.33 Creating a C# Project.
238
Figure 7.34 The new HelloCSWorld project is created and it opens a Forms design window.
After a few seconds the new project will be created and you should see a Forms display appear similar to Figure 7.34. In the solution explorer view, note that the new HelloCSWorld project has been added. Once the project is created we need to add sample code. Right click on the Form and select Properties. Under Properties change the Form size to 320 by 240, a more appropriate size for a device with a small display area. The Form area should be smaller once the size is changed. Select View Toolbox, and the Toolbox should appear on the right. Using the toolbox, select a textbox and add a textbox to the form, then select a Button and add a button to the Form1 design as seen in Figure 7.35.
239
Figure 7.35 A textbox and a button is added to the Form using the toolbox.
Next we need to change the properties associated with the new textbox and button in the Form. Select the textbox in the Form, Right click and select Properties. The Properties window should appear. In the Properties window, change the text property window to HelloCSWorld . The text displayed in the Forms text window should change to HelloCSWorld. Next we need to add code to respond to the button click event. Select the button in the Forms window. In the Properties window, you should now see the properties of the button. At the top of the Properties window, you should see a small yellow lightning bolt icon. Click the lightning bolt icon. Next, double click the mouse on the highlighted Click entry and a code window should open.
240
The code window automatically opens to the location of the code to be executed in response to the button click event. We will change the text displayed inside the text box in response to a button click event. Type the following into the code window at the cursor:
textBox1.Text = "Goodbye";
Textbox1 is the default name of the first textbox and text is the text displayed. So when the button is hit, the textbox should say Goodbye. The code window should now look something like Figure 7.36. Select Build Build HelloCSWorld and the new project should build quickly with no errors.
Figure 7.36 Entering the new code to be associated with the button click event.
241
7.9 Tutorial VII: Deploying new application code to the target device
Now that a new C# application program has been created and built successfully, the next step is to deploy (automatically download) the new application to the target device for execution. If you are using VS to download or debug your new OS kernel, to also debug and deploy C# (managed code) you will need to run a second instance of VS 2005 using your C# project. The first instance of VS is busy downloading and debugging C/C++ code in the kernel. Trying to debug both C/C++ and C# at the same time with only one instance of VS 2005 will cause it to hang in CE 6.0. To setup both computer systems for the Corecon networking component used to deploy the code, several steps are required initially. Once the system is setup, you should be able to continue to deploy new application code until the eBox is reset or your application crashes the eBox. Several steps are required initially, so pay attention and be careful not to leave one out. If the MyOS release build is not already running on the eBox from the earlier step, using the first instance of VS attach the target device, download and boot the MyOS release build on the eBox. Wait for the OS to boot. (Just like in the earlier OS build tutorial) If the eBox is setup to use DHCP, you need to determine its assigned IP address that was obtained when it booted (With DHCP this can change every time the eBox boots). On the eBox target system, use Start Run, type CMD and then select OK to bring up the Pocket command window on the eBox. Type ipconfig and note the IP address, it will be needed later. This can also be done on the development PC in the Windows CE Command Window by hitting Alt+1, and then typing s ipconfig /d at the command prompt. The IP address appears in the VS output window. If the eBox is setup to use a static IP address, you need to assign the static IP address on the eBox. On to eBox, select Start Settings Network and Dial-up Connections. Select the network device icon on the window that appears, right click and select properties. Setup the static IP address and the Subnet Mask (255.255.255.0) for the eBox. The IP address will be needed later. A registry setting is also available to initially setup a static IP address. If you do not want to setup the network manually, you can add the following (substituting your static IP, DNS, and Gateway address) to the OS Design s Project.reg registry file (not Platform.reg). ; Manually configure an IPv4 Address [HKEY_LOCAL_MACHINE\Comm\PCI\RTL81391\Parms\Tcpip] "DefaultGateway"=multi_sz:"192.168.0.1" "EnableDhcp"=dword:0 "DNS"=multi_sz:"192.168.0.1" "IPAddress"=multi_sz:"192.168.0.128" "SubnetMask"=multi_sz:"255.255.255.0"
242
Project.reg is displayed when you expand Parameter Files and ICOP_Vortex86_60B in Solution Explorer. The advantage here is with the registry entry you only have to setup the IP once in a new OS Design Project. In either case, DHCP or Static IP, the PC development system and the target device need to be on the same subnet (i.e., only the last number .xxx) in the IP address can be different) for deploy to work. The first time, you should confirm that the PC development system is actually on the same subnet as the target device, run the ipconfig command on the PC. In Vista, open the command prompt window found in the Accessories program group and type ipconfig /all. (In XP use Start Run type Cmd click OK type ipconfig /all). Next you need to set the target devices IP address settings in the VS 2005 instance that is running C#. Back in VS 2005 in the solution explorer window, select HelloCSWorld . Right click and select Properties. In the HelloCSWorld properties window that appears, select Devices . Unclick the option to deploy the latest version of .NET Compact Framework . (Assuming that you have included it in your OS build this will save download time)
Figure 7.37 First step in setting up the target device s IP address for deploying code.
Select Tools Options and then in the options window expand Device Tools and select Devices. Change the default device to use MySDK x86 Device or the factory default eBox4300_WINCE600_SDK . Make sure that the MySDK x86 Device is highlighted as seen in Figure 7.37 and hit the Properties button.
243
The new window in Figure 7.38 appears. Confirm the settings and click the configure button next to TCP Connect Transport.
Figure 7.38 Second step in setting up the target device s IP address to deploy.
In the Configure TCP/IP Transport window shown in Figure 7.39 type in the actual IP address assigned to the eBox and click OK three times to exit.
Figure 7.39 Final step, type in the target devices actual assigned IP address.
244
Now that the connections are setup, we need to start the Corecon communication components running on the eBox and confirm that the processes are running. In the VS 2005 instance with your MyOS design, hit ALT+1 to bring up the Windows CE Command Prompt window. At the command prompt type the following three lines as seen in Figure 7.40 to start Corecon. s conmanclient2 s cmaccept gi proc
Next, confirm that the conmanclient2 and cmaccept processes are in the process list that appears to make sure that they are still running. If they do not run, you may be missing some of the five Corecon components in your OS build. After starting cmaccept you have three minutes to establish the initial connection. ClientShutdown is used to stop Corecon. If you ever lose an active connection after it connects, try stopping and starting Corecon again.
Figure 7.40 Starting the Corecon components running on the target device.
245
If you add the AutoLaunch subproject 19 to your OS build, it will automatically start the CoreCon components. It adds the registry entries needed to automatically start the CoreCon components immediately after the OS boots. This is a real time saver when you are doing extensive application debugging or developing a device without a display or keyboard. See Appendix A for more details on using AutoLaunch. As another alternative, you can also start the Corecon components using the CE command window running on the eBox. For this approach, open the eBox command window (Start Run, type CMD, and then click OK ). Back in the eBox command window, type Conmanclient2 , repeat the process for another command window and run Cmaccept (no S is typed here on the eBox , there is no gi proc command to use , and Cmaccept works but it does not return to the command line prompt on the eBox). This approach is useful if you boot the eBox using a local copy of the kernel. To verify that everything is setup properly, in the VS instance with the C# HelloCSWorld project select Tools Connect to device then select the MySDK device and click connect as seen in Figure 7.41.
Figure 7.41 Select the MySDK Device to connect.
19
The AutoLaunch subproject was developed by James Wilson and Mike Hall (www.learningce.com )
246
When the connection is successful the Connection succeeded message window will be displayed as seen in Figure 7.42.
Figure 7.42 The Corecon components are running on the target device and it is now connected.
Now that a connection has been setup, applications can be deployed to the target device. If you have problems connecting, double check the network connections and the IP address setup steps described earlier. You may need to stop and start the Corecon components on the eBox again, if you make any changes to the network setup. Back in the solution explorer view window in the VS 2005 instance with your C# project, select the HelloCSWorld Project, right click, and select Debug Start New Instance. After a few seconds, the project should deploy without errors and a deploy was successful message appears in the VS output window. Several seconds later the HelloCSWorld application should load and start running on the eBox as seen in Figure 7.43.
247
Figure 7.43 The new C# application has been deployed and is running on the eBox.
On the eBox, click the HelloCSWorlds button and confirm the message in the textbox changes to Goodbye as shown in Figure 7. 44. Click the X in the upper right corner of the window to exit. The window should close. Congratulations you have now successfully developed, compiled, deployed and run a C# application. Complete details on C# application programming are beyond the scope of this document, but there are a number of excellent on-line resources and textbooks on C# programming and the .NET Compact Framework available. Back in the solution explorer view window, browse around the projects *.cs files and note all of the code that was automatically generat ed by the Forms design wizard. Once the system has been connected properly and deploys, you can test an application, make changes, and re-deploy the new application without changing the connection setup as long as you do not have to re-boot the eBox. If you reboot you will need to repeat the entire deploy setup process.
248
Figure 7.44 The new C# applications textbox changes after the button is clicked.
While the device in remains connected, breakpoints also can be set in C# code using operations similar to the earlier debugging tutorials with C/C++ breakpoints. In Figure 7.45 in the copy of VS 2005 running the C# code using the mouse, a breakpoint was set in the code view of Form1.cs on the code line for the button click event. When the code runs on the eBox and the button is clicked, the breakpoint is encountered as seen in Figure 7.46. Set a breakpoint in Form1.cs as seen in Figure 7.45, deploy the code again and start the debugger again. Verify that you stop at the breakpoint as seen in Figure 7.46 when you click the button on the HelloCSWorld GUI on the eBox.
249
Figure 7.45 Setting a breakpoint in the HelloCSWorld C# code at the button click event.
Once you have developed a stable application and want to run it without debugging and deploying it each time over the network, you can copy the applications *.exe file to a USB Flash drive, the internal Flash drive, or a CF card and run it on the eBox without having to connect and deploy it each time. If you want to boot from USB Flash, see Appendix A. By default, C# code deploys to files in /Program Files folder on the device and it can also be run manually on the device from that folder after it has be deployed.
250
Figure 7.46 The C# HelloCSWorld code stops at the breakpoint when the GUI button is clicked.
This same SDK development approach is typically used on larger team projects that need a number of application developers. The application developers can use the SDK and do not need regenerate the OS for the device to develop and test applications. SDKs are also occasionally released by embedded device manufact urers, so that others can develop applications code for their existing commercial embedded products. Many manufacturers do not want the end customer to be able to change the OS, since it would make support very difficult, if not totally impossible. This is typical on popular consumer devices such as cell phones and PDAs. As long as you are constantly making changes in the OS and rebuilding it on a routine basis, the approach used here (making a C# application another project) is easier. Once you have a stable OS build, and do not need support for
251
debugging you can combine the OS and C# projects into one solution in Visual Studio. Once you have the OS and the application code developed, the eBox can be configured to automatically boot your new OS and even start running applications automatically at boot time. It can boot from the internal Flash drive or a USB Flash drive.
7.10 Setting the Build Options for Standalone Operation

In a final product running in its normal operating mode, most embedded devices boot the OS from flash and can operate completely standalone (i.e., totally independent of the development system PC). To be able to fully demonstrate mobile and portable devices in operation, a standalone boot setup will often be required.
Figure 7.47 Selecting the build options for a standalone release build.
Once a new device has been debugged and developed to the point where complete standalone operation is desirable and the eBox is no longer permanently attached to the development system PC, switch to a release build and select the OS build options shown in Figure 7.47. Remove KITL and the kernel debugger build options from any standalone release build for the final
252
device or the eBox will hang forever trying to establish the debug communications with a development system PC (that is no longer attached to the eBox). Checking the box on the WinCEShip build option will eliminate even more debug messages. After changing the build options, rebuild the OS. The OS image can be downloaded over the network connection, the new NK.BIN OS boot file can be copied to the eBoxs internal flash drive, or booted from a USB Flash drive. Section 11.6 will provide additional details on the steps to setup the eBo x for standalone operation and booting using the internal Flash memory. Appendix C has the complete details on making a bootable USB Flash drive for the eBox. If the final system needs to start running application programs once it boots, use the Autolaunch project to automatically start running multiple applications once the OS boots and after all OS services have initialized and are available for use by application code. Autolaunch is especially useful in headless devices without a keyboard and display. The Autolaunch subproject is described in Appendix A. A headless device with networking support can also export the video display image and import mouse and keyboard commands using a window on a PC with the CE remote host program that is described in Appendix B.

The Microsoft web sites have other tutorials and labs on using Visual Studio 2005 and C# that may be of interest. The eBox 4300 Windows Embedded CE 6.0 Jump Start Guide also contains several basic eBox tutorials ( www.embeddedpc.net )

1. Use the on-line help system in Visual Studio to find additional information on the CE GetTickCount API call. What does it do? 2. Run through the tutorials in this Chapter in the laboratory using an eBox. Use the Tools Remote Tools Zoom tool to capture a screen image of the OS running on the eBox and the C/C++, and C# tutorial applications running on the eBox. If necessary, add a long Sleep(ms_delay) API call at the end of C/C++ Hello World application, so that you can capture the screen image before it closes. 3. Build both a debug run-time image and a release run-time image as outlined in the tutorial. Determine and compare the memory requirements. 4. Build a release run-time image without .NET Compact Framework support for C#. Compare the memory requirements to your kernel with .NET Compact Framework. How much larger is the kernel file with .NET Compact Framework?
253
5. Run the Osbench benchmark program on your release kernel. Examine the output and summarize the average timing of the OS synchronization primitives. Download your kernel, type ALT+1 and at theWindows CE> prompt type s osbench all. The output from Osbench appears in the output window.
6. Build a Small OS kernel using the Small Footprint Device template that has minimal features. Include the Tiny Kernel Test Sample Application (TKTEST) catalog item in the OS Build. Compare the size to the original run-time image from the tutorial. In the TKTEST code, note the use of the RETAILMSG function. 7. Add the minimal OS features needed so that you can run the TKTEST program on your Small OS kernel with it attached to the development system PC. Verify that the basic Small OS kernel functions are working by running TKTEST on the eBox.
CHAPTER 8
Application Programming in CE
This Bernina Artisita Sewing Machine can be programmed to sew complex patterns. New patterns can also be downloaded. It runs Windows Embedded CE. Photograph courtesy of Mike Hall.
256
8 Application Programming in CE
As an introduction to developing application programs, several short Windows Embedded CE C/C++ programs are provided to demonstrate the basic operation of the I/O devices on the eBox using Windows Embedded CE. It is assumed that the reader is already familiar with basic C/C++ syntax. To keep these programs short and easy to follow, the first few examples are all simple CE console applications (text only is sent to the console window - no windows or graphics). C/C++ programs can write text to the console using the printf function for ASCII or the wprintf function for Unicode strings. This will keep our early example programs short and a bit easier to follow. In later examples, more typical Windows (GUI-based) applications and a simple C# example will be introduced. If you have a custom generated CE kernel, it needs to include console application support to run and display the output from these simple console programs. The console window does not appear until the first character is sent out to the console by a program. Source code files are available for all of the demo programs. These files can be copied from the CDROM provided with this document and installed as subprojects to your OS design for quick demos. Once they are included in the OS C/C++ examples can be run using Target Run Programs or started using the CE command window on the eBox. C# programs will need to be deployed as was described in the last tutorial in Chapter 7.
8.1 FileIO example program

This C++ program creates a file, writes a file, and then closes the new file. Next it opens the file for a read operation, reads the data back, displays it, and closes the file again. Status messages are displayed on the console. After a short pause to allow the user to view the status messages on the console window, the program automatically exits. In Windows Embedded CE, these file operations are provided by CreateFile, ReadFile, WriteFile, and CloseHandle API function calls. The CE Sleep(milliseconds) API function call is used to pause the program. Note the use of Unicode for the file names string using _T(..) and TCHAR . After running the program, you can also examine the contents of the new file, \Temp\CE_Demo.txt, using an editor like WordPad on the device. Note in a C string \\ is used for one slash character.

// FileIO.cpp : Defines the entry point for the console application. // // FileIO demo program // Shows how to create, write, and read a file using CE file APIs // // Remember CE uses 16-bit Unicode for character strings! // _T("....") generates a Unicode string // TCHAR is a Unicode string type // #include "stdafx.h" int _tmain(int argc, TCHAR *argv[], TCHAR *envp[]){ HANDLE hFile; DWORD cBytes; char cBuffer[] = "Hello File World\n"; printf("\nCreating CE_Demo.txt file\n"); // Open File for Write hFile = CreateFile(_T("\\Temp\\CE_Demo.TXT"), GENERIC_WRITE, FILE_SHARE_WRITE, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
257
// Check for file open errors if (hFile == INVALID_HANDLE_VALUE){ printf("file write open errors\n"); Sleep(1000); return 0; } // Write to File if (!WriteFile(hFile, cBuffer, strlen(cBuffer), &cBytes, NULL)){ printf("file write errors\n"); Sleep(1000); return 0; } // Close File CloseHandle(hFile); // Open File again for read hFile = CreateFile(TEXT(""), GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); // Check for file open errors if (hFile == INVALID_HANDLE_VALUE){ printf("file read open errors\n"); Sleep(1000); return 0; } // Read back data just written to new file if (!ReadFile(hFile, cBuffer, 79, &cBytes, NULL)){ printf("file read errors\n"); Sleep(1000); return 0; } // Display Data read back and delay 4 seconds before exiting printf("%s\n",cBuffer,cBytes); printf("the file data was written and read back OK\n"); Sleep(4000); // Close File CloseHandle(hFile); return 1; }
258
8.2 SerialIO example program using OS File I/O Calls

This C++ example program reads the serial input data from COM2:, displays each character on the eBox console window, and echoes it back as output to COM2:. The program uses the basic CE File I/O API functions CreateFile, ReadFile, WriteFile, and CloseHandle to transfer data to/from the serial port. In the function, ModifyCommSettings , the API calls, GetCommStatus and SetCommStatus, are used to obtain, modify, and then set the COM ports baud rate, number of data bits, and handshake options from the default values. The API call, SetCommTimeouts. is used to set timeouts for serial read and write operations. It can be used to specify if a read operation should wait for character input or return immediately. The API call, WaitCommEvent , is used to block the process until an input character appears. This is more efficient in terms of processor time and power than constantly looping. SetCommEvent is used to define what type of communications event will trigger WaitCommEvent . Normally, one would not block the main process and a thread would be used to read or write the serial port. Since the main process in this example is only echoing data, a thread is not needed. To view the serial data, the serial null modem cable is connected from COM2: on the eBox to a unused COM port on the desktop PC development system. Running HyperTerminal or another terminal emulator program, connect to the COMx: port at 9600 baud, 8 data bits, no parity, 1 stop bit, and flow control set to none. When the program runs, it prints out a header and then each character typed on the desktop PCs keyboard is sent to the eBox, it reads in the characters, displays them in the console window, and echoes the characters back. Since they echo back, they are also displayed in the terminal emulator. Typing Ctrl-C in the terminal emulator, forces the eBox to exit the program and a CloseHandle call releases the COM port for use by other applications.
259
Figure 8.1 HyperTerminal running on development system and communicating with eBox COM Port
// // // // // // //
SerialIO.cpp : Defines the entry point for the console application. Serial Port File I/O Demo Program FOR DEMO: Connect Ebox COM2: to PC with null modem cable Run HyperTerminal with 9600 Baud 8 data bits 1 stop bit no parity and no flow control
#include "stdafx.h" BOOL ModifyCommSettings (HANDLE hComPort); HANDLE hSerial; int _tmain(int argc, TCHAR *argv[], TCHAR *envp[]) { DWORD cBytes_out, cBytes_in; DWORD dwMask; char cBuffer_out[] = "\f\n Hello Serial World! \n\r Type something and watch it echo back \n\r Ctrl C to exit \n\r"; TCHAR cBuffer_in[80]; // Display message on console printf("\nOpening COM2: Serial Port - Type ctrl C on other device to exit\n\r"); // Open Serial Port COM2: for Read and Write // Note: COM1: is normally setup to send out Debug info // In this case COM2: becomes COM1: in the OS
260
hSerial = CreateFile(_T("COM1:"), GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0, NULL); // Check for file open errors if (hSerial == INVALID_HANDLE_VALUE){ printf("file open errors\n"); Sleep(4000); return 0; } // Modify Com Port settings (i.e., Baud Rate, #bits, parity etc) if(!ModifyCommSettings (hSerial)){ printf("com port settings errors\n"); Sleep(4000); return 0; } // Write to title out to serial port. if (!WriteFile(hSerial, cBuffer_out, strlen(cBuffer_out), &cBytes_out, NULL)) { printf("file write errors\n"); Sleep(4000); return 0; } // Set Communication event mask for WaitCommEvent for rxchar (recieve character) in buffer SetCommMask(hSerial, EV_RXCHAR | EV_ERR); cBuffer_in[0] = 0; // Read in characters, copy to console display and Echo // Loop until ctrl C is typed while (cBuffer_in[0] != 0x03){ // Wait for character in input buffer - events are more efficient than looping WaitCommEvent(hSerial, &dwMask, 0); cBytes_in = 1; // Loop just in case more than one character is in UARTs input buffer while (cBytes_in != 0){ // Read back data any serial data and display if (ReadFile(hSerial, cBuffer_in, 64, &cBytes_in, NULL)){ if (cBytes_in == 0) break; // Display Data read back printf("%s",cBuffer_in, cBytes_in); // Echo characters back to sender if (!WriteFile(hSerial, cBuffer_in, cBytes_in, &cBytes_out, NULL)){ printf("\rfile write errors\n"); Sleep(4000); return 0; } } } } // Close File CloseHandle(hSerial); return 1; } // Function to set COM port options

BOOL { ModifyCommSettings (HANDLE hComPort)
261
COMMTIMEOUTS ctos; DCB PortDCB; // Initialize the DCBlength member. PortDCB.DCBlength = sizeof (DCB); // Get the default serial port settings DCB information. GetCommState (hSerial, &PortDCB); // Change the common DCB structure settings to modify serial port settings. PortDCB.BaudRate = 9600; // Current baud PortDCB.fBinary = TRUE; // Binary mode; no EOF check PortDCB.fParity = TRUE; // Enable parity checking PortDCB.fOutxCtsFlow = FALSE; // No CTS output flow control PortDCB.fOutxDsrFlow = FALSE; // No DSR output flow control PortDCB.fDtrControl = DTR_CONTROL_ENABLE; // DTR flow control type PortDCB.fDsrSensitivity = FALSE; // DSR sensitivity PortDCB.fTXContinueOnXoff = TRUE; // XOFF continues Tx PortDCB.fOutX = FALSE; // No XON/XOFF out flow control PortDCB.fInX = FALSE; // No XON/XOFF in flow control PortDCB.fErrorChar = FALSE; // Disable error replacement PortDCB.fNull = FALSE; // Disable null stripping PortDCB.fRtsControl = RTS_CONTROL_ENABLE; // RTS flow control PortDCB.fAbortOnError = FALSE; // Do not abort reads/writes on error PortDCB.ByteSize = 8; // Number of bits/byte, 4-8 PortDCB.Parity = NOPARITY; // 0-4=no,odd,even,mark,space PortDCB.StopBits = ONESTOPBIT; // 0,1,2 = 1, 1.5, 2 // Configure the port settings according to the new specifications // of the DCB structure. if (!SetCommState (hSerial, &PortDCB)){ printf("Unable to configure the serial port"); Sleep(4000); return false; } // Set read time outs ctos.ReadIntervalTimeout = MAXDWORD; ctos.ReadTotalTimeoutMultiplier = MAXDWORD; ctos.ReadTotalTimeoutConstant = 1; ctos.WriteTotalTimeoutMultiplier = 0; ctos.WriteTotalTimeoutConstant = 0; if(!SetCommTimeouts(hSerial, &ctos)){ printf("Unable to configure the serial port"); Sleep(4000); return false; } return true; }
8.3 PortIO example program using the CE Device Driver Kit

Like the previous example program, this C++ program reads the serial input data from COM2:, displays each character on the eBox console window, and echoes it back as output to COM2:. Instead of CE File I/O API calls, it uses the WRITE_PORT_UCHAR and READ_PORT_UCHAR functions found in the CEDDK library. A CEDDK.h
262
include file is required and the code must be linked to the CEDDK.lib. These functions communicate directly to the I/O ports on the COM ports UART hardware and are typical of the operations required in the lowest level of a device driver that needs to communicate directly with hardware. We will modify this example later to create a simple OS Stream Interface Device Driver. The intent of this example is to illustrate how low level device driver code communicates with I/O hardware. A device driver in the operating system would normally be used to communicate with the serial port as in the previous example. So the point here is just to understand some of the first basic steps that will be required to eventually write your own device driver for the OS. COM2: contains a 16550 UART compatible hardware interface with a base I/O address of 0x2F8. A 16550 UART data sheet or a PC hardware reference text will explain the details of how all of the eight consecutive UART I/O ports are used for data, status, and the many other serial options such as baud rate, number of data bits etc. Interrupts are disabled and Programmed I/O is used for serial port data transfers. Table 8.1 lists the basic functions of the UARTs I/O ports. The first two addresses serve a dual purpose. They can also be used to set the baud rate divisor when the divisor latch bit (DLB) is one (in Data Format register bit 7). In normal operation mode, the divisor latch bit is set back to zero. This code is not intended as a replacement for a professional interrupt driven serial device driver with buffering and timeouts such as is provided with CE as was used in the first serial port demo program. It serves only to demonstrate using programmed I/O for data transfers, and the use of the CEDDKs I/O port R/W functions that are typically found in the lowest-level of device drivers that communicate directly with hardware. Table 8.1 16550 UART I/O Ports Register Function I/O Port Address Data (DLB=1, Baud rate divisor LSB) Base + 0 Interrupt Enable (DLB=1, Baud rate divisor MSB) Base + 1 Interrupt ID Base + 2 Data Format Base + 3 Modem control Base + 4 Line Status Base + 5 Modem status Base + 6 Scratch-Pad Base + 7
263
Note the use of programmed I/O in the functions write_serial_character and read_serial_character . These functions read in the appropriate UART device ready bit from the status port, mask off the bit, test it, and loop if needed, before transferring data. Recall that & is a bitwise AND and | is a bitwise OR operation in C/C++. Sleep(0) exits for the current time slice and puts the process back in the queue waiting for its turn to run again. Once again, to view the serial data, the serial null modem cable is connected from COM2: on the eBox to a unused COM port on the desktop PC development system. Running HyperTerminal or another terminal emulator program, connect to the appropriate COM x: port at 9600 baud, 8 data bits, no parity, 1 stop bit, and flow control set to none. Make sure you are not running another application on either device that is using the same COM port! When the program runs, it prints out a header and then each character typed on the desktop PCs keyboard is sent to the eBox, it reads in the characters, displays them in the console window, and echoes the characters back. Since they echo back, they are also displayed in the terminal emulator. Typing Ctrl-C in the terminal emulator, forces the eBox to exit the program.
// // // // // // // // // // // // // // // // // PortIO.cpp : Defines the entry point for the console application. Educational example intended to illustrate how programmed I/O works using the serial I/O port hardware on the target system and show the use of READ_PORT_UCHAR and WRITE_PORT_UCHAR from the CE Device Driver Kit (CEDDK) Setup for X86 PC (CEPC) using 16550 UART compatiable serial port hardware Not intended to replace a good serial port device driver! Does not use interrupts, have any timeouts, or provide support for all of the serial port's features Would normally use OS API calls for this operation! FOR DEMO: Connect Ebox COM2: to PC with null modem cable Run HyperTerminal with 9600 Baud 8 data bits 1 stop bit no parity and no flow control
#include "stdafx.h" // For WRITE_PORT_UCHAR & READ_PORT_UCHAR functions #include "..\WINCE600\CEPC_x86\cesysgen\ddk\inc\ceddk.h" // Also need to include CEDDK.lib in link (see sources file) // add $(_SYSGENOAKROOT)\lib\$(_CPUINDPATH)\ceddk.lib // to TARGETLIBS entries void Setup_UART (PUCHAR Data_Port_Address); void Write_Serial_Character (PUCHAR Data_Port_Address, UCHAR Serial_Data); UCHAR Read_Serial_Character (PUCHAR Data_Port_Address); int _tmain(int argc, TCHAR *argv[], TCHAR *envp[]) { PUCHAR Data_Port_Address;
264
UCHAR Serial_Input_Data = 0; char Title[]= "\f\n Hello Serial World!\n\rType something and watch it echo back\n\rCtrl C to exit\n\r"; int i; // Force Console to Display printf("I/O Port READ/WRITE Demo Program - Echos data on COM2:\n\r Type Ctrl C on other device to exit\n\r"); // Data Port Address for COM2: Data_Port_Address = (PUCHAR)0x2F8; // Sets up UART for 9600 Baud & No Interrupts with 8D NP 1S Setup_UART(Data_Port_Address); // Print title out on serial port for (i=0; i<strlen(Title); i++) Write_Serial_Character(Data_Port_Address, (UCHAR)Title[i]); // Start Echo Loop - Loop until Ctrl C is hit while (Serial_Input_Data != 0x03){ // Read in Data Serial_Input_Data = Read_Serial_Character (Data_Port_Address); // Copy Data to Console printf("%c", Serial_Input_Data); // Write Data Back out (Echo) Write_Serial_Character(Data_Port_Address, Serial_Input_Data); } return 0; } void Write_Serial_Character (PUCHAR Data_Port_Address, UCHAR Serial_Data) // Write out a character to the serial port { UCHAR Status; // Wait for TX output ready bit=1 // Status I/O Port Address is Data I/O Port Address + 5 do{ Status = READ_PORT_UCHAR(Data_Port_Address + 5); } while ((Status & 0x40) == 0); // Write (Echo) new data back out on COM2: WRITE_PORT_UCHAR(Data_Port_Address, Serial_Data); return; } UCHAR Read_Serial_Character (PUCHAR Data_Port_Address) { // Read in a character from the serial port UCHAR Serial_Data, Status; // Wait for RX input ready bit=1 // Status I/O Port Address is Data I/O Port Address + 5 do{ Status = READ_PORT_UCHAR(Data_Port_Address + 5); // If not ready release remainder of time slice if ((Status & 0x01) == 0) Sleep(0); } while ((Status & 0x01) == 0); // Read in new serial data Serial_Data = READ_PORT_UCHAR(Data_Port_Address); return Serial_Data;

} void Setup_UART (PUCHAR Data_Port_Address) { UCHAR Temp; // Will need a good PC Hardware Reference Text and/or // the 16550 UART data sheet to fully understand this! // Disable COMx: Interrupts (use Programmed I/O) WRITE_PORT_UCHAR(Data_Port_Address + 1, 0); // Set Baud Rate to 9600 with clock Divisor settings // Put in set divisor mode Temp = READ_PORT_UCHAR(Data_Port_Address + 3); WRITE_PORT_UCHAR(Data_Port_Address + 3, Temp | 0x83); // Set Divisor LSB (note: 12 = 115200/9600) WRITE_PORT_UCHAR(Data_Port_Address , 12); // Set Divisor MSB WRITE_PORT_UCHAR(Data_Port_Address + 1, 0); // Back to normal operation mode (and set for 8D NP 1S) Temp = READ_PORT_UCHAR(Data_Port_Address + 3); WRITE_PORT_UCHAR(Data_Port_Address + 3, Temp & 0x03); return; }
265
8.4 Linking to other modules using the Projects sources file

When writing more complex applications, the subprojects sources file must be used to set search paths for include files and specify other modules to link with the subproject. The Build process reads each subprojects sources file to determine how to make the project. By default, all subprojects are linked to coredll.lib in the sources file. Coredll.lib library defines many of the basic API calls, but many API calls are defined in other libraries. In the on-line help system, each API call entry lists the header and library files needed for that API near the end of its page in the Requirements section. If you need to link an application to a user created *.DLL file that has an associated *.lib file available, the process is the same. API calls that are defined in other libraries will need to have the path to that library added to t he subprojects sources file. These are added to the TARGETLIBS= section in the sources file or can be added using the subproject property window (right click on project name, select properties and the link tab). If a link file is missing, a link error s uch as undefined symbol or missing external reference type error will be generated. For long complex paths, it is easier to edit the sources file directly. By double clicking on the main subproject name entry, the sources file will open in the editor. A \ is used for line continuation. Be careful, a slash must be the last character on each line, filenames must be separated with a space, and after the last \ a blank line or a line containing the last text line for that section is actually needed before the next section. If additional header files (*.h) are required, an INCLUDES= section will need to be added to the end of the sources file. Paths for include files are separated by semicolons (not spaces) and a \ is used again for continuation.
266
These can also be set using the subprojects properties window under the C/C++ tab or by editing the sources file. When entering paths in the sources file several predefined CE path environment variables are available of the form $(..). When possible, try t o use the predefined path variables so that project files can be more easily moved to other directories or drives, if needed. An environment variable contains information such as a drive, path, or configuration string. These are separate from Sysgen variables, which control the functionality included in your OS design. Table 8.2 contains miscellaneous environment variables that you can use to specify directory paths. Many of these are set up in Wince.bat. Table 8.2 Environment Variables used for Paths Environment variable _WINCEROOT Description Defines the root directory. If you have enough space on a single partition, create a root directory on that partition, such as C:\WINCE600, and install the OS under it. To do this, set %_WINCEROOT% to the full root directory path. Defines the directory where the released source code and binary files will be placed. The default is %_WINCEROOT%\ PBWorkspaces\%_TGTPROJ%\RelDir\%_TGTPLAT%\%_T GTCPUFAMILY%_Release.
_FLATRELEASEDIR
PBWORKSPACEROOT Defines the location of the current Platform Builder workspace. The default is %_WINCEROOT%\PBWorkspaces \%_TGTPROJ%. However; if you have placed your root directory in a location other than the default; that location is used as the definition for %PBWORKSPACEROOT%. _PLATFORMROOT Defines the location of the Platform directory. The default is %_WINCEROOT%\Platform.. _PRIVATEROOT Defines the location of an alternate root directory, such as a directory to contain a different Set Environment Variable tool, Setenv.bat. You can set this variable to point to a directory of your choice. The default is %_WINCEROOT%\Private. Defines the location of the Oak directory for your project. During the build process, Build.exe places the files it builds in this directory. The default is %_PROJECTROOT%\Oak. Defines the location of the project you are building; for example, %_PBWORKSPACEROOT%\WINCE500 \%PBCONFIG%.
_PROJECTOAKROOT
_PROJECTROOT
267
_PUBLICROOT _SDKROOT
Defines the location of public projects. The default is %_WINCEROOT%\Public. Defines the location of the tools you use to build projects, such as the command-line compiler, linker, debugger, and run-time libraries. The default is %_WINCEROOT%\SDK. Defines the name of the current active workspace.
_TGTPROJ
When you create an OS design with Platform Builder, the integrated development environment (IDE) sets specific environment variables based on the settings you choose for your design and run-time image. You can modify these environment variable settings during the development process. You can set or clear environment variables from: A command prompt build window using the set command. Use the top level Build menu and open a build command window. A batch file The IDE. Right click on the project and select properties and then expand the configuration item.
Open the sources file for the PORTIO subproject and examine the TARGETLIBS and INCLUDE sections. Notice that a line was added to link this module with the ceddk.lib. This library is required for READ_PORT_UCHAR and WRITE_PORT_UCHAR APIs.
8.5 ILASMIO example program using in-line X86 assembly code

This demo program is identical to the previous serial port demo except it does not use the CEDDK library for the I/O port read and write functions. The two lowest level functions, Read_Port and Write_Port , found at the end of the example code are implemented using in-line X86 assembly language. This C++ program reads the serial input data from COM2:, displays each character on the eBox console window, and echoes it back as output to COM2:. Using assembly language takes longer to develop, makes code less portable, and should be avoided whenever possible. There are still a few rare occasions when a low-level routine (i.e., CEs OAL routines) in an embedded device must be implemented in assembly language, and this can be done directly in a C\C++ source program using in-line assembly. If you examine the CEDDK library source files provided with CE carefully, you will find that in fact the lowest-level routine also uses in-line assembly language to communicate with the I/O port. However, the CEDDK will automatically change the assembly code for a different processor.
268
Once again, this code is not intended as a replacement for a production quality interrupt driven serial device driver with I/O buffering and timeouts such as is provided with CE as was used in the first serial port demo program. It serves only to demonstrate how to use in-line assembly language to communicate directly with hardware in a C/C++ program. As before, to view the serial data, the serial null modem cable is connected from COM2: on the eBox to an unused COM port on the desktop PC development system. Running HyperTerminal or another terminal emulator program, connect to the COM x: port at 9600 baud, 8 data bits, no parity, 1 stop bit, and flow control set to none. Make sure you are not running another application that is using the same COM port on either machine! When the program runs, it prints out a header and then each character typed on the desktop PCs keyboard is sent to the eBox, it reads in the characters, displays them in the console window, and echoes the characters back. Since they echo back, they are also displayed in the terminal emulator. Typing Ctrl-C in the terminal emulator, forces the eBox to exit the program.
// ILASMIO.cpp : Defines the entry point for the console application. // // Educational example intended to show the use of in-line X86 assembly // language and illustrate how programmed I/O works // using the serial I/O port hardware on the target system // (use assembly only when you have to!) // // Setup for X86 PC (CEPC) // using 16550 UART compatiable serial port hardware // // Not intended to replace a good serial port device driver! // Does not use interrupts, have any timeouts, or provide // support for all of the serial port's features // Would normally use OS API calls for this operation! // // FOR DEMO: Connect Ebox COM2: to PC with null modem cable // Run HyperTerminal with 9600 Baud 8 data bits 1 stop bit // no parity and no flow control #include "stdafx.h" void Setup_UART (short int Data_Port_Address); void Write_Serial_Character (short int Data_Port_Address, UCHAR Serial_Data); void Write_Port (short int Data_Port_Address, UCHAR Data); UCHAR Read_Port (short int Data_Port_Address); UCHAR Read_Serial_Character (short int Data_Port_Address); int _tmain(int argc, TCHAR *argv[], TCHAR *envp[]) { short int Data_Port_Address; UCHAR Serial_Input_Data = 0; char Title[]= "\f\n Hello Serial World!\n\rType something and watch it echo back\n\rCtrl C to exit\n\r"; unsigned int i; // Force Console to Display
269
printf("I/O Port X86 ASM READ/WRITE Demo Program - Echos data on COM2:\n\r Type Ctrl C on other device to exit\n\r"); // Data Port Address for COM2: Data_Port_Address = 0x2F8; // Sets up UART for 9600 Baud & No Interrupts with 8D NP 1S Setup_UART(Data_Port_Address); // Print title out on serial port for (i=0; i<strlen(Title); i++) Write_Serial_Character(Data_Port_Address, (UCHAR)Title[i]); // Start Echo Loop - Loop until Ctrl C is hit while (Serial_Input_Data != 0x03){ // Read in Data Serial_Input_Data = Read_Serial_Character(Data_Port_Address); // Copy Data to Console printf("%c", Serial_Input_Data); // Write Data Back out (Echo) Write_Serial_Character(Data_Port_Address, Serial_Input_Data); } return 0; } UCHAR Read_Serial_Character (short int Data_Port_Address) { // Read in a character from the serial port UCHAR Serial_Data, Status; // Wait for RX input ready bit=1 // Status I/O Port Address is Data I/O Port Address + 5 do{ Status = Read_Port(Data_Port_Address + 5); // If not ready release remainder of time slice if ((Status & 0x01) == 0) Sleep(0); } while ((Status & 0x01) == 0); // Read in new serial data Serial_Data = Read_Port(Data_Port_Address); return Serial_Data; } void Setup_UART (short int Data_Port_Address) { UCHAR Temp; // Will need a good PC Hardware Reference Text and/or // the 16550 UART data sheet to fully understand this! // Disable COMx: Interrupts (use Programmed I/O) Write_Port(Data_Port_Address + 1, 0); // Set Baud Rate to 9600 with clock Divisor settings // Put in set divisor mode Temp = Read_Port(Data_Port_Address + 3); Write_Port(Data_Port_Address + 3, Temp | 0x83); // Set Divisor LSB (note: 12 = 115200/9600) Write_Port(Data_Port_Address , 12); // Set Divisor MSB Write_Port(Data_Port_Address + 1, 0); // Back to normal operation mode (and set for 8D NP 1S) Temp = Read_Port(Data_Port_Address + 3); Write_Port(Data_Port_Address + 3, Temp & 0x03); return; }
270
void Write_Port (short int Data_Port_Address, UCHAR Data) { // X86 in-line assembly language // use only when you have to! _asm { mov dx,Data_Port_Address mov al,Data out dx,al } return; } UCHAR Read_Port (short int Data_Port_Address) { UCHAR Data; // X86 in-line assembly language // use only when you have to! _asm { mov dx,Data_Port_Address in al,dx mov Data,al } return Data; }
8.6 Thread and synchronization event example program

The C/C++ Thread_Demo program shows how to create a thread using the API call CreateThread . The main process and thread both print out a console message line each time they execute a loop iteration. Threads normally need to be synchronized to other events, in this case we will assume it should be synchronized to each loop iteration of the main process that created the thread. In Figure 8.2, no synchronization is used and the thread runs several times before the main program finishes one loop iteration. The Sleep function was used to simulate each thread having a greatly different execution time so that any synchronization problem is more readily apparent. In Figure 8.3, a synchronization event was added to keep the main thread and the worked thread synchronized on the same iteration. The synchronization code can be seen in comment lines in the while loop at the end of the code. CreateEvent sets up an event, SetEvent signals an event, and WaitForSingleObject blocks the worker thread until the event is set by the main thread. Other synchronization methods available in the CE APIs include mutexes, semaphores, and critical sections. Would the threads still be synchronized if the worker thread had a very long execution time or something else in the system forced it to run an iteration slower? Change the code (hint: Sleep) and try it. If they are not fully synchronized, how would you fix the problem?
271
Figure 8.2 A thread running without synchronization can run several times before the main program
Figure 8.3 Thread running using WaitForSingleObject to wait for a synchronization event
272
// Thread_Demo.cpp : Defines the entry point for the console application. // // Demo that shows how to create and synchronize a thread using an event // #include "stdafx.h" //Thread Function DWORD WINAPI WorkerThread (LPVOID lpArg); HANDLE g_hMainEvent = 0; int _tmain(int argc, TCHAR *argv[], TCHAR *envp[]) { HANDLE hThread1; DWORD dwThread1ID = 0; INT nParameter = 1; int count1 = 0; printf(" \n"); _tprintf(_T(" Hello Thread World!\n")); g_hMainEvent = CreateEvent(NULL, FALSE, FALSE, NULL); Sleep(1000); hThread1 = CreateThread (NULL, 0, WorkerThread, (LPVOID)nParameter, 0, &dwThread1ID); while (count1 < 100){ printf(" main thread computes value: %d\n",count1); count1++; SetEvent(g_hMainEvent); Sleep(370); } CloseHandle(hThread1); CloseHandle(g_hMainEvent); return 0; } DWORD WINAPI WorkerThread (LPVOID lpArg) { INT threadnumber = (INT) lpArg; INT count = 0; INT RunCode; while (1){ // RunCode = WaitForSingleObject(g_hMainEvent, INFINITE); // if (RunCode == WAIT_OBJECT_0){ printf(" worker thread %d computes value %d\n", threadnumber, count); count++; Sleep(50); // } } return 0; }
The remote tools ( Tools Remote Tools) are useful to display information about processes and threads running on the target system. The Remote Process viewer displays information about each process and thread running. If you highlight a process, the red X w ill kill the process. Remote Kernel Tracker
273
graphically displays processes and synchronizations events vs. time. It runs faster when the settings for the number of information view items is reduced.
Figure 8.4 The process viewer can be used to check the status of processes and threads .
Figure 8.5 The kernel tracker shows which process is running and displays synchronization events. The exact state of the two threads from the thread demo program can be seen.
274
Figure 8.6 The kernel tracker displays all of these events.
Other remote tools you should try and may find useful include: Zoom used for remote screen capture Remote Registry Editor Edit and view the target device registry Remote File Viewer see files on target device, download (export) a file Heap Walker - displays information about the heap. Call Profiler - provides a graphical interface for profiling and analysis. Spy display a list of windows open on the target and messages
8.7 The Producer Consumer Problem

The Producer Consumer problem is a classic synchronization problem discussed in many OS classes and textbooks 20. Two threads are running. One thread is busy producing items that are inserted into a shared buffer. The second thread consumes items from the shared buffer. Since the two threads share global variables for the buffer area, the use of synchronization primitives is required to avoid erratic operation (recall that access to shared variables must be mutually exclusive in parallel processes or threads). In this example, a critical section is used for synchronization whenever the threads access shared data used for the buffer area. The buffer is setup as a circular buffer area (i.e., the end of the buffer wraps back around to the start). Two buffer pointers are used, one to write data into the buffer named in and one to read data from the buffer named out. The
20
One such text is Operating System Concepts 6th Edition, by Shilbershatz and Gavin.
275
C/C++ % mod operator used each time one of the pointers is incremented is used to wrap the pointers around when they reach the end of the buffer. A count of the number of items in the buffer is also used. The producer increments the count, and the consumer decrements the count. The buffer can fill up and force the producer to wait, or it can be empty and force the consumer to wait. To simulate the random time required to produce or consume each buffer item the Sleep function is used. Its argument is a random time delay provided by Random, the random number generator in C. The item inserted into the buffer is an increasing time stamp value returned by GetTickCount . Here is a first attempt at a solution. An intermediate step is required to fully understand the issues. We will fix some problems it has later.
// ProCom.cpp : Defines the entry point for the console application. // Producer Consumer problem with a shared circular buffer // // Demo that shows how to create and use critical sections // #include "stdafx.h" //Thread Function DWORD WINAPI ConsumerThread (LPVOID lpArg); // Critical Section CRITICAL_SECTION CriticalSection; // Shared Circular Buffer and pointers int count = 0; int in = 0; int out = 0; DWORD Buffer[3]; int _tmain(int argc, TCHAR *argv[], TCHAR *envp[]) { HANDLE hThread1; DWORD dwThread1ID = 0; INT nParameter = 1; int i; printf(" \n"); _tprintf(_T(" Producer Consumer example\n")); for (i=0; i<4; i++) Buffer[i] = 0; InitializeCriticalSection(&CriticalSection); hThread1 = CreateThread (NULL, 0, ConsumerThread, (LPVOID)nParameter, 0, &dwThread1ID); // Producer while (1){ // Check for Buffer Full while (count == 4) { printf("Buffer Full - Producer Waiting\n"); }; // Insert new item into Buffer // Shared Global Variables - use Critical Sections EnterCriticalSection (&CriticalSection);
276

printf(" producer thread produces new item at Buffer[%d] \n",in); ++count; Buffer[in] = GetTickCount(); in = (in + 1) % 4; LeaveCriticalSection (&CriticalSection); // Random delay to simulate process producing new item for Buffer Sleep(Random()>>21); } CloseHandle(hThread1); DeleteCriticalSection(&CriticalSection); return 0;
} DWORD WINAPI ConsumerThread (LPVOID lpArg) { INT threadnumber = (INT) lpArg; // Consumer while (1){ // Check for Buffer Empty while (count == 0) { printf("Buffer Empty - Consumer Waiting\n"); }; // Remove item from Buffer // Shared Global Variables - use Critical Sections EnterCriticalSection (&CriticalSection); --count; printf(" consumer thread consumes item from Buffer[%d] with time stamp %d\n",out,Buffer[out]); out = (out + 1) % 4; LeaveCriticalSection (&CriticalSection); // Random delay to simulate process consuming Buffer item Sleep(Random()>>21); } return 0; }
Figure 8.7 shows the Producer Consumer problem running on the eBox. The random time delays should help uncover synchronization issues. Assuming synchronization is working properly, you should always see the time stamp increase as it runs. But this first example has at least two problems. First, the global variable count is referenced outside of the critical section. This violates the mutual exclusion rule for shared variables, but moving it into the critical section would lock up the threads. Second, the while loops can consume a lot of CPU time and power. It would be better to block the threads. With three semaphores, we can fix these two problems with a second version of the Producer Consumer problem. One semaphore is used for mutual exclusion and it takes the place of the critical sections.
277
The second and third semaphores replace the while loops by indicating the buffer full and buffer empty conditions. The value of these two semaphores is key to understanding this solution. They require different initial values, one is set to 0, and one is set to the maximum buffer size of 4. The variable count is actually no longer needed, but is handy to print out full and empty messages. So the threads now block with a semaphore instead of spinning in a while loop (saving both processor time and power) and the possible synchronization issues with count are resolved.
Figure 8.7 Sample Output from the first Producer Consumer Problem.
// ProCom.cpp : Defines the entry point for the console application. // Producer Consumer problem with a shared circular buffer // // Demo that shows how to create and use semaphores // #include "stdafx.h" // Semaphores static HANDLE mutex_semaphore; // mutual exclusion lock static HANDLE full_semaphore; // something is in buffer static HANDLE empty_semaphore; // buffer has an empty space // Shared Circular Buffer and pointers
278
static int in = 0; static int out = 0; static int count = 0; // Shared Buffer Area DWORD Buffer[4]; //Thread Function DWORD WINAPI ConsumerThread (LPVOID lpArg); int _tmain(int argc, TCHAR *argv[], TCHAR *envp[]) { HANDLE hThread1; DWORD dwThread1ID = 0; INT nParameter = 1; int i; printf(" \n"); // setup semaphores and their initial and max values mutex_semaphore = CreateSemaphore(NULL, 1, 1, TEXT("mutex")); // 1 for mutex lock full_semaphore = CreateSemaphore(NULL, 0, 4, TEXT("full")); // 0 items in buffer empty_semaphore = CreateSemaphore(NULL, 4, 4, TEXT("empty")); // 4 max items in buffer _tprintf(_T(" Producer Consumer example\n")); for (i=0; i<4; i++) Buffer[i] = 0; hThread1 = CreateThread (NULL, 0, ConsumerThread, (LPVOID)nParameter, 0, &dwThread1ID); // Producer while (1){ // Wait for empty space in buffer WaitForSingleObject(empty_semaphore, INFINITE); // Shared Global Variables - use mutex WaitForSingleObject(mutex_semaphore, INFINITE); // Insert new item into Buffer Buffer[in] = GetTickCount(); count++; // Check for buffer full message if (count >= 4) printf("producer thread produces new item at Buffer[%d] %d Buffer now Full \n",in, Buffer[in]); else printf("producer thread produces new item at Buffer[%d] %d \n",in, Buffer[in]); in = (in + 1) % 4; ReleaseSemaphore(mutex_semaphore, 1, NULL); ReleaseSemaphore(full_semaphore, 1, NULL); // Random delay to simulate process producing new item for Buffer Sleep(Random()>>21); } CloseHandle(hThread1); CloseHandle(mutex_semaphore); CloseHandle(full_semaphore); CloseHandle(empty_semaphore); return 0; } DWORD WINAPI ConsumerThread (LPVOID lpArg) { INT threadnumber = (INT) lpArg; // Consumer

while (1){ // Wait for item in buffer WaitForSingleObject(full_semaphore, INFINITE); // Shared Global Variables - use mutex WaitForSingleObject(mutex_semaphore, INFINITE); count--; // Check for Buffer Empty message if (count == 0) printf("consumer thread consumes item from Buffer[%d] %d Buffer now Empty\n",out,Buffer[out]); else printf("consumer thread consumes item from Buffer[%d] %d\n",out,Buffer[out]); // Remove item from Buffer out = (out + 1) % 4; ReleaseSemaphore(mutex_semaphore, 1, NULL); ReleaseSemaphore(empty_semaphore, 1, NULL); // Random delay to simulate process consuming Buffer item Sleep(Random()>>21); } return 0; }
279
Figure 8.8 Sample Output from the second Producer Consumer Problem using Semaphores .
280
8.8 AC97 example program using CE API audio functions

The following example program rings a bell seven times on the AC97 Audio output device. A standard PC speaker or stereo headphone can be connected to the audio output jack on the front of the eBox to hear the output (the jack with the headphone symbol). The CE kernel also needs to have been built with the BSPs audio device driver selected. The PlaySound API call only plays one sound file at a time. A delay is added using Sleep to separate the sounds and to pause before the program exits and closes the console window. This example uses a built-in Windows sound file , EXCLAM . With a minor change, you can play any custom wave file. For more complex sounds and mixing use the waveout API calls. The wavein API calls can be used to record sounds using a PC microphone. Audio sounds will be distorted a bit whenever you are connected to the debugger since it slows things down, especially when debug messages are being displayed or one of the remote tools connects to the device. Source code examples using wavein and waveout APIs including an audio recorder and player can be found in the WINCE600\PUBLIC\COMMON\SDK\SAMPLES\AUDIO subdirectory.
// Playsound.cpp : Defines the entry point for the console application. // #include "stdafx.h" int _tmain(int argc, TCHAR *argv[], TCHAR *envp[]) { int i; _tprintf(_T("Hello Audio World!\n")); Sleep(1000); // Play WAV file seven times on audio device for (i=0; i<7; i++) { // Uses registry wave file entry for EXCLAM // Can replace with path to your wav file // if you add | SND_FILENAME to third arg PlaySound (TEXT("EXCLAM"), NULL, SND_SYNC); Sleep(500); } Sleep(1500); return 0; }
281
8.9 A basic Windows application, the Hello World example

In this example program, a Windows (GUI-based) application is created rather than just a text only console application. It is important to realize that a normal Windows program is different than other programming models in which the application program requests input from the operating system using explicit API calls such as getc and putc. In a Windows application program, the operating system notifies the application that keyboard and mouse input is available by sending messages to the application. Messages are automatically generated by the operating system whenever mouse or keyboard activity associated with the window occurs. Clicking a button or selecting a menu item with the mouse generates a message. Windows applications are written to respond to this series of messages from the operating system. Messages are recognized by the application program using a series of predefined constants, such as WM_CREATE and WM_DESTROY. This process in the same in both the Windows desktop operating systems and Windows Embedded CE. A programming style traditionally used in Windows programs and in this example program is to prefix each variables name with lower case characters that indicate the variable s type. This improves readability of the code, once you understand meaning of the prefixes since you dont nee d to hunt around multiple files for a variable s declaration to figure out its type. The more commonly used Hungarian notation prefixes are shown in Table 8.3. Prefixes can be combined. For example, lpsz, is a long pointer to a string. To easily identify the lowercase prefix, the first character of a variable name is typically uppercase. As an example, szTitle, one of the first variables in the example program is a string that contains the title. Table 8.3 Common Hungarian Notation Prefixes Used for Variables in Windows Programs Variable Type Integer Word (16-bit) Double Word (32-bit) Long (32-bit signed) Char String (zero terminated) Pointer Long Pointer Handle Window Handle Structure Size Hungarian Prefix i or n w or s dw l c sz p lp h hwnd cb
282
The use of prefixes was recently dropped by many authors for new desktop OS code development, but its use still continues today in many embedded code examples. The sample Windows application in the next code example is based on the code automatically generated by CE when a simple C/C++ hello world windows application is created. Following the code example, note that all Windows programs have the program entry point, WinMain. Upon entry the application must register its main window class. In the example code this is done in MyRegisterClass. Various Window style options are specified. All windows are instances of a window class. Next the application must create, display, and update the new Window. In the example program this operation is performed in InitInstance. After WinMain registers, creates, shows, and updates the main window, it enters a windows messaging loop. In the example program, find the while loop at the end of WinMain. This is the critical part of any windows application. It stays in the While message loop as long as the application is running. GetMessage blocks until a new message is available from the operating system. Translate message translates appropriate keyboard messages into a character message. The DispatchMessage function notifies the operating system to forward the new message to the appropriate window in the application. The application remains in the while loop until a WM_QUIT message is received. This special message forces GetMessage to return a value of zero and terminates the while loop and the application exits. As each new message is dispatched, the operating system automatically activates the applications callback procedure, WndProc. The OS passes the new message to it. Find this function near the end of the example program code. A windows applications callback function (i.e., WndProc) processes each message by decoding it in a switch statement. The operations required for each message are coded into each case. After the message is processed, the callback function returns. The callback procedure must respond to a large number of messages. In more complex application programs, instead of a very large switch statement another method is sometimes used to decode messages faster. An array structure is created with each entry containing the message code and a pointer to a function that handles each message. The array is searched in a loop in the callback function and when the message code is found the function is called. Most effort in developing a new Windows application program is spent in coding the applications windows callback procedure and the code required to handle each message. Graphical tools can be used to design the GUI and automatically generate windows code templates for C/C++ and C# programs. The developer still needs to manually enter the code to implement the actions required to react to each windows messages.

// WinAPP.cpp : Defines the entry point for the application. // #include "stdafx.h" #include "resource.h" #define MAX_LOADSTRING 100 // Global Variables: HINSTANCE hInst; TCHAR szTitle[MAX_LOADSTRING]; TCHAR szWindowClass[MAX_LOADSTRING]; // current instance // The title bar text // The title bar text
283
// Forward declarations of functions included in this code module: ATOM MyRegisterClass(HINSTANCE hInstance); BOOL InitInstance(HINSTANCE, int); LRESULT CALLBACK WndProc(HWND, UINT, WPARAM, LPARAM); int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPTSTR lpCmdLine, int nCmdShow) { // TODO: Place code here. MSG msg; HACCEL hAccelTable; // Initialize global strings LoadString(hInstance, IDS_APP_TITLE, szTitle, MAX_LOADSTRING); LoadString(hInstance, IDC_WinAPP, szWindowClass, MAX_LOADSTRING); MyRegisterClass(hInstance); // Perform application initialization: if (!InitInstance (hInstance, nCmdShow)) { return FALSE; } hAccelTable = LoadAccelerators(hInstance, (LPCTSTR)IDC_WinAPP); // Main message loop: while (GetMessage(&msg, NULL, 0, 0)) { if (!TranslateAccelerator(msg.hwnd, hAccelTable, &msg)) { TranslateMessage(&msg); DispatchMessage(&msg); } } return msg.wParam; } // // FUNCTION: MyRegisterClass() // // PURPOSE: Registers the window class. // ATOM MyRegisterClass(HINSTANCE hInstance)
284
{
WNDCLASS wc; wc.style = CS_HREDRAW | CS_VREDRAW; wc.lpfnWndProc = (WNDPROC) WndProc; wc.cbClsExtra = 0; wc.cbWndExtra = 0; wc.hInstance = hInstance; wc.hIcon = 0; wc.hCursor = 0; wc.hbrBackground = (HBRUSH) GetStockObject(WHITE_BRUSH); wc.lpszMenuName = 0; wc.lpszClassName = szWindowClass; return RegisterClass(&wc); } // // FUNCTION: InitInstance(HANDLE, int) // // PURPOSE: Saves instance handle and creates main window // // COMMENTS: // // In this function, we save the instance handle in a global // variable and create and display the main program window. // BOOL InitInstance(HINSTANCE hInstance, int nCmdShow) { HWND hWnd; hInst = hInstance; // Store instance handle in our global variable hWnd = CreateWindow(szWindowClass, szTitle, WS_VISIBLE, 0, 0, CW_USEDEFAULT, CW_USEDEFAULT, NULL, NULL, hInstance, NULL); if (!hWnd) { return FALSE; } ShowWindow(hWnd, nCmdShow); UpdateWindow(hWnd); return TRUE; } // // FUNCTION: WndProc(HWND, unsigned, WORD, LONG) // // PURPOSE: Processes messages for the main window. // // WM_COMMAND - process the application menu // WM_PAINT - Paint the main window // WM_DESTROY - post a quit message and return // // LRESULT CALLBACK WndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)

{ PAINTSTRUCT ps; HDC hdc; TCHAR szHello[MAX_LOADSTRING]; LoadString(hInst, IDS_HELLO, szHello, MAX_LOADSTRING);
285
switch (message) { case WM_PAINT: hdc = BeginPaint(hWnd, &ps); // TODO: Add any additional drawing code here... RECT rt; GetClientRect(hWnd, &rt); DrawText(hdc, szHello, _tcslen(szHello), &rt, DT_CENTER); EndPaint(hWnd, &ps); break; case WM_DESTROY: PostQuitMessage(0); break; default: return DefWindowProc(hWnd, message, wParam, lParam); } return 0; }
8.10 Managed Code vs. Native Code

Embedded systems developers face a choice when developing applications for embedded devices in Windows Embedded CE. The choices are use managed code and/or native (unmanaged) code. Native code uses C/C++ as was used in the earlier example programs. In native code, routines are compiled directly to the target dev ices machine code. Managed code uses the new C# (pronounced C sharp) language or also Visual Basic.NET. We will focus our discussion and examples here on C#. C# compiles into an intermediate byte code called the Common Intermediate Language (CIL). During execution a just-in-time compilation process translates CIL into native instructions that are cached. This means that the next time the cached code is invoked the native instructions execute directly, instead of being reinterpreted from CIL. The .NET Compact Framework runs the CLI code in a protected environment on top of Windows Embedded CE. The common language runtime (CLR) and Framework Class Library (FCL) provide a layer of useful middleware functions for programmers that are not available in C/C++. Those readers already familiar with Java will see many similarities between the syntax for Java and C#, CIL and Java Byte Code, and the Java Virtual Machine (JVM) and .NET Compact Framework. C# offers developers several advantages over C/C++. C# application programmers are more productive especially when developing complex GUI graphical and network applications. C# provides a layer of middleware in these application areas that allows programmers to work at a higher level of abstraction than C/C++. C# includes built-in language features for threads and
286
synchronization (as in Java). C# also produces safer code in the sense that more run-time checking is done than in C/C++. Array bounds and data types are checked at run-time and direct pointer manipulation is not allowed in C# (as in Java). Another advantage is that only one version of the C# programs executable CIL code is needed to support the application on different types of processors running on different hardware platforms. The disadvantages of C# are the impact on memory use and performance. The .NET Compact Framework that is required to support C# increases the CE kernel size by several megabytes. Just-in-time compilation with run-time checking runs slower than native C/C++ code. Garbage collection routines need to periodically run to recover memory from discarded heap objects and perhaps even clear some code from the code cache. During garbage collection, all threads must be suspended and this can have a negative impact on the real-time performance of the system. In a desktop system with ample memory and fast processors this is less of a concern than in a small embedded device with limited memory and slower processors. Designers will need to evaluate the tradeoffs carefully when considering their options.
8.11 The C# Hello World Example Program

The code for a simple C# console application will now be examined briefly. C# uses namespaces. Namespaces prevent naming conflicts across independently created classes. The first line using System enables the compiler to check for references in the System namespace. This is where Console.WriteLine is found. Without using System the reference would need to be System.Console.WriteLine. Multiple using statements are allowed. Console.WriteLine displays the string argument on the console window (just like the C/C++ printf function) . Console.Readline reads in characters typed on the keyboard. This application prints a title and prompt on the console. It then continues to read lines typed in from the keyboard until the quit string is typed.
using using using using using System; System.Collections.Generic; System.Text; System.IO.Ports; System.Threading;
namespace Hello_CS_World { class Program { static void Main(string[] args) { bool _continue = true ; string message; StringComparer stringComparer=StringComparer.OrdinalIgnoreCase // Display title and prompt line on console Console.WriteLine("Hello C# World"); Console.WriteLine ("Type QUIT to Exit");
287
// Loop reading in lines from keyboard until user types "quit" while (_continue) { message = Console.ReadLine(); if (stringComparer.Equals("quit", message)) { _continue = false; } } } } }
As was done in the earlier C# tutorial described in Chapter 7 in Section 7.7, C# programs that create Windows are almost always designed using Visual Studios application designer that has graphical design tools that automatically produce code for a Windows Forms application. Event handler code is then manually added by the designer to respond to each event. C# events are similar to C/C++ Windows messages. There are numerous books that explain the C# software development tools in more detail.
8.12 The C# Serial Port Example Program

The SerialPort control can be used in C# to send and receive data from a serial port such as COM1: and COM2: on the eBox. It defaults to COM1: at 9600 Baud, 8 data bits, no parity, one stop bit, and no handshake. Be sure to install SP2 for .NET Compact Framework 2.0 or use 3.5 before using SerialPort (i.e., earlier versions have serial port open errors) and make sure that any other programs that might have the serial port open are not using it (i.e., CE serial debug messages, ActiveSync, KITL). Here is a C# example that prints Hello CS Serial World out on COM1:
using System; using System.Collections.Generic; using System.Text; using System.IO.Ports; namespace Hello_CS_Serial_World { class Program { static void Main(string[] args) { SerialPort _serialPort; // Create a new SerialPort object with desired settings. _serialPort = new SerialPort(); //Defaults to ("COM1", 9600, Parity.None, 8, StopBits.One) _serialPort.Open(); _serialPort.WriteLine("Hello CS Serial World"); _serialPort.Close(); } } }
288
8.13 Calling C/C++ functions from C#

When using C# managed code to develop applications, there are still some rare occasions when it is necessary to call functions written in unmanaged C/C++ code. A special interface called Platform Invoke (PInvoke) is used as seen in Figure 8.9 that provides this capability.
Figure 8.9 Calling C/C++ functions from C# using Platform Invoke (PInvoke).
The C/C++ functions used in C# code need to be exposed in a dynamic linked library (DLL) using __declspec(dllexport) in the C++ source code (or in a *.def file) with a syntax similar to: extern C{ _declspec(dllexport) DWORD Userfunction (. . .); } extern C {.} keeps the compiler from mangling (i.e. changing with a prefix) the C++ function names. It is not needed in plain C code. The following C# code needs to be added to a class or struct definition in C# to call the C/C++ function Userfunction defined and exported by Users. dll: [DllImport("Users.dll")] private static extern uint Userfunction( . . .); Data types are not exactly the same in C/C++ and C# in all cases, so when calling functions with multiple arguments of different types, one dimensional arrays, and strings it gets a little more difficult and you will need to consult other C# reference materials for additional details. The VS 2005 on-line help files contain a Platform Invoke Tutorial with more information on this topic.
289

The textbook, Programming Microsoft Windows CE.Net, Third Edition by Douglas Boling published by Microsoft Press contains additional details on developing C/C++ Windows Embedded CE application programs. Chapter 23 contains a brief introduction to C#. It also includes additional code examples to send and receive SMS messages. The textbook, Programming Microsoft Windows Embedded CE 6.0 , Fourth Edition by Douglas Boling published by Microsoft Press contains addit ional details on developing C/C++ Windows Embedded CE 6.0 application programs and is updated for CE 6.0. The on-line help system in Windows Embedded CE contains descriptions of all API calls and has additional example code. More details on writing C# programs can be found in . NET Compact Framework Programming with C# by Paul Yao and David Durant, and information on forms design can be found in Programming Windows with C# by Charles Petzold. The helpful P/Invoke Wizard tool demo is available at http://www.paulyao.com/resources/tools/pinvoke.asp A comparison of C# and Java language features can be found in The C# Programming Language for Java Developers available on-line at http://msdn.microsoft.com/vstudio/java/gettingstarted/csharpforjava/ X86 Assembly language reference manuals are available free on the web at www.ece.gatech.edu/~hamblen/Ebox.

1. Modify the file system example program so that the file is written to non-volatile storage (USB Flash, CF Card, or Internal Flash drive). Find the file on the eBox after you create and display the data to verify that it works. 2. Modify the serial port example program to use a higher baud rate of 38400 and test the code with the eBox attached to the PC running HyperTerminal or RealTerm. Consult a 16550 data sheet, if you need help understanding and setting the clock divisor. 3. Modify the thread example so that the threads are fully synchronized no matter what delay is present in the Sleep API calls. Use random delays as seen in the Producer Consumer problem and run the code on the eBox. 4. Modify the second producer consumer example to use a critical section instead of the mutex semaphore. Verify that it works by running the code on the eBox.
290
5. Modify the second producer consumer example to use a mutex lock instead of the mutex semaphore for its mutex lock on shared data. Verify that it works by running the code on the eBox. 6. Write a C/C++ model of the classic dining philosophers problem that uses CEs threads and semaphores. There are 5 philosophers sitting at a circular table. Philosophers eat or think (sleep). In the center of the table is food. There are a total a five forks, one on both the right and left of each philosopher. Since there are only five forks, the philosophers must share their forks with the philosopher on either side of them. In order to eat, a philosopher must have both forks. When they are trying to eat, they are in a permanent hungry state until they get both forks. The purpose of this problem is to design a way to take forks such that no philosopher starves (starvation). Also, it is possible for philosophers to deadlock (everyone grabs one fork and does not release it) without synchronization. Use a random time delay (like the producer consumer problem) for the think and eat events. Run your model on the eBox in a console application. You can find the full details on the problem setup in most OS textbooks or on the web. 7. Repeat the previous problem, but this time use C# and any of its built-in synchronization features. 8. Add an etchasketch subproject to your MyOS project and run it on the eBox. C source code for an etchasketch can be found in the following directory C:\WINCE600\PUBLIC\COMMON\OAK\DEMOS\ETCHA. Draw your name on the etchasketch and capture the image with the Zoom remote tool. 9. Write a C# web browser application named HelloWeb. A textbox is used to enter the URL. When a button is pressed it sends the new URL (text from textbox) to the browser. Use the WebBrowser window in the C# toolbar. The URL is a property of the WebBrowser window. The setup is very similar to the C# code developed in the tutorial. Verify that it works by running the code on the eBox and display a web page.
CHAPTER 9
Adding External I/O Devices and New Features
Fords Sync is a small embedded in-vehicle computer system running Microsofts Windows Automotive OS (CE-based) that wirelessly integrates mobile gadgets such as cell phones and media players. It is available with an LCD touch screen display, enables hands-free phone use, and has a universal music player that pulls songs from any MP3 player using voice-recognition control along with speech synthesis feedback. Photograph courtesy of Ford Motor Corporation.
292
9 Adding External I/O Devices and New Features

In this Chapter, several interesting I/O devices commonly found in embedded systems will be added to the eBox along with the supporting OS device drivers, new OS build steps required, and sample application programs that demonstrate each device in operation. The devices include digital inputs and outputs, analog inputs from sensors, a small LCD display, servo and motor controllers, an RFID reader, a USB web camera, a cell phone modem, and a GPS receiver. Several new software features such as a web server, speech synthesis, speech recognition, and optical character recognition will also be introduced and demonstrated on the eBox.
9.1 Phidget USB drivers and example programs

Phidgets are a family of low-cost USB-based external I/O devices. Phidgets modules support both analog and digital I/O. A wide array of sensors and interfaces are available for Phidgets. One of the more popular Phidget modules is shown in Figure 9.1. This module contains a 20 by 2 LCD display and digital and analog interface modules on the backside of the board. It supports 8 digital input and 8 digital outputs. Digital I/Os attach to screw terminal blocks on the back of the board. 8 analog sensor module inputs can attach to the board. Each analog sensor module attaches using special 3-pin connectors (5V power, analog signal, and ground). With the standard drivers, sample rates range from 50 to 125 samples per second.
Figure 9.1 This Phidget USB device contains a LCD and digital and analog I/O pins.
293
To use Phidgets on the eBox 4300 target hardware, five Phidget CE 6.0 device driver files need to be installed in the OS kernel and the appropriate registry entries added. Once the drivers are installed, Phidgets API calls are available and can be used in C/C++ and C# applications. Several API driver manuals and example applications are available at the Phidgets web site in the download area (www.phidgets.com). Complete source code for the Phidgets device driver is available as a CE shared source code community project. To simplify the driver installation, a PhidgetsDrivers subproject for CE 6.021 has been developed. The subproject does not recompile all of the drivers, rather it just copies the binaries to the release directory, sets up the necessary registry entries, and creates a *.bib file to include the drivers in the OS kernel. The CEFileWiz 22 tool is useful to initially create files for subprojects like PhidgetsDrivers. To include the Phidgets driver in a new OS kernel so that application programs can use Phidgets, copy the entire PhidgetsDrivers directory to your OSDesigns project directory that contains subproject directories (i.e., the default location is WINCE600\OSDESIGNS\MyOSProject\MyOSProject ). Since the poslink.bat file just copies files, the subproject directory must be in the correct location and it must also be named PhidgetsDrivers. After copying the PhidgetsDrivers directory, select Subprojects in solution view, right click and select add existing subproject and select PhidgetsDrivers.pbpxml . After several seconds a new PhidgetsDrivers subproject should appear. Right click on the PhidgetsDrivers subproject and select Build . The new PhidgetsDrivers subproject should now build without errors. If the directory is copied to the wrong location or misspelled, postlink.bat file copy errors will occur in the build. Check for any updates to the Phidgets Drivers for CE 6.0 at the Phidgets website. New driver binary files can be copied into the existing subprojects d irectory under \target\X86 in the release and debug directories. Once the drivers are installed correctly, when the new OS run-time image is running, when any USB Phidget device is plugged into the eBox the device should enumerate and load the appropriate driver automatically. A series of USB related messages will also appear in the debug output window. If the new USB device is unknown (i.e., the Phidgets driver is not installed correctly), a dialog box appears asking the user to type in the name of the driver for the new USB device. Several example C# demo applications can be found in the WindowsCE. NET Examples project that is provided with the drivers. They can be used to test the most common Phidget modules for correct operation. Complete source code fo r the applications is included. A project file is available that can be used to build
21 22
The PhidgetsDrivers subproject was developed by James Y. Wilson ( http://www.learningce.com ) CEFileWiz for CE 6.0 was developed by Mike Hall and is available free at his blog site at http://blogs.msdn.com/mikehall. The download URL is http://embeddedpodcast.com/Tools/CEFileWiz.zip.
294
the Phidget demo applications. After building the applications they can be deployed to the eBox and executed. The following C# applications are provided in the WindowsCE.NET Phidget example solution provided with the drivers: The InterfaceKit Controller displays the status of an 8/8/8 digital and analog I/O module. Digital states are indicated with a check box, and analog sensor values appear on slider bars. A handy way to check sensors. The TextLCD Controller can be used to display text typed in a text box on the Phidgets LCD module. The Phidget Manager displays the name and type of any attached Phidgets modules. The RFID controller will display the RFID tags currently read by the Phidgets RFID module.
Figure 9.2 The Phidget C# demo programs running on an eBox with several Phidgets attached.
295
These C# demo applications are shown running on the eBox in Figure 9.2. Phidget modules are attached to the eBox and sending data back to the GUI display. A sensor module is attached to the first analog input which displays on the first slider bar in the interface controller. The position of the slider bar indicates the relative value of the analog voltage reading from the sensor. The Phidget LCD is displaying Hello Phidget World and the RFID reader is reading in a tag value of 010230dff3. Note that the Phidget Manager has detected that the RFID Phidget, the Phidget Interface Kit with LCD, and the Phidget Servo Controller are all plugged into eBox USB ports. To develop your own Phidgets C# applications, study these examples and download the appropriate Phidgets API interface manuals for additional information. For C/C++ Phidgets applications, the C/C++ programs will need to include phidget21.h, load the Phidgets device driver using LoadLibrary(_T("phidget21.dll")), and use several GetProcAddress function calls to return each of the entry points needed for the Phidgets library functions, since there is no phidget21.lib available to link to a C++ project in the current driver release.
// Example using LoadLibrary to load Phidgets driver hModule = ::LoadLibrary(_T("phidget21.dll")); if (hModule == NULL) return 0; // Example showing the use of GetProcAddress for each entry point typedef int (__stdcall *Phidget_open)(CPhidgetHandle phid, int serialNumber); Phidget_open open = (Phidget_open)::GetProcAddress(hModule, _T("CPhidget_open"));
One GetProcAddress function call is need for each different Phidgets API entry point used in an application. The subproject, PhidgetsLCD 23, contains a C++ code example the displays both text and data on the Phidgets LCD module using this technique. The PhidgetsDrivers CE 6.0 subproject setup files were obtained from http://www.learningce.com/779.aspx . The shared source code community project driver files for Phidgets are available at http://www.codeplex.com/PhidgetsWinCEDriver . This site is the best place for comments and questions. The official Phidgets product download site may contain newer versions of the latest CE 6.0 drivers http://www.phidgets.com/modules.php?op=modload&name=Downloads&file=i ndex&req=getit&lid=30.
23
The PhidgetsLCD subproject code example is based on a student project by Eshwar Stalin.
296
The Panner C# project for the Phidgets R/C servo IR distance hardware setup was seen earlier in Figure 5.23. Panner scans for the nearest object 24. The servo angle is displayed in the LEDs and a GUI displays status information. Phidgets modules are also available to drive relays, DC motors, and stepper motors. The modules contain a USB microcontroller and special driver circuits that provide additional current for the relays or motors. An external power supply is used for the motor drive circuits, since the USB cable provided 5V DC power is limited to 500ma per device and most motors will require more current.
9.2 USB WebCam drivers and Camera test program

Many embedded devices contain cameras. A shared source code project for a USB web camera driver is available at www.codeplex.com/cewebcam. The complete details of the driver code are available in a white paper that is also available at the codeplex web site 25.
Figure 9.3 This Logictech Quickcam is running on the eBox using the WebCam driver and it took its own picture in a mirror using the CamTest2 camera test application. The Panner C# project code is based on an example in Creating a Windows CE 6.0 OS Design For Development With Phidgets Devices by James Wilson (search at http://www.academicresourcecenter.net) 25 Writing a Windows CE USB Webcam Driver, by Douglas Boling ( www.codeplex.com/cewebcam )
24
297
This driver was originally developed using the Logitech QuickCam Pro 5000, but it is reported to work on the QuickCam Fusion, MP, Ultra Vision, Pro 9000, Pro for Notebooks, Communicate Deluxe, Orbit/Sphre AF, Deluxe for Notebooks. Any new cameras that support the USB Video Standard version 1.1 should work with the driver. Cameras not in the list above will need a new registry entry with the USB vendor ID (VID) and product ID (PID) that is used to associate a new USB device to a driver when USB enumeration occurs. Source code for a basic camera test application, CamTest2.exe, is also provided. To make it easier to install the webcam.dll camera driver, setup the required registry entires for the new driver and camera, and copy the camera test application to the eBox file system, another subproject was developed, WebCam using this driver and test application. Including the WebCam subproject in your OS design project will automatically setup everything for the camera. It does not recompile the driver or the camera test application. It is identical in operation to the PhidgetsDrivers subproject described in the previous section, but it installs the camera driver and camera test application instead. All known supported cameras have already been included in the subprojects webcam.reg registry file. If necessary, edit the subprojects webcam.reg file to add more USB VID PID registry entries for newer cameras as they become available. Figure 9.3 was generated using the CamTest2 application running on the eBox. It displays live video from the camera and allows the user to change image size, frame rates, and a number of other camera settings. Another option allows an image to be saved in *.jpg format and it was used to produce Figure 9.2. After including the WebCam subproject in an OS build, you should be able to plug in the camera to the eBox and it will load the camera driver. If it asks for a USB driver name when the camera is plugged in, the driver is not installed properly or there is not a correct USB VID PID registry entry for your exact camera model. The CamTest2 test application that you will find preinstalled in the eBoxs Windows directory will open a window on the eBox displaying live video from the camera. With this driver, the performance is not sufficient to be able to display the highest resolution image at the highest possible frame rate, so consider the tradeoffs carefully for your application when you select the video resolution and frame rate. CamTest3 is a port of the older CamTest2 to Visual Studio 2005 CE 6.0 that was developed as a student project 26. It contains source code that can be used as a starting point for applications that need to process image data. The motion detection feature code in CamTest3 includes an example that processes image data. Keep in mind that any image processing likely needs to use very simple calculations and low resolution images to run in real-time on the eBox.
26
CamTest3 was ported by Josh Beavers.
298
An alternative CE camera driver is also available from Microsoft 27. This driver is meant to be used as the source filter in a DirectShow capture graph for multimedia, rather than as a stand-alone stream-based driver. Using this driver requires detailed knowledge of DirectShow. For multimedia applications, it offers higher performance than the stream driver used in the WebCam subproject, but using it is more complex. After the CE camera driver is installed it shows up as a third party catalog item. A recent student project developed DirectShow filters to send and receive images over the network using WinSock 28. It achieved frame rates around twice as fast as the stream interface driver. Processor time for image conversion for the display limits frame rates on the eBox. Shared source code sample applications are included in CE 6.0 in WINCE600/Private/Test/Multimedia/DirectX/Dshow/Camera , including the CaptureFramework library and the CameraDshowApp. These examples are useful when developing applications using the CE camera driver.
9.3
Using the CEbased Web Server (HTTPD)
Many new embedded devices support networking. Once networking is available, it is convenient to use a web page style interface to configure, control, or display and receive data from a device remotely using a web browser running on another computer. This is especially true for small headless devices such as network routers, firewalls, and many internet appliances. The eBox can be easily configured to support a basic web server using an additional catalog item during the OS build step. Windows CE 6.0 also includes an example FTP and Telnet Server catalog item that can be added to an OS build. The FTP server defaults to the \temp directory and it also has several registry settings that can be used for configuration. The Windows Embedded CE-based Web Server (HTTPD) implementation enables you to monitor, configure, and remotely control a device or computer through the use of a Hypertext Transfer Protocol (HTTP) server. Web Server implements a subset of HTTP 1.0 and allows connections to be maintained through keep-alive functionality. The Web Server provides file downloads, multiple virtual paths, and simultaneous connections. Web Server applications send Hypertext Markup Language (HTML) pages to a requesting browser. You only need an Internet connection and a browser to be able to make use of the Web Server. The WebServer subproject is setup to provide a quick demonstration of a simple web server running on the eBox. The subproject just copies a default web page and image file to the eBox file system. The web page files for the server are placed in the \Windows directory on the eBox. The WebServer subproject just sets up an example web page there that has a default.htm file and an image file used on the page. You can browse the file system on the eBox to find them. The WebServer subproject is intended as a quick demo only, it does not activate the web server security features that would protect it from a hacker. See the
27 28
http://www.microsoft.com/downloads and search for the CE camera driver download. http://users.ece.gatech.edu/~hamblen/489X/S08PROJ/NetSink&Source_Filters/
299
extensive on-line help files for the Web Server (HTTPD) for full details on registry settings for security, users, and passwords. These registry settings can be added to the subprojects *.reg file, and currently only the default security values are used for the demo. To setup the Web Server demo, the WebServer subproject is added to an OS Design and an additional new catalog item is required. In addition to networking support which should already be included (assuming your OS design project is setup as per the earlier tutorials) the Web Server (HTTPD) catalog item needs to be added. It is found under Core OS CEBASE Communications Services and Networking Servers. After adding it and including the existing WebServer subproject, rebuild the OS.
Figure 9.4 A sample Web Server running on the eBox provided this web page.
To run the example, download the new OS to the eBox. Since the eBox does not have a registered domain name, the eBox IP address must be used as the URL in the web browser. If you need to determine the eBox IP address, on the
300
eBox start Windows CE and use Start Run Cmd and type ipconfig /all and note the eBoxs IP address. If you are using DHCP, dont forget that the IP address could change whenever you reboot the eBox. Start a web browser on your PC development system and use the URL, http://eboxIPaddress/ eBox.htm. A sample hello world web page should appear as seen in Figure 9.4. If you are using the web server in an application you should consult the online help to configure the security settings and move the web directory back to the default value of \Windows\www\wwwpub by changing the registry setting in the WebServer subprojects *. reg file, or set it to use a USB Flash drive or a CF card on the eBox. USB drives or CF cards would provide additional space for all of the web servers files since space o n the internal flash drive is limited. Additional Catalog items can be added in your OS design to add support for authentication, Internet Server Application Program Interface (ISAPI) extensions, ISAPI filters, and/or active server pages (ASP). Services.exe loads the Web Server at system startup. You can create web-based interfaces for Windows CE devices by creating an ASP 3.0 web page, creating an ISAPI filter, or using ASP.NET. ASP.NET is a web application framework that programmers can use to build dynamic web sites, web applications and web services. A third party ASP.NET web server for CE is available from OpenNETCF (http://www.opennetcf.com/). Padarn is a very small-footprint ASP.NET web server designed to run under Windows CE 6.0. A live Padarn ASP.NET demo running on an eBox is available at http://www.padarn.net/. Padarn provides a subset of Microsoft's ASP.NET. A special educational-use-only version of Padarn is available for schools.
9.4 Adding Speech Synthesis and Recognition Technology

Speech synthesis and voice recognition technology is often found in embedded devices. Various algorithms and programs have been developed over the years to automatically synthesize human speech from text. Such software is commonly called a Text-to-Speech (TTS) engine. Windows CE 6.0 does not include a TTS or engine or speech recongizer, but it defines standard API calls that can be used with optional third party TTS software. This software is available at extra cost from third parties. To provide a low-cost alternative for student projects, an open source TTS engine, eSpeak 29, was ported to Windows CE 30. ESpeak uses a technique called formant synthesis. Phonemes are the fundamental building block sounds that are used to generate all human speech. First, each word is translated to a series of phonemes using a dictionary and rules. Next, sinusoidal synthesis is used for vowels and short waveform files are used for consonant phonemes. For eSpeaks formant synthesis technique, *. wav files and transitions are maintained in three sets of data files phondata, phontab, and phonindex. So in
29 30
http://espeak.sourceforge.net/ http://users.ece.gatech.edu/~hamblen/489X/S08PROJ/OCR_TTS/
301
addition to the TTS program code, a significant number of supporting data files are also required on the device in the espeak-data directory. The input to TTS is text and synthesized speech can be output in a standard audio *. wav file format. An example application, Speak, was developed to demonstrate speech synthesis on the eBox. Speak is a CE console application that is run from the command line. Running Speak with no command line arguments outputs a default hello speech synthesis world message on the eBox sp eaker audio output. Speak has an optional argument which is a different text string to speak (i.e., Speak speak this text instead ). The Speak program code is shown below. Speak checks for the argument string presence and then runs the tts.exe engine using an automatically generated command line that is invoked using the CreateProcess API call. CreateProcess allows a process to spawn another process. It then waits for an event flag using WaitForSingleObject that indicates that tts has completed execution. Tts outputs an audio *. wav file. Using the audio *. wav file just created, Speak then calls the PlaySound API to play the audio *. wav file on the speaker audio output.
// Speak.cpp : Defines the entry point for the console application. // Uses Espeak Text to Speech Engine X86 port for Windows CE - tts.exe // http://users.ece.gatech.edu/~hamblen/489X/S08PROJ/OCR_TTS/ // See Espeak commands at http://espeak.sourceforge.net/commands.html // Copy tts.exe to device's \windows directory // Copy espeak-data directory and all files and // subdirectories to device's \ directory // Copy of these files is in this subproject directory // Type "Speak" at the CE command prompt for demo #include "stdafx.h" #define BUFFER_SIZE 4096 int _tmain(int argc, TCHAR *argv[], TCHAR *envp[]) { wchar_t command_buffer[BUFFER_SIZE+32]; wchar_t buffer[BUFFER_SIZE]; wchar_t wave_file[16]; wchar_t voice[16]; PROCESS_INFORMATION pProcInfo; if ((argc > 1) && (wcslen(argv[1]) < BUFFER_SIZE)) { // if command line string argument is there speak it wcscpy(buffer, argv[1]); } else { // no argument passed, so speak default message wcscpy(buffer,_T("hello speech synthesis world!")); } wcscpy(voice, _T("default")); wcscpy(wave_file, _T("TTSout.wav")); // Create tts command line arguments wsprintf(command_buffer, _T("-w %s -v %s \"%s\""),wave_file, voice, buffer); DeleteFile(wave_file); printf("Converting from text to wave file. Please wait... \n\r");
302

// Run tts.exe process to produce human speech wave file CreateProcess(_T("tts.exe"), command_buffer, NULL, NULL, NULL, 0, NULL, NULL, NULL, &pProcInfo); // Wait until tts exits WaitForSingleObject(pProcInfo.hProcess, INFINITE); printf("TTS conversion done. Now playing wave file. \n\r"); // Use PlaySound API to play speech in wave file PlaySound(wave_file, NULL, SND_FILENAME | SND_SYNC); DeleteFile(wave_file); return 0;
} To run the Speak application, first you need to add the Speak subproject to your OS build project and then copy the program file tts.exe to the devices \ windows directory and all of its supporting data files in the espeak-data directory to the devices \ directory. The tts,exe X86 executable files and supporting data files are available for download in a zip file 31. Some commercial versions of TTS software can provide more realistic human speech. Speech recognition or voice recognition is used to covert spoken words to a standard computer text file. Speaker independent recognition systems can be used to successfully recognize a limited vocabulary of a small number of words (i.e., numbers or digits). Many systems use speaker dependent speech samples as training data to improve recognition rates for each individual speaker. After training with sample speech data from the speaker, accuracy rates in the high ninety percent range can be achieved under ideal conditions. Ideal conditions would require a speaker that consistently matches the training data provided, and a low noise environment. There are commercial third party extensions and shared source projects 32 that can be used to add speech recognition support to Windows CE.
9.5 Adding Cell Phone Radio Technology with a Modem

Mobile devices and devices used in remote locations often require and utilize cell phone radio technology to place voice calls, send messages, transfer data, and even access the Internet. For example, a device might need to monitor sensors at a remote site and when preset limits are exceeded automatically send an alarm using a text messages. Many new high-end vending machines already send automatic notifications when they need service or restocking, so that drivers can schedule their time and service routes more efficiently. Coupled with GPS technology, mobile tracking devices such as those found in many commercial vehicles can also be developed. Cell phone radio technology can be added to projects on the eBox using the Enfora GSM/GPRS SA-GL 1218 modem shown atop the eBox in Figure 9.5. The Enfora modem contains a quad-band cell phone radio with support for
31 32
http://users.ece.gatech.edu/~hamblen/wemap/eBox4300/eBox_TTS_OCR/eBox_TTS_OCR.zip http://sourceforge.net/projects/cmusphinx/
303
voice, Short Message Service (SMS) messages and email, and high-speed EDGE data transfer capabilities. The modem attaches to any standard serial port running at 115K Baud. On the eBox, a regular 9-pin M/F PC serial cable is required (i.e., not a null modem cable like the serial cable provided with the eBox). A standard SIM card for an active account must be inserted into a slot in the front of the modem. For voice calls, a standard cell phone headset with a 2.5mm jack can be inserted into the modem (it does not provide support for voice calls through the audio I/O available on the eBox).
Figure 9.5 The Enfora SA-GL GSM1218 Cell Phone Modem attached to the eBox.
An LED on the front of the modem flashes when connecting to a GSM network, and then stays on once the device registers on a GSM network. During a network boot, the eBox sends some initial serial debug messages out on COM1: at 38400 Baud that could put the modem in an unknown state, so it is suggested that physical COM2: be used for the modem connection. The modem should be powered on as the OS starts to load and the power needs to be cycled on the modem whenever the eBox is turned on or reset. Like most modems, the standard AT command set is used to send and receive commands in ASCII for the modem over the serial port 33. Short Message Service (SMS) is a standard for sending and receiving short text messages of up to 160 characters to devices that use Global System for Mobile Communications (GSM). Messages can be textual (alphanumeric) or binary.
Enfora Enabler IIG GSM/GPRS Radio Modem AT Command Set Reference Manual (www.enfora.com)
33
304
SMS messages sent to a device that is not connected are held for a number of days, then sent when the device becomes active or comes back into range. SMS messages can be sent from mobile devices, or they can be sent from computers by means using some web-page based interfaces typically available on websites for cell phone service providers. For basic operations such as sending an SMS message, OS filesystem APIs for the serial port (as seen in earlier examples) could be used in an application to send commands directly to the modem34. For example, after the modem is properly configured, to send an SMS message the following command is sent from the computer at 115K Baud: AT+CMGS=18005551212 The modem responds with > And next the message text is then sent by the computer with: SMS Message text is here ^Z And finally the modem responds after a slight delay to acknowledge sending the SMS message with: +CMGS: number OK A similar command syntax that varies somewhat between the different cell phone service providers can also be used to send the SMS message text to an email account 35. Received SMS messages can also be read back to the computer over the serial link. With CE, the eBox, and the cell phone modem, prototypes of cell phone type devices can easily be developed as seen in Figure 9.6 Given the time delays inherent in the commands and their acknowledgements, more complex applications that require simultaneous send and receive operations will likely require multiple threads. Add timeouts, more advanced error checking, and provisions to handle voice calls, data, and text messages concurrently, and it gets complex enough that an OS device driver and Cell Phone related APIs would be extremely useful for any application developers. In CE 6.0, CellCore provides a basic set of wireless connection cell phone oriented services. The Radio Interface Layer (RIL) handles the communication between the CellCore system software and the radio hardware. Fortunately, Windows CE 6.0 includes a sample RIL PDD device driver for the Enfora SAGL GSM1218 modem. An environment variable in many BSPs (IMGENFORA 1) is used to add the Enfora driver during an OS build.
34
35
Application Note: Enabler Modems SMS Configuration and Use ( www.enfora.com ) Application Note: How to Send an SMS Message to an E-Mail Address ( www.enfora.com )
305
Figure 9.6 A GUI display from a student project that sends SMS test messages using the modem.
In the current eBox 4300 BSP (i.e., Rev. D), in addition to setting IMGENFORA 1 , two additional steps are required to manually place the Enfora device driver, Enfora.cpp , into the release directory by copying the CEPC version of the driver files and adding this new driver to the eBox OS bu ild process. 36. First, copy the entire CEPC Enfora driver RILPDD directory from \Wince600\Platform\CEPC\SRC\DRIVERS\RILPDD over to the eBox 4300 platform folder, \Wince600\Platform\ICOP_eBox4300_60DS\SRC\DRIVERS \RILPDD. Then edit and modify the DIRS file for your new DRIVERS folder, so that the new RILPDD directory gets built during a new eBox OS build by adding these lines: DIRS= \ # @CESYSGEN IF CELLCORE_MODULES_RIL rilpdd \ # @CESYSGEN ENDIF CELLCORE_MODULES_RIL In addition to adding the driver, several CellCore catalog items must be added to the OS project. In the SMS example that follows, all of the CellCore catalog items were added to the OS build with the exception of WAP and Wireless WAN.
Using CellCore with Windows Embedded CE 6.0, Windows Embedded Blog, http://blogs.msdn.com/mikehall/archive/2006/11/29/using-cellcore-with-windows-embedded-ce-60.aspx
36
306
In CE 6.0, SMS APIs including SmsOpen, SmsSendMessage, SmsReadMessage, and SmsClose are available for use in C/C++ applications to send and receive SMS messages. To use these SMS API functions in an application, it will need to be linked with sms.lib. When SMSOpen is used for read operations it can set an event flag to signal that a new SMS message is available to read. WaitForSingleObject can then be used to block a thread waiting on this event, before the SmsReadMessage SPI is called to read a message 37. A short code example for the modem, GSMSP, sends and receives and SMS message. GSMSP sends an SMS message to its own phone number to provide a simple SMS loopback test. In the following code, the main program sends an SMS message using SmsOpen and SmsSendMessage and a thread named ReadMessageThread waits using WaitForSingleObject for the incoming SMS message to return. It then reads the message using SmsReadMessage 38:
// GSMSP.cpp : Defines the entry point for the console application. // Program sends and recieves an SMS message to itself // Uses Enfora GSM1218 Modem with CE 6.0 RIL driver #include "stdafx.h" #include "sms.h" DWORD WINAPI ReadMessageThread (LPVOID lpArg); int _tmain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPTSTR lpCmdLine, int nCmdShow) { DWORD dwSize=0, dwRead=0; SMS_HANDLE smshHandle; SMS_ADDRESS smsaDestination; TEXT_PROVIDER_SPECIFIC_DATA tpsd; SMS_MESSAGE_ID smsmidMessageID = 0; HANDLE hThread; DWORD dwThread1ID = 0; INT nParameter = 1; TCHAR tcBuffer[1024]; memset(tcBuffer,0x00,1024); // SMS message text StringCchCopy(tcBuffer, 1024, L"Hello Cell World!"); printf("\n\rMain Thread - Starting SMS Send and Recieve Test\n\n"); printf("\n\rMain: Starting SMS Read Thread"); hThread = CreateThread(NULL,0,ReadMessageThread, (LPVOID)nParameter, 0, &dwThread1ID ); printf("\n\rMain: Trying to open SMS Handle for Send.........");
37 38
Programming Microsoft Windows CE.Net, Third Edition by Douglas Boling, Microsoft Press. CE 6.0 - Sending an SMS Message, Windows Embedded Blog, http://blogs.msdn.com/mikehall/archive/2007/04/08/ce-6-0-sending-an-sms-message.aspx
307
// try to open an SMS Handle for Send HRESULT hr = SmsOpen(SMS_MSGTYPE_TEXT, SMS_MODE_SEND, &smshHandle, NULL); if (hr != ERROR_SUCCESS) { printf ("\n\rMain: SmsOpen failed %x %d", hr, GetLastError()); Sleep(15000); return 0; } else { printf ("\n\rMain: Open Send SMS OK"); } // Create the destination phone address memset (&smsaDestination, 0, sizeof (smsaDestination)); smsaDestination.smsatAddressType = SMSAT_INTERNATIONAL; // Phone Number to send SMS to - Unicode String lstrcpy(smsaDestination.ptsAddress, TEXT("+14045551212")); // Set up provider specific data tpsd.dwMessageOptions = PS_MESSAGE_OPTION_NONE; tpsd.psMessageClass = PS_MESSAGE_CLASS1; tpsd.psReplaceOption = PSRO_NONE; wprintf(L"\n\rMain: Sending the SMS message to %s",smsaDestination.ptsAddress); wprintf(L"\n\rMain: Sending Message> %s",tcBuffer); // Send the SMS message, indicating success or failure HRESULT hr1 = SmsSendMessage (smshHandle, NULL, &smsaDestination, NULL, (PBYTE) tcBuffer, (lstrlen(tcBuffer)+1)*sizeof(TCHAR), (PBYTE) &tpsd, sizeof(TEXT_PROVIDER_SPECIFIC_DATA), SMSDE_OPTIMAL, SMS_OPTION_DELIVERY_NONE, &smsmidMessageID); if (hr1 == ERROR_SUCCESS){ printf("\n\rMain: SMS message was sent OK"); } else { printf ("\n\rMain: Error Send Message handle: %x Last Error %d", hr1,GetLastError()); } SmsClose (smshHandle); Sleep(100000); return 0; } // Receive SMS Thread DWORD ReadMessageThread (PVOID pArg){ SMS_HANDLE smshHandle; SMS_ADDRESS smsaDestination; TEXT_PROVIDER_SPECIFIC_DATA tpsd; SMS_MESSAGE_ID smsmidMessageID = 0; DWORD dwSize, dwRead=0; printf("\n\r Read Thread: Started SMS Read Operation"); HANDLE hRead = CreateEvent(NULL, FALSE, FALSE ,NULL); printf("\n\r Read Thread: Trying to open SMS Handle for Read........."); // try to open an SMS Handle for Read
308
HRESULT hr2 = SmsOpen(SMS_MSGTYPE_TEXT, SMS_MODE_RECEIVE, &smshHandle, &hRead); if (hr2 != ERROR_SUCCESS) { printf ("\n\r Read Thread: SmsOpen failed %x %d", hr2, GetLastError()); Sleep(15000); return 0; } printf ("\n\r Read Thread: Open Read SMS OK"); // Wait for SMS message to arrive and set event before reading printf("\r\n Read Thread: Waiting for new message to arrive....."); int rc = WaitForSingleObject (hRead, 500000); if (rc != WAIT_OBJECT_0){ printf("\n\r Read Thread: timed out waiting for incoming SMS\n\r"); SmsClose(smshHandle); Sleep(100000); return 0; } // Set up provider specific data memset(&tpsd,0,sizeof(tpsd)); // Get size of message for buffer setup HRESULT hr3 = SmsGetMessageSize( smshHandle, &dwSize); TCHAR *cBuffer = (TCHAR *)malloc (dwSize+1); printf("\n\r Read Thread: Reading the SMS message............"); // Read the message, indicating success or failure HRESULT hr4 = SmsReadMessage (smshHandle, NULL, &smsaDestination, NULL, (PBYTE) cBuffer, dwSize, (PBYTE) &tpsd, sizeof(TEXT_PROVIDER_SPECIFIC_DATA), &dwRead); if (hr4 == ERROR_SUCCESS){ printf("\n\r Read Thread: SMS message was received OK"); wprintf(L"\n\r Read Thread: Destination Address: %s",smsaDestination.ptsAddress); wprintf(L"\n\r Read Thread: Received Message> %s\n\r", cBuffer); } else { printf ("\n\r Read Thread: Error Receive Message handle: %x Last Error %d\n", hr3,GetLastError()); } free(cBuffer); SmsClose (smshHandle); Sleep(100000); return 0; }
The com port that the modem is attached to is specified by the GSMSP subproject with the following registry setting:
[HKEY_LOCAL_MACHINE\Software\Microsoft\GSM07_10] "ComPort"="COM2:" "BaudRate"=dword:1C200 ; 115200
"FrameOption"=dword:1
; Advanced
309
In recently produced Enfora modems, there appears to have been a firmware update that requires a minor change in the driver. After completing the steps outlined earlier to add the modem driver to the OS build, in the file, Enfora.cpp , change the line CSTAT=1 to CSTAT=0. This is an initialization command sent to the modem by CEs driver at power up. This turns off unsolicited SIM status messages from the modem that can lock up the RIL driver when handling SMS messages. This also serves as a prime example of why it is always desirable to have the source code available for device drivers. In a debug build, the timing is too slow for the modem. In a release build with KITL and debugging enabled, the RIL driver sends out the modem commands and shows the modems response in debug messages that appear in the output window in Visual Studio when the target device is connected. This is a handy way to verify that the modem is attached correctly and that the driver is working properly. A number of initialization AT commands are exchanged with the modem when the OS first boots. As a test, the program was set to send an SMS message to its own phone number (i.e., a simple loopback test). Here is an example of what happens after initialization, when an SMS message is sent by the program:
152759 PID:400002 TID:2aa0002 RilDrv: Sending cmd: AT+CMGS=28<cr> 152770 PID:400002 TID:2ac0002 RilDrv: Accumulated response: > <cr> 152771 PID:400002 TID:2aa0002 RilDrv: Sending cmd: 0001000B91414015 6464F7001011C8329BFD060DCB6C36E8FA96B3C921
A slightly different AT message send command is used by the OS driver. In this case, AT+CMGS=28, tells the modem the message length and the phone number is encoded into the first portion of the SMS message that follows in the long hex string. Once the message is sent the modem responds with:
156807 PID:400002 35<cr><lf>0<cr> TID:2ac0002 RilDrv: Accumulated response: +CMGS:
After a slight delay for the SMS message from the modem to be received by the cell phone provider and for the cell phone provider to send it back to the modem, it returns as:
157774 PID:400002 TID:2ac0002 RilDrv: Accumulated response: +CMT: ,34 <cr><lf>07912160130300F4040B914140156464F700108040523200246911C8329BFD0 60DCB6C36E8FA96B3C921<cr><lf>
So the modem and test program were able to successfully send and receive an SMS text message using the OS device driver. The message text can be found at the very end of the SMS message hex strings. A display of the console output produced by the GSMSP test program is seen in Figure 9.7. It shows the sequence of events by using a series of printf commands in both the main and read thread. To run GSMSP on your system,
310
you will need to change the phone number string to the number that is registered for the SIM card you inserted in the modem. Telephony APIs (TAPIs) manage phone connection and disconnection and are used for voice call setup and modem support. TAPI includes Unimodem, which supports AT command-based standard modems. Windows Mobile also adds an additional layer of API support and features for cell phone type devices such as the Smartphone, but these APIs are not available in Windows Embedded CE. The CeDialer sample program available in the Windows Mobile SDK contains an example using TAPI to dial a phone number.
Figure 9.7 Console output produced on the eBox by the GSMSP test program shows it sending and successfully receiving an SMS text message back using the modem and the SMS APIs.
9.6 Adding a small LCD touch panel display

In many embedded devices such as PDAs, cell phones, and controllers, a small touch screen display is often used. LCD touch panels are typically found in such devices. The touch screen needs a driver for the OS, so that it can function in a way very similar to a standard mouse. Large LCD touch screens the size of a typical desktop monitor are typically cost prohibitive, but in smaller sizes they can be a cost effective solution for many embedded devices.
311
In addition, since no keyboard many be present on such a device, support is needed for typing characters with a stylus and even perhaps automatic handwriting recognition. The touch location data is typically transferred over a serial or USB port back to the computer. It would be useful when prototyping such devices to have touch screen capability on the eBox. To use an LCD touch panel with the eBox it would need VGA input for the LCD panel, a serial or USB interface port to provide the touch location data, and OS drivers that read in the touch location data. One such device is the Xenarc 705TSV 7-inch LCD TFT Touchscreen monitor seen in Figure 9.839. This low-power device was designed primarily for use in in-car PCs. It uses white light LEDs for the backlight on the LCD panel.
Figure 9.8 A small low-cost Xenarc LCD touch panel display is shown mounted on the eBox.
The touch panel interface uses USB, and a free X86 touch input device driver for CE 6.0 is provided with the display. In any OS, the source code for many third party device drivers is often not available since manufacturers may view such source code as important proprietary IP. In these cases, double check that the device driver is available in the correct binary code version for the target devices processor (in CE it could be X86, ARM , SHx, or MIPS). The eBox of course, will require an X86 version of the driver binary code for which the source code is not available. ARM only versions of CE drivers and applications
39
Xenarc Technologies, www.xenarc.com
312
are quite common because of their use in the popular Smartphone and PocketPC consumer devices. The panel is very lightweight and when touching the panel it tends to move, unless the LCD mounts base is attached to something a bit more secure. The monitor shown in Figure 9.8 attaches to a plastic plate mounted on spacers above the eBox. Screws attach the plastic plate using the four Video Electronics Standards Association (VESA) mounting holes already present in the eBox case. Spacers are used between the eBox and plastic plate so that there is still sufficient air flow for cooling over the black heatsink surface o n the top of the eBox. To help setup the touch screen driver and to make the necessary additions to the registry for the driver, the TouchKit subproject was developed 40. It works in a similar way to the earlier PhidgetsDrivers and WebCam subprojects. It does not compile code, but during an OS build it adds the driver to the kernel using its *.bib file and adds the new registry settings using a *.reg file. A postlink.bat file copies the necessary driver file to the OS release directory for use by the *.bib file. Once touch technology is available, there are additional catalog items in CE 6.0 that can be added to the OS that support a stylus, a touch panel keyboard, and even an automatic handwriting recognition system. First, the Touch Screen (Stylus) catalog item adds support for a stylus. In many applications, the user interacts with an application by using a stylus and a touch screen. The stylus and the touch screen provide a direct and intuitive alternative to a mouse. The stylus generates an input event when the user touches the screen with a stylus or when the user moves the stylus when the tip is touching the screen. When the user presses and releases the stylus on the screen, the application processes these events as a click of the left mouse button. When the user moves the stylus across the screen, the application processes this action as a movement of a mouse. The Software-based input panel (SIP) seen in Figure 9.9 is a catalog item that allows a touch screen to simulate keyboard input. Once SIP is added, a small stylus icon appears in the lower right corner of the display. Click on the icon to activate or hide the touch keyboard. In CE 6.0 for English, French, and German, the Transc riber Handwriting Recognition Application catalog item can be added to a device. It allows a user to provide a second form of input by writing on a touch screen. As an alternative, the Handwriting Recognizer Engine (HWX) for CE provides a handwriting recognition engine that supports user-drawn ideographs and characters. The handwriting recognition engine supports several languages. Unfortunately, the current touch panel driver does not include all of the features needed for CEs automatic handwriting recognition systems.
40
The Touchkit subproject was initially developed as a student project by Kyle Keppler.
313
Figure 9.9 Using the software-based input panel (SIP) with a touch stylus to type in text.
9.7 Adding a GPS Receiver for Location Information

For location information, many mobile devices rely on the Global Positioning System (GPS). GPS navigation units are found in vehicles, aircraft, and boats, newer cell phones, vehicle tracking systems, surveying systems, and outdoor robots including autonomous vehicles. GPS uses a constellation of 24 satellites that transmit microwave signals. Each satellite has a highly accurate atomic clock. Using the precision timing signal from several satellites (at least four), a GPS receiver can determine its location, altitude, speed, direction and the time. The GPS receiver uses the signal arrival time from each satellite to calculate its distance from the satellite. Using the exact distance from each satellite, it determines its position using geometry and trigonometry. New GPS receivers are more sensitive, but GPS signals are still not reliable inside large buildings or dense urban canyon areas with large buildings due to signal degradation. Basic GPS measurements are typically accurate to within a few meters. Other satellite (WAAS) and ground-based signals (Differential GPS) can be used with in conjunction with GPS to obtain higher accuracy. Small low-cost single chip GPS receivers are available that can be added to a device. Often they are surface mount soldered directly to the devices main printed circuit board. To add external GPS capability to the eBox, there are
314
several hardware interface options, serial, USB, and Bluetooth. Bluetooth GPS units would require a USB to Bluetooth adapter with a CE 6.0 driver. This approach can be used but is more expensive than the other options. Since GPS USB drivers are not readily available for CE 6.0 X86 systems at t he current time, the serial units are easier to use. Many of the GPS USB-based operate as a virtual com port, so a driver could be developed using that approach. The serial GPS devices will not require a new driver, since the normal OS file system APIs can be used to set the baud rate and transfer data over the serial port.
Figure 9.10 A GlobalSat BR-355 GPS receiver with an RS232 serial interface 41. Power needed for the device is provided using a PS/2 connector without data connections. The special serial cable adapter used is not shown. Photograph courtesy of USGlobalSat.
The GPS serial unit shown in Figure 9.10 draws its 5V 80mA power by using a PS/2 connector and transfers the data using an RS232 serial connector. No data is transferred on the PS/2 connector it only serves to provide a power source. So this unit can plug directly into the eBox, but if both a mouse and keyboard is used an additional PS2 Y cable will be required for the GPSs PS/2 power only connection.
41
For more information see http://www.usglobalsat.com or http://www.globalsat.com.tw
315
Most GPS receivers periodically transfer ASCII data to the host computer using the National Marine Electronics Association (NMEA) data format (www.nmea.org). A short NMEA data sample follows:
$GPGSV,3,3,12,12,18,215,18,04,08,092,,21,06,286,,18,01,233,*7B $GPRMC,140233.000,A,3355.6908,N,08419.2488,W,0.26,86.73,220408,,*21 $GPGGA,140234.000,3355.6907,N,08419.2490,W,1,05,1.5,277.5,M,-30.9,M,,0000*6C $GPGSA,A,3,12,26,29,10,24,,,,,,,,1.8,1.5,1.0*35 $GPRMC,140234.000,A,3355.6907,N,08419.2490,W,0.03,220.64,220408,,*1F $GPGGA,140235.000,3355.6903,N,08419.2493,W,1,05,1.5,278.3,M,-30.9,M,,0000*63
The time and GPS position data appears in the lines that start with $GPGGA, so a simple string comparison can be used in a program to recognize and capture this data. Several other lines that contain other information also are sent out. A sample line that contains GPS fix data in NMEA 2.0 format is shown below:
$GPGGA,113419,4807.038,N,01131.000,E,1,08,0.9,545.4,M,46.9,M,,*XX
The meaning of each field in this sample line is described in Table 8.4. On serial GPS devices, 4800 Baud with no handshaking is typically used for streaming out the NMEA data to the host processor. Applications running on a device that need location information can read in the GPS data directly, but when multiple applications need GPS data at the same time it becomes a more complex issue. In such cases, OS support with a standard set of GPS related APIs would be helpful for developers. Such support is provided in CE using the GPS Intermediate driver. Using the GPS Intermediate Driver APIs, application developers can write code that works on any GPS hardware and device manufacturers can produce hardware that works with any application by providing a low-level hardware driver that supports the GPS Intermediate driver. Table 8.4 Interpreting a NEMA GPS Data Fix Line $GPGGA,113419,4807.038,N,01131.000,E,1,08,0.9,545.4,M,46.9,M,,* XX Field Meaning $GPGGA Global Positioning System Fix Data Follows 113419 Fix taken at 11:34:19 UTC 4807.038,N Latitude 48 deg 07.038' N 01131.000,E Longitude 11 degrees, 31 E 1 Fix quality: 0 = invalid, 1 = GPS fix (SPS) 08 Number of satellites tracked 0.9 Horizontal dilution of position 545.4,M Altitude, Meters, above mean sea level 46.9,M Geoidal separation *XX Checksum Data Value
316
The GPS Intermediate driver does not interact with hardware directly, but it can be setup to handle serial GPS devices using file system APIs to communicate with the serial port. A registry setting needs to be modified as follows for a GPS unit attached to COM1: [HKEY_LOCAL_MACHINE\System\CurrentControlSet\GPS Intermediate Driver\Drivers] "CurrentDriver" = "AcmeGPSHardware" [HKEY_LOCAL_MACHINE\System\CurrentControlSet\GPS Intermediate Driver\Drivers\AcmeGPSHardware] "InterfaceType" = "COMM" "FriendlyName" = "GlobalSat GPS BR-355" "CommPort" = "COM1:" The GPS Intermediate Driver catalog item must be added to the OS build. CE GPS APIs available include GPSOpenDevice , GPSCloseDevice , GPSGetPosition , and GPSGetDeviceState . The C/C++ subproject, GPSdemo sets up the registry and has a simple console application that prints out location data from the GPS. The GPS_POSITION structure contains all of the GSP data information such as location, altitude, heading, speed, time, and satellites used. Here is the GPSdemo console application C/C++ code:
// GPSdemo.cpp : Defines the entry point for the console application. // Displays GPS data from GlobalSat BR-355 attached to COM1: // LED on GPS blinks when it has a fix // A fix can take a couple minutes at cold power up // Requires GPS Intermediate Driver Catalog Item in OS build // Registry settings are included in subproject reg file // links with gpsapi.lib #include "stdafx.h" #include <gpsapi.h> int _tmain(int argc, TCHAR *argv[], TCHAR *envp[]) { HANDLE g_hGPSDevice; GPS_POSITION GPSPosition; DWORD i=0; // Print Header on Console _tprintf(_T(" Hello GPS World!\n\r")); // Open GPS Device g_hGPSDevice = GPSOpenDevice(NULL, NULL, NULL, 0); if (g_hGPSDevice == NULL) printf("\n\r GPS device failed to open"); // Setup required for initial data in GPS Position Structure GPSPosition.dwVersion = GPS_VERSION_1; GPSPosition.dwSize = sizeof(GPS_POSITION); printf("\n\r Waiting for initial GPS fix");

// Wait a bit for GPS Open to initialize GPS device do { Sleep(2000);
317
// Read GPS Position and repeat until GPS has an initial fix DWORD result = GPSGetPosition(g_hGPSDevice, &GPSPosition, 10000, 0); printf("."); } while ((GPSPosition.dwValidFields & GPS_VALID_LATITUDE) == 0); printf("\n\r UTC Time %2d:%2d:%2d", GPSPosition.stUTCTime.wHour, GPSPosition.stUTCTime.wMinute,GPSPosition.stUTCTime.wSecond); printf(" Heading = %f",GPSPosition.flHeading); printf(" Altitude = %f",GPSPosition.flAltitudeWRTSeaLevel); // Take more GPS readings in a loop and display valid location data for (i=0; i<50; i++){ DWORD result = GPSGetPosition(g_hGPSDevice, &GPSPosition, 10000, 0); if((GPSPosition.dwValidFields & GPS_VALID_LATITUDE) != 0) { printf("\n\r%2d Satellites in Fix, ", GPSPosition.dwSatelliteCount); printf("Latitude = %8.4f, ",GPSPosition.dblLatitude); printf("Longitude = %8.4f, ",GPSPosition.dblLongitude); printf("Speed = %6.1f",GPSPosition.flSpeed); } Sleep(2000); } // Close GPS Device GPSCloseDevice(g_hGPSDevice); return 0; }
Running GPSdemo with a GPS device attached to COM1: and the OS properly configured, the console displays GPS location data as seen in Figure 9.11. A cold boot of a GPS receiver may require a couple minutes before it locks into the required number of satellites and gets an initial fix. Deep inside a large building you might be able to get a fix due to signa l loss. When the GlobalSat BR-355 GPS locks in on a fix, the LED on the unit starts flashing. The GPSdemo application prints out location data, delays two seconds and repeats several times. On low power devices, the GPS hardware will typically need to be cycled off between readings to reduce power consumption. The simple GPSdemo application just periodically polls for the location data, but the GPS APIs can also be used to trigger an event whenever a new reading is available. A similar setup should work for any serial GPS units that send out NMEA data strings, but a different cable setup may be needed to provide power to the GPS receiver module. Most serial GPS devices default to 4800 Baud. If not, there is also a registry setting that can be used to change the GPS COM port baud rate.
318
Figure 9.11 A The GPSdemo applications console display output. It is reading in GPS location data using CEs GPS APIs and a serial GPS attached to COM1:. Note that the number of Satellites will vary and overall accuracy is limited to several meters. In the US, additional WAAS satellites are available that provide a bit more accuracy for a WAAS enabled GPS .
For C# (managed code) applications that need GPS location data, the Windows Mobile SDK includes a code sample named GPS. The GPS code sample wraps the native (C/C++) GPS APIs in a C# class using a special interface called PInvoke. PInvoke was discussed at the end of the previous Chapter.
9.8 Adding OCR Technology

Optical character recognition (OCR) software is found in some embedded devices. OCR is the electronic conversion of images of text (captured by a scanner or camera) to a standard computer text file. The post office uses OCR technology to help sort letters and banks use it to process checks with special magnetic ink at the bottom of the check. Reading systems for the blind were among the first applications of OCR technology. These systems utilize a scanner or camera to capture text images, and OCR followed by text to speech synthesis to produce audio output. Today, even cell phones with cameras can use OCR to read in business cards and other documents. The recognition of typewritten characters using standard typewritten fonts is a well understood problem, but work still continues to achieve lower error rates. Very high levels
319
of accuracy can be obtained with typewritten text, but human editing is often still needed to correct the remaining errors. There are third party commercial solutions available at additional cost for Windows CE that add support for OCR. For student projects, an open source OCR project, GOCR 42, can be used to add OCR support to a device. It has been ported as a student project to run on Windows CE and the eBox 43. High quality commercial OCR software currently has better error recognition rates than the current open source OCR software, but GOCR can still be used to successfully demonstrate OCR technology.
Figure 9.12 This bitmap image file of typewritten text is used as input test data for the optical character recognition (OCR) program.
The OCR executable file, ocr.exe, needs to be copied to the devices \windows directory and a test bitmap image file is needed 44. A sample test image is seen in Figure 9.12. Running ocr at the CE command line prompt with the following arguments: \> ocr i sample-image.pnm o ocr-output.txt
42 43
http://jocr.sourceforge.net/ http://users.ece.gatech.edu/~hamblen/489X/S08PROJ/OCR_TTS/ 44 http://users.ece.gatech.edu/~hamblen/wemap/eBox4300/eBox_TTS_OCR/eBox_TTS_OCR.zip
320
uses the bitmap image file, sample-image.pnm, seen in Figure 9.12 as input test data. It produces the following ocr-output.txt file output without any errors, after a couple seconds of computations: This text should be read by our optical character recognition program. What is the result of this image? Hello world? Character recognition rates in the high ninety percent range are common for OCR programs with high-quality images in (300-600 DPI) using the common 10-12 pt. typewritten fonts. Many modern OCR programs can also capture formatting information. A serif is the small curly feature seen at the end of strokes in many fonts such as the times new roman character font used here. For OCR, sans-serif (i.e., without serifs) fonts tend to produce more accurate results. Fonts that slant and run characters together like italics tend to have higher error rates. It is also very sensitive to the spacing between characters. Image noise levels and lower resolutions also increase the error rates in OCR programs. In the bitmap text image, characters will typically need to be at least 20-60 pixels high for successful recognition.
This text should be read by our optical character recognition program. at is the result of this image? Hello world?
Figure 9.13 The image on the left was captured using a web camera attached to the eBox. The text on the right shows the text output produced by the OCR program.
As a more thorough technology demonstration, the test image provided with Gocr seen earlier in Figure 9.12 was printed out and captured with the Camtest2 application previously described in this chapter using a Logitech web camera attached to the eBox. The original test image is 1024 by 768. Camera image capture size was 640 by 480 and the image was compressed as a *.jpg
321
file that was converted later to *.pnm bitmap for use by the OCR program. In this test, the resulting character recognition rate was in the mid ninety percent range. Only t he Wh in What was not recognized correctly, probably as a result of the two characters appearing to touch and merge into one. Since the image was down sampled, spatially distorted due to minor camera and image plane misalignment (i.e., notice that characters on right side of the image increase slightly in size), and noise added from the camera electronics and image file compression, one would expect a higher error rate than the original perfect test image. This also shows the typical character pixel resolution needed in text images. To capture significantly more lines of text in a single image, a higher pixel resolution camera would be required. The default stack size for the ocr.exe process had to be increased in the Windows CE port since it uses recursive algorithms and puts quite a lot of data on the stack. When receiving runtime stack warnings from a process in CE, a processs stack size can be adjusted from the default values by changing the projects property settings, by using a stack entry the projects *. def file, or even after compilation using the editbin programs /Stack:size option in a build command line window. Computer recognition of handwriting is a somewhat different problem than OCR. In automatic handwriting analyzers like the one included in Windows CE that uses touch screen input, additional information on how the character is actually written or drawn using a sequence of strokes is used to obtain more accurate character recognition rates.
9.9 Building a Mobile Robot Project using CE and the eBox

Robots are a rapidly growing and important area in embedded systems. Robots are typically controlled by one or more embedded computers. The eBox running the CE RTOS makes an ideal computer platform to control a small robot. Mounting the eBox on a commercial robot base (i.e., a platform with drive motors and a battery) is a simple and quick way to develop robotics projects using the eBox and Windows CE. A large R/C toy or hobbyist vehicle can also serve as a robot base with some additional interface electronics 45. Developing a custom base from scratch on your own requires significant time and effort in the mechanical design aspects, obtaining, and fabricating all of the required parts, batteries, motors, and drive electronics. Assuming that the primary goal of such a project is to focus most of time and effort on the electronics and software design aspects of the robot, using a commercial robot base is the usually the more appropriate choice. This is especially true for student projects where time is limited. There are a number of excellent low-cost robot base options currently available and they can be reused for a number of different projects. Two low-cost commercial robot bases 46 that work well in such projects are seen in Figure 9.14. The robot on the left is the iRobot Create that is based on parts
45 46
More details in Rapid Prototyping of Digital Systems SoPC Edition, by J. Hamblen. Details on these robots can be found at http://www.irobot.com and http://www.roboticsconnection.com
322
originally developed for the popular Roomba robotic vacuum cleaner. The robot on the right is Robotics Connections Stinger kit . Assuming that an independent autonomous mobile robot project is the goal, the eBox can be mounted on these robots and powered by their batteries using a 5V regulator setup as previously described in Chapter 5. Other robot kits can also be used as long as they are large enough to carry the eBox easily and any extra batteries and sensors that may be required. Typically, this would require a robot around one foot in size or larger.
Figure 9.14 The iRobot Create robot is seen on the left and the Robotics Connection Stinger robot is seen on the right. Both robots are controlled by the eBox running Windows CE. Photographs Courtesy of Microsoft and Robotics Connection.
Most small mobile robots contain a variety of sensors and use two diametrically mounted reversible DC drive motors for movement. A low-cost microcontroller is often used to control the motor H-bridge driver circuits using PWM signals and to collect and assemble the low-level sensor data. A low-cost microcontroller can actually cost less than a single drive motor or sensor. This frees up significant time for the main computers more expensive and power hungry processor to concentrate on combining or fusing data from various sensors and making higher-level decisions, so it typically makes economic sense to offload these low-level motor and sensor tasks to a microcontroller. This also reduces the real-time response demands on the processor and OS. Both robots seen in Figure 9.14 use this microcontroller-based approach for their built-in sensors and motor controls. These robots have a microcontroller in the base that sends and receives serial data packets. The main computer sends out high-level motor commands on the serial port to the microcontroller, and it reads back packets that contain collected sensor data generated by the microcontroller.
323
The electronics setup for the Stinger robot is seen in Figure 9.15. The microcontroller board seen in the center is surrounded by the drive motors and an assortment of sensors. Starting in the upper left corner, the two DC drive motors for the wheels are seen. In most cases, a DC motor will require gear speed reduction to provide the higher torque and slower speed needed for wheel movement. The gear reduction unit is seen attached to the front of each motor. These connect to a 4 Amp H-bridge drive circuit on the microcontroller board. Moving clockwise, the optical wheel encoders are seen next. These provide feedback on the exact movement of the wheels to help provide more accurate measurements on wheel movement.
Figure 9.15 The hardware used in the Stinger robot is shown in this photograph. The microcontroller is seen in the center and is surrounded by two drive motors and an assortment of various sensors commonly found in small robots. Photograph Courtesy of Robotics Connection.
Next is a solid state camera with an R/C servo controlled pan and tilt camera mount. The camera is used to provide vision. The camera contains its own small microcontroller with firmware that can tack colored objects and download images to the microcontroller.
324
Moving clockwise again, there are several Sonar sensors to measure the distance to the closet object and a heat sensor. Multiple Sonars are often used on a single robot, but each is mounted facing out at a different angle. The Sonars beam width is typically less than eighty degrees and the range is limited to several feet. Each Sonar sensor has an onboard microcontroller. These sensors connect to an I 2 C interface on the microcontroller board. Moving clockwise again in Figure 9.15, several identical IR distance sensors are seen. Just like the Sonar sensors they are mounted facing out in different directions. Mechanical bump switches are often used as the last line of defense to detect when the robot hits an object. Solid State cameras can be used to detect and locate objects. Combining data from multiple types of distance sensor technologies in a robot increases the reliability of detecting all of the various types of objects and conditions that might be encountered. At the top of the microcontroller board is a serial port that is used to connect to the main computer board that is controlling the robot. For remote control of a robot, wireless networking such as WiFi or Bluetooth is often used. The microcontroller accepts motor drive commands on the serial port and sends out packets of sensor data on the serial port. The iRobot Create robot also contains a microcontroller that controls two drive motors and a similar assortment of built-in sensors. Controlling the robot base on such devices requires code on the main control computer that sends motor commands out on the serial port, and periodically reads in packets of sensor data coming in on the serial port. Such an application program to demonstrate manual remote control of the Create robot using CE and the eBox will now be developed. The firmware on the microcontroller inside the Create robot uses a set of standard commands that are fully defined and explained in the robots documentation 47. To provide more bandwidth on serial port transfers, all commands and sensor packets are sent in binary (i.e., not ASCII or Unicode). The default setup on the Creates serial port is 57,600 baud, no parity, 8 data bits, and no handshaking. A long serial cable is provided with the Create robot that can plug directly into o ne of the eBoxs serial connectors. The remote control program developed here can be run using only this cable. The eBox does not need to be mounted on and powered by the Create robot base to run the remote control demonstration program. To remotely control the robot, an easy to understand GUI would be highly desirable. Designing a GUI using C#s graphical design tools is much easier and quicker than C/C++. Since the real-time constraints are relaxed somewhat by the robots internal microcontroller and plen ty of memory is available, C# will be used to develop the remote control application. The primary goal of the remote control program is to be able to move the robot around and monitor the sensor data. The CreateRemote projects GUI is seen in Figure 9.16. It combines two important concepts seen in the earlier C# sample programs,
47
iRobot Create Open Interface Specification Manual available at www.irobot.com and Hacking Roomba: Extreme Tech by T. Kurt.
325
Buttons and serial port operations. Buttons are used for the basic control operations and each Button click event sends out commands on the serial port to the robot. A slider bar control is used to set the speed of the motors. Moving at a slower speed gives the user more time to respond with corrective input. Even on these small battery powered robots, at full speed they can be difficult to control. Some robots can also be damaged, if they strike a hard object at full speed. A checkbox is used to visually indicate the status of several sensors. A check in the box means the sensor is active. As seen in Figure 9.16, the Bump Left check box is activated to indicate that the left front bumper switch is active on the robot indicating that it has come in contact with an object.
Figure 9.16 This C# GUI was designed to remotely control the iRobot Create robot using the eBox.
CreateRemote contains the following C# code:

// Create Remote Control GUI for eBox attached to a iRobot Create Robot // can drive robot, play song, return to charger, and view sensors // using System; using System.Collections.Generic; using System.ComponentModel;
326
using using using using using using using

System.Data; System.Drawing; System.Text; System.IO; System.IO.Ports; System.Windows.Forms; System.Threading;
namespace CreateRemote { #region Enumerations // Definitions of iRobot Create OpenInterface Command Numbers // See the Create OpenInterface manual for a complete list public enum Commands { // Create Command // Arguments Start = 128, SafeMode = 131, FullMode = 132, Drive = 137, // 4: [Vel. Hi][Vel Low][Rad. Hi][Rad. Low] DriveDirect = 145, // 4: [Right Hi][Right Low][Left Hi][Left Low] Sensors = 142, // 1: Sensor Packet ID CoverandDock = 143,// 1: Return to Charger Demo = 136, // 2: Run Demo x Song = 140, // Download Song Notes - up to 16 notes PlaySong = 141, // 2: Play Song number x LED = 139, // 3: LED output control Stream = 148, // x+1: [# of packets]IDs of packets to stream QueryList = 149, // x+1: [# of packets] IDs of requested packets StreamPause = 150, // 1: 0 = stop stream, 1 = start stream } /* iRobot Create Sensor Packet IDs */ public enum Sensors { BumpsandDrops = 7, Distance = 19, Angle = 20, } #endregion Enumerations public partial class Form1 : Form { public SerialPort port; public Int16 left = 50; public Int16 right = 50; public byte Color = 0; private bool ProcessingSensorDataPacket = false; public bool raw_sensor_debug = false; public volatile short bumpandrop_data = 0; public Form1() { InitializeComponent(); // Serial Port Open Code - used to communicate with iRobot Create robot port = new SerialPort("COM1",57600,Parity.None,8,StopBits.One); port.Handshake = Handshake.None; port.ReadTimeout = 60000; port.WriteTimeout = 60000;

try // Just in case .NET CF not updated { port.Open(); } catch (Exception com_open_except) { } }
327
// Start Button - send start and safe mode, start streaming sensor data private void button5_Click(object sender, EventArgs e) { port.Write(new byte[] { (byte)Commands.Start, (byte)Commands.SafeMode }, 0, 2); Thread.Sleep(100); port.Write(new byte[] { (byte)Commands.Stream, 1, (byte)Sensors.BumpsandDrops}, 0, 3); Thread.Sleep(200); port.DataReceived += new SerialDataReceivedEventHandler(port_DataReceived); } // Stop Button - turn off drive motors private void button6_Click(object sender, EventArgs e) { port.Write(new byte[] { (byte)Commands.DriveDirect, (byte)0, (byte)0, (byte)0, (byte)0 }, 0, 5); } // Forward Button - turn on drive motors private void button1_Click(object sender, EventArgs e) { port.Write(new byte[] { (byte)Commands.DriveDirect, (byte)(right >> 8), (byte)right, (byte)(left >> 8), (byte)left }, 0, 5); } // Reverse Button - reverse drive motors private void button4_Click(object sender, EventArgs e) { port.Write(new byte[] { (byte)Commands.DriveDirect, (byte)(-right >> 8), (byte)-right, (byte)(-left >> 8), (byte)-left }, 0, 5); } // Left Button - drive motors set to rotate to left private void button3_Click(object sender, EventArgs e) { port.Write(new byte[] { (byte)Commands.DriveDirect, (byte)(right >> 8), (byte)right, (byte)(-left >> 8), (byte)-left }, 0, 5); } // Right Button - drive motors set to rotate to right private void button2_Click(object sender, EventArgs e) { port.Write(new byte[] { (byte)Commands.DriveDirect, (byte)(-right >> 8), (byte)-right, (byte)(left >> 8), (byte)left }, 0, 5); } // Charger Button - return to charger using IR beacons private void button7_Click(object sender, EventArgs e) {
328
//
//
//
// //
port.Write(new byte[] { (byte)Commands.Demo, (byte) 1}, 0, 2); } Play Song Button - define and play a song on robot private void button8_Click(object sender, EventArgs e) { // Send out notes & duration to define song and play song port.Write(new byte[] { (byte)Commands.Song, 0, 16, 91, 24, 89, 12, 87, 36, 87, 24, 89, 12, 91, 24, 91, 12, 91, 12, 89, 12, 87, 12, 89, 12, 91, 12, 89, 12, 87, 24, 86, 12, 87, 48 }, 0, 35); Thread.Sleep(100); port.Write(new byte[]{(byte)Commands.PlaySong, (byte)0 },0,2); } Slider trackbar to set motor speed private void Speed(object sender, EventArgs e) { left = (Int16) trackBar1.Value; right = (Int16) trackBar1.Value; } Checks for Proper Checksum at end of Sensor Data Packet bool validData(byte[] buf, byte chksum) { foreach (byte b in buf) chksum += b; if (chksum != 0) { return false; } else return true; } Event activated whenever new serial data is recieved packets are sent every 15 MS void port_DataReceived(object sender, SerialDataReceivedEventArgs e) { if (ProcessingSensorDataPacket) return; { ProcessingSensorDataPacket = true; try { // align with sensor packet header value and read in data while (port.ReadByte() != 19) { } byte[] buf = new byte[port.ReadByte()]; port.Read(buf, 0, buf.Length); // grab final checksum, validate checksum, and update sensor data if (validData(buf, (byte)(port.ReadByte()+ (buf.Length + 19)))) { // Display raw sensor data on console for debug? if (raw_sensor_debug) { foreach (byte b in buf) Console.Write(b + " "); Console.WriteLine(); }; // Checksum OK - so save new sensor data in packet bumpandrop_data = buf[1]; } } catch (TimeoutException) {

Console.WriteLine("Serial port Read timed out?"); } catch { } ProcessingSensorDataPacket = false; // //
329
//
// //
} } Update Sensor Display - timer executes this every 300 MS private void timer1_Tick(object sender, EventArgs e) { Flash through different colors on LED to indicate program is running Color += 64; port.Write(new byte[] { (byte)Commands.LED, 0, Color, 200 }, 0, 4); mask off sensor bits & Update Sensor Check Boxes on GUI checkBox1.Checked = (bumpandrop_data & 1) == 1; checkBox1.Update(); checkBox3.Checked = (bumpandrop_data & 2) == 2; checkBox3.Update(); checkBox4.Checked = (bumpandrop_data & 4) == 4; checkBox4.Update(); checkBox5.Checked = (bumpandrop_data & 8) == 8; checkBox5.Update(); checkBox6.Checked = (bumpandrop_data & 16) == 16; checkBox6.Update(); } Checkbox to display raw sensor data on console for debug delays response a bit - data backs up in buffers when on private void checkBox2_CheckStateChanged(object sender, EventArgs e) { raw_sensor_debug = checkBox2.Checked; } }
The CreateRemote program code will now be explained. The enumeration section defines the binary values used in the serial commands and other serial data packets on the Create robot. The first operation needed is to open the serial port with the correct baud rate and communication settings when the program first initializes using port.Open. The Start button sends out a required start and set mode command to the robot using port.Write. Port.Write writes a string of bytes to the serial port. The robot will not respond to other commands until these two initialization commands are received. This is common on many robot controllers as a safety feature. As an additional safety feature, many robots will also shut down automatically if a new command is not sent within a fixed time period. After start and set mode command, a command is sent to select the sensor packets for transfer and to start continuously sending (i.e., streaming) sensor data packets from the robot. A large number of different sensor data packets are available from the robot, but only the most basic one is used here. Sensor packets are sent out on demand
330
or continuously streamed at 15 Ms intervals. In this program, the sensor packets are set to continuously stream. The Forward, Left, Right, Reverse, and Stop buttons each send out the appropriate movement commands for the drive motors using port.Write. For left and right turns, the two drive motors move in opposite directions and the robot rotates in place. The robot moves it the same direction until another button is hit. Using different speed settings for each motor, it is also possible to move in arcs, but this is not supported in this simple GUI control demo. In each of the direction commands, the current Speed setting from the speed trackbar is used. A trackbar works very similar to a button and an event is generated whenever the bar is moved by the user. This event is used to set the speed for the left and right motors that is stored in the variables left and right. The Charger button sends a command to the Create robot to automatically search for and return to its battery charging station. The Create charger has two IR transmitter beacons that are sent out at different angles. These two IR sig nals can be used by the Create robots IR receiver to locate and vector in on the charger so that it automatically docks with the charger. The Song button downloads a song to the Create and then sends a command to play the song. On the Create, song data consists of a series of musical notes and the duration of each note. Each time a character is received on the serial port, port_DataReceived activates. Sensor packets are streamed out every 15 ms with no handshaking. If it is already in the process of reading in a sensor data packet, port_DataReceived immediately returns. When a new packet is initially starting, it checks for the proper data value in the sensor header. Once the header value is found, the next byte indicates the length of the sensor packet being sent. The length is used to read in the remaining bytes and the final checksum byte into a buffer, buf . Since there is no hardware synchronization of sensor data packets, it is possible that a data value could have the same value as the sensor packet header, so it is a good idea to check the final checksum for the proper value. ValidData computes a checksum based on the data in buf and compares it with the final checksum byte. If the checksum is not correct, the new data is ignored. As a debugging aid, the sensor data packets can be displayed on the eBox console as seen in Figure 9.17 by enabling the Display Raw Sensor Packets checkbox. Continuously printing out all of the sensor data tends to eventually slow down the sensor response times since data accumulates in the receive data buffers, so it is turned off by default. Finally, when the checksum is correct the new sensor data is saved in the variable bumpandrop_data and port_DataReceived returns. The C# timer feature is used in timer1_Tick to update the GUI sensor status checkboxes and to periodically blink the LED on the Create robot. The timer is set to run every 300 Ms. It is appealing to flash LEDs, but in this case it also provides a useful visible indication on the Create robot that the CreateRemote program is alive and running. First in the timer event code, an LED command
331
is sent that cycles through the different colors on the Creates multicolor power LED.
Figure 9.17 For debug purposes, checking Display Raw Sensor Packets in the CreateRemote GUI will display incoming robot sensor data packets on the eBox s console window.
Next, using the sensor bits found in the variable bumpandrop_data the appropriate checkboxes in the GUI are updated. Using .Update () forces each checkbox to update a bit quicker than the default periodic redraw update for the entire GUI. Other devices such as the web camera, Phidgets modules with new types of sensors including Sonar and IR, wireless support, cell phone modem, and speech synthesis and recognition technology could also be added to a small robot. GPS is also commonly used for navigation in larger robots that operate outdoors. Using CreateRemote as a starting point or as an alternative the .NET support libraries already available for the Stinger robot, an almost unlimited number of interesting autonomous robot projects can be developed as seen in the three student projects in Figures 9.18 and 9.19. In an autonomous robot, the robot would constantly read in new sensor data and process this sensor data to make high-level decisions on how to move the robot and operate in its environment to perform some desired task. WiFi allows the robot to communicate with other devices such as a desktop PC.
332
Figure 9.18 Two student design projects are seen above that were built using CE, the eBox, and the Create robot. They also contain a number of other devices including a web camera, WiFi, GPS, electronic compass, Phidgets USB modules with IR distance sensors, Sonar, and small R/C servos that are used to rotate sensors independent of the robots orientation.
Figure 9.19 The Printbot student project seen above was built using CE, the eBox, and the Create robot. It prints bitmaps on the floor using talcum powder. Parts from an old inkjet printer were used. A PSoC microcontroller with motor driver circuits uses PWM to control the two DC motors on the printing mechanism. The PSoC microcontroller responds to commands from the eBox serial port.
333

Phidgets C/C++ API manuals and additional documentation on the different devices is available at www.phidgets.com The textbook, Programming Microsoft Windows CE.Net, Third Edition by Douglas Boling published by Microsoft Press contains additional details on developing C/C++ Windows Embedded CE application programs. Chapter 23 contains a brief introduction to C#. It also includes additional code examples to send and receive SMS messages. The textbook, Programming Microsoft Windows Embedded CE 6.0 , Fourth Edition by Douglas Boling published by Microsoft Press contains additional details on developing C/C++ Windows Embedded CE 6.0 application programs and is updated for CE 6.0. The Enfora SA-GL GSM1218 cell modem reference manuals for the AT command set and several application notes including one on configuring and sending SMS text messages or email are available at www.enfora.com Additional information and documentation for the iRobot Create robot is available at www.irobot.com Additional information and documentation for the Robotics Connection Stinger robot kit is available at www.roboticsconnection.com

1. If a Phidgets LCD display device is available, develop an application the displays the eBox system time on the LCD. Verify that it works by running the code on the eBox. The API call GetLocalTime may come in handy. 2. If a Phidgets sensor is available, develop an application the reads in an analog sensor value, converts it to decimal, and displays it on the Phidgets LCD. Verify that it works by running the code on the eBox with the Phidgets modules attached. 3. If a Phidgets temperature sensor is available, develop an application that reads the temperature and functions like a heating thermostat. If the temperature drops too low, turn on a digital output bit to turn on the heater and when it gets to hot, turn off the digital output bit. You can heat up the temperature sensor by touching it. Attach an LED to the digital output bit so that you can monitor its state. A rotating or sliding sensor can also be used to simulate the temperature sensor. This type of application does not need a really fast update rate, so consider using the Sleep function. Display the current temperature reading on the Phidgets LCD or on the eBoxs display.
334
4. Add more features to the previous thermostat problem including the following: a. Digital input bits attached to a pushbutton or switch that raise or lower the desired temperature. Once you hit a pushbutton display the temperature setpoint and not the current temperature for several seconds. b. A switch that selects heating or cooling mode along with another output bit and LED to control the air conditioning. 5. Write a Windows GUI application that plots the most recent values of a Phidgets sensor vs. time in a sliding time window. 6. Build an autonomous robot by using the eBox and Phidgets PWM servo controllers to control a hobbyist R/C vehicle that uses standard R/C servos. Most low cost toys do not use the standard R/C PWM servo signals. The higher grade hobbyist models are setup to use the standard PWM signals for steering and speed control. With the hobbyist grade vehicles, a radio sold separately is typically used for remote control, but use the Phidgets and the eBox to setup a 802.11 wireless remote control application on another PC with wireless. Use slow speeds to avoid damage to the vehicle. A 5V DC 3A maximum regulated supply operating off of a battery will be required for the eBox. One such regulator board is available at www.roboticsconnection.com . 7. Add other sensors such as IR distance or Sonar can enable the vehicle to detect and avoid objects on its own. Several sensors even perhaps sensors of different types will be needed for reliable operation and you will need to use slower speeds on the vehicle to avoid damage. 8. Use the Cypress PSoC board with the eBox to control a low cost R/C toy vehicle as in the previous two problems. They do not use the standard R/C servo PWM signals, they just turn the motors on and off. Speed control can be achieved by pulsing and varying the duty cycle of the digital motor control signals at several kilohertz. You may be able to tap into the existing DC motor drive power transistor circuits and use them, or you could build your own. The eBox can send the PSoC microcontroller a desired speed setting and it can generate the required higher data rate pulses in firmware. Choose a vehicle large enough to carry the eBox and another battery. 9. Develop a web-page interface that remotely controls and display data from an interesting I/O device (Phidgets or PSoC) attached to the eBox. 10. Develop an application that allows you to remotely view an image from the web camera over the internet using a web browser by using the Web camera driver and the Web Server. 11. Add the web camera to the robot base from the problem 9 and using the internal eBox WiFi card with the Web Server develop a remotely controlled teleoperated robot. Due to network delays, expect some delay in response to new commands.
335
12. Develop a talking alarm clock using speech synthesis. 13. Read the news from a live RSS news feed using speech synthesis. 14. Modify the Speak example program so that it reads large text files aloud. To minimize delays, investigate using one thread to speak the current line of text while another thread is converting the next line of text to speak. 15. Using the Enfora SA-GL GSM1218 modem attached to an eBox COM port and CEs RIL OS drivers from the earlier example in this chapter, develop a remote device that can be controlled by and exchange data with a cell phone using SMS text messages. 16. Develop a GUI application that uses the Enfora modem attached to the eBox to produce a prototype device that can function as a cell phone that supports both voice calls and SMS messaging. A cell phone headset with a standard 2.5mm plug will be required for the modem. If an LCD touch panel is available, use it to develop a touch screen interface for the device. 17. Develop a cable hookup and an interface from the eBoxs audio output to the audio input on the cell phone modems microphone input. Microphone input signals typically need to be less than 1V peak to peak and speaker outputs can be several volts higher. Design an automated system that can automatically dial a list of phone numbers and send out emergency notification calls using synthesized speech. 18. Using the eBox with a web camera and Enfora modem, develop a prototype device that can send a still camera image anywhere upon request using the cell phone radio. 19. Write a console application that displays the current location from the GPS. Instead of using the OS GPS driver, read in and parse the NMEA strings using OS file system APIs to communicate with the serial port. 20. Develop a Windows GUI application that displays the current location from the GPS receiver. 21. Using a GPS receiver attached to the eBox, write a C# application that displays a map of your current location using one of the free mapping services available on the web that accept direct latitude and longitude input in the URL. (Hint: see the C# WebBrowser window info in problem 8.9) 22. Using the Enfora modem and a GPS unit attached to the eBox, develop a prototype of a device that reports back its current location in an SMS text message in response to a request it receives in a SMS text message with the string Where are you.
336
23. Develop a system that can perform optical character recognition on images captured by a web camera. Code will need to be developed to convert camera images to the *.pnm bitmap format used by the OCR program. 24. Extend the previous problem and add speech synthesis for output, so that it can read text aloud. 25. If a Create robot is available, run the CreateRemote program demo. Modify the program so that it automatically sends a motor stop command immediately whenever it encounters an object. Test your new code by running into an object at slow speed. 26. Attach the eBox to an iRobot Create base using a COM port or use the Robotics Connection Stinger robot base. Write code for the eBox that sends commands to the robot base that moves the robot around in a square pattern. 27. Using the CreateRemote program developed for the eBox and Create robot as a starting point, develop an autonomous robot that automatically performs some predefined task. The program should constantly read in sensor data and based on the sensor data make the appropriate decisions to automatically generate the necessary motor control commands so that it can exhibit an autonomous robot behavior. 28. Assuming a robot base is available for the eBox, add Sonar and IR distance sensors. The Create can read in additional analog and digital inputs using the DB25 connector found in the cargo bay or Phidgets modules can also be used. 29. Assuming a robot base is available for the eBox with wireless support, develop a robot that is remotely controlled using a web page interface. 30. Combine the speech synthesis project with a robot project to build a talking robot. 31. Develop an autonomous robot project that also uses the web camera for vision and if available, the internal wireless card for the eBox. 32. Develop a robot that can be monitored and controlled remotely using a cell phone and SMS messages. 33. Assuming that a large suitable surface is available outside for the robot, attach a GPS receiver to the robot and use it outdoors to navigate the robot. The robot should be able to navigate from one set of GPS coordinates to another avoiding any obvious obstacles in its path using its sensors.
CHAPTER 10
Introduction to I/O Device Drivers
This LG Electronics Voice over IP (VoIP) phone system is based on Windows Embedded CE. Photograph courtesy of Mike Hall.
338
10 Introduction to I/O Device Drivers

Device drivers help provide a layer of abstraction between the hardware and the user s application programs. A typical user developing an application should not need to understand the low-level hardware details of each interface. Instead, the application program calls OS APIs that invoke a device driver. By working at a higher level of abstraction using the OS and device drivers, applications programmers can be more productive. Applications can be ported more readily to different hardware platforms when the OS and device drivers are used and the system is also more stable and secure. The OS is also critical in scheduling, allocating, and managing devices that are shared between multiple processes. As an example, imagine what would happen if two applications started sending character data directly to the printer hardware at the same time. A random mix of characters on each printed page would result. Most of the common device drivers are provided with the OS or are available from chip manufacturers, but many will still need to be ported to a new hardware platform since even small changes such as I/O port address or interrupt level assignments may require minor modifications in the driver code. One challenge always faced by embedded systems designers is the need to develop device drivers for the unique hardware introduced in each new board design. Documentation on driver interfaces and example device drivers are included with each OS. Driver implementation details vary from OS to OS. A wizard type tool may also be provided to help generate the boilerplate code needed in a new device driver to interface properly to the OS. In some cases, device drivers are even purchased from third parties or developed by outside consultants. Entire books have even been written on the subject of writing device drivers. CEs device driver libraries are listed in Table 10.1 Table 10.1 CE Device Driver Libraries Library Description Microprocessor- Device drivers for high integration microprocessor-native native libraries peripherals. For example, the ARM microprocessor, and its companion chip integrates many peripherals on the microprocessor, such as LCD, serial, USB Host, USB function, and so on. An SDB or hardware platform that uses a specific microprocessor will use the same set of microprocessor-native drivers. In Windows Embedded CE, most microprocessors are high-integration microprocessors that contain many native peripherals. These are referred to as SOC (system-on-chip) drivers and these are in ..\WINCE600 \Platform\Common\Src\SOC. Microprocessor- OAL functions for devices such as a real-time clock, timer, and a specific OAL debug Ethernet controller that are common to a microprocessor. support libraries This library minimizes the OAL code written. These are also referred to as SOC (system-on-chip) drivers and are in ..\WINCE600 \Platform\Common\Src\SOC.
339
BSP or hardware platformspecific drivers Other common peripheral drivers
Device drivers for peripherals that are specific to a given SDB or hardware platform. These drivers have hardware platform-specific code and can only be used on that hardware platform. These drivers are in ..\WINCE600\Platform\<Hardware Platform Name> \Src\Drivers. Drivers for strategic peripheral chipsets that are commonly found or included on many SDB or hardware platform designs. These include devices like Realtek RTL8139, generic NE2000, DEC/Intel 2114x Ethernet chipsets, MediaQ MQ200, and ATI Rage XL display chipsets, and Ensoniq audio chipsets. The goal is to provide production quality drivers for 50% of the strategic chipsets that cover more than 75% of the hardware platforms available on the market. These are referred to as common drivers and are in ..\WINCE600\Public\Common\Oak\Drivers. Source code is provided for modules in the Public directory.
10.1 The Stream Interface Model for Device Drivers 48

A stream interface driver is any driver that exposes the stream interface functions, regardless of the type of device controlled by the driver. The stream interface model is the simplest way to implement most user drivers and applications access it using the normal file system APIs. Like many OS features, origins of the stream interface approach date back to the first versions of Unix. The stream interface is appropriate for any I/O device that can be thought of logically as a data source or a data sink. That is, any peripheral that produces or consumes streams of data as its primary function is a good candidate to expose the stream interface. An example is a serial port device. An example of a device that does not produce or consume data in the traditional sense would be a display device, and indeed, the stream interface is not exposed for controlling display hardware. The stream interface can use another underlying device driver to access the physical peripheral devices that the driver manages, or they can access the device directly if the device is mapped into memory. Audio device drivers for built-in audio hardware are an example of direct access. The stream interface functions themselves are designed to closely match the semantics of the usual file system application programming interfaces (APIs) such as CreateFile, WriteFile, ReadFile, IOControl, and CloseHandle. As a side effect of this design, devices that are managed by the stream interface are
48
Portions of the material presented in this Chapter was obtained from or is derived from the CE 6.0 online help files, MEDC 2006 conference presentations by members of the Windows Embedded CE design team, and Microsofts Windows Embedded CE Professional Training Materials. Reprinted with Permission of Microsoft Corporation.
340
exposed to applications through the file system; applications interact with the driver by opening special files in the file system. Stream interface drivers can have a monolithic architecture or a layered architecture with two layers, the MDD and PDD, as seen in Figure 10.1.
Device Manager
Stream Interface Stream Interface
MDD Monolithic Stream Interface Driver PDD
Device
Figure 10.1 Two alternative architectures for a Stream Interface Driver. A Monolithic Stream Interface Driver or a Layered Stream Interface Driver. In the layered driver architecture in CE, the two layers are named the MDD and PDD.
Treating devices as special files is common to many operating systems (OSs), including the desktop versions of the Microsoft Windows OS and even the first versions of Unix. There, printer devices have traditionally been represented by the LPTx: special file names, serial ports by the COMx: special file names, and so on.
341
Despite the generic characteristics of the stream interface, it can be implemented in different ways. For example, even though the stream interface is typically designed by independent hardware vendors (IHVs) for peripheral devices, original equipment manufacturers (OEMs) might choose to expose the stream interface for certain built-in devices. In some less common cases, stream interface drivers can repackage existing resources, usually in ways that specific applications can more readily use. For example, this type of stream interface driver can control a serial global positioning system (GPS) receiver. In this example, an ISV might choose to write a special stream interface driver to work in conjunction with a GPS mapping application. Many GPS receivers connect to serial ports. A GPS mapping application could, therefore, open the special COMx: file corresponding to the serial port and directly interact with the GPS receiver. However, the GPS receiver might provide positioning data in an inconvenient format, or the application writer might want to keep the details of managing specific models of GPS receiver hidden. Therefore, a stream interface driver could be written to mediate between the application and the GPS receiver. The driver would interact with the GPS receiver through a special COMx: file as before, but could repackage the positioning data in a more convenient format for the application. The driver could expose its own services as a special GPSx: file, which the application would open in order to read positioning data. A stream interface driver receives commands from the Device Manager and from applications by means of file system calls. The driver encapsulates all of the information that is necessary to translate those commands into appropriate actions on the devices that it controls. All stream interface drivers, whether they manage built-in devices or installable devices, or whether they are loaded at boot time or loaded dynamically, have similar interactions with other system components. Figure 10.2 shows the architecture for stream interface drivers for built-in devices that are loaded by the Device Manager at boot time. Various issues can affect your design decisions as you implement a stream interface driver dynamic-link library (DLL). To implement the stream interface driver, create a DLL containing the required entry points for the drivers, and then decide whether you want to enforce either single or multiple access to the driver. You can implement a driver with only Init and Deinit entry points and no device prefix. You cannot access this driver using CreateFile. PCIBUS and RegEnum are two examples of this type of driver. These drivers are located in the ..\WINCE600\Public\Common\OAK\Drivers\PCIbus and ..\WINCE600 \Public\Common\ OAK\Drivers\RegEnum directories.
342
Application
CreateFile
File System Stream Interface Driver (Loaded at Boot up)
OAL
Window CE Kernel
Device Manager
Interrupt Events
Software Hardware
Hardware Platform
Built-in Device
Figure 10.2 Stream Interface Architecture
If DEVFLAGS_NAKEDENTRIES is specified in the driver's Flags registry subkey, the entry point names can be undecorated; for example, Open, Close, and so on. The sample battery driver, which is in ..\WINCE600\Public\Common\OAK\Drivers\Battdrvr, is an example of a driver that uses undecorated entry points. The battery driver's registry settings still must include a prefix. Your implementations of these entry points must be declared for export from your DLL by placing __declspec(dllexport) in front of your function declaration. If you are developing in C++, your entry points must also be declared extern "C" as well. Table 10.2 shows the stream interface driver functions with a description of the purpose of each. XXX in each function name is replaced by the devices three character name. These functions are defined internally for the device manager only and not for user applications.
343
Table 10.2 Stream Interface Driver Functions. Programming element XXX_Close Description This function closes the device context identified by hOpenContext.. This function is required to access the device with CreateFile. If you implement XXX_Close, you must implement XXX_Open. This function de-initializes a device. It is called by Device Manager. This function is required by drivers loaded by ActivateDeviceEx, ActivateDevice, or RegisterDevice. This function initializes a device. It is called by Device Manager.This function is required by drivers loaded by ActivateDeviceEx, ActivateDevice, or RegisterDevice. This function sends a command to a device. This function might or might not be required, depending on the device capabilities that the driver exposes. This function requires an implementation of XXX_Open and XXX_Close. This function opens a device for reading, writing, or both. An application indirectly invokes this function when it calls CreateFile to obtain a handle to a device. This function is required to access the device with CreateFile. Optional. This function ends power to the device. It is useful only with devices that can be shut off under software control. Optional. This function restores power to a device. Optional. This function marks the closing handle as invalid and wakes any sleeping threads. This function marks the device instance as invalid and wakes sleeping threads. This function is required if the XXX_PreClose function is implemented. This function reads data from the device identified by the open context. This function might or might not be required, depending on the device capabilities that the driver exposes. This function requires an implementation of XXX_Open and XXX_Close. This function moves the data pointer in the device. This function might or might not be required, depending on the device capabilities that the driver exposes. This function requires an implementation of XXX_Open and XXX_Close. This function writes data to the device. This function might or might not be required, depending on the device capabilities that the driver exposes. This function requires an implementation of XXX_Open and XXX_Close.
XXX_Deinit
XXX_Init
XXX_IOControl
XXX_Open
XXX_PowerDown XXX_PowerUp XXX_PreClose XXX_PreDeinit
XXX_Read
XXX_Seek
XXX_Write
344
Because peripheral devices are exposed to applications as files when you create a stream interface, you provide the implementation of such a file. Therefore, consider whether it is practical, based on the capabilities of the device that your driver exposes, to enable multiple applications to have simultaneous access to the file that represents the device. That is, consider whether your driver can have multiple open file handles on its device. A stream interface driver can implement either single access or multiple access by using the hOpenContext parameter passed to all file I/O functions. To enable multiple access, each call to the XXX_Open function should return a different value for hOpenContext . The device driver must track which return values from XXX_Open are in use. Subsequent calls to XXX_Close , XXX_Read, XXX_Write , XXX_Seek , and XXX_IOControl pass these values back to the device driver, enabling the driver to identify which internal data structures to manipulate. To enforce single access, only the first call to XXX_Open should return a valid hOpenContext value. As long as this value remains valid, which is until XXX_Close is called for the value, subsequent calls to XXX_Open should return NULL to the calling application to indicate failure.
10.2 ISR & IST Processing for Device Drivers

Most peripheral devices can generate interrupts in order to receive service from the operating system (OS). Some examples of devices that can use interrupts are PC cards, onboard timers, audio input devices, keyboards, touch screens, serial ports, and pointing devices. Nearly any type of peripheral device might use interrupts as the principle method of initiating servicing actions by the OS. Because these peripheral devices can cause or signal interrupts, their device drivers must process interrupts in order to service their devices. Physical interrupts (IRQs) are hardware lines over which devices can send interrupt signals to the microprocessor. Logical interrupts (SYSINTRs) are a mapping of the IRQ, which the OAL specifies. When an interrupt is processed, a specific sequence of events takes place. You should write the interrupt service request (ISR) and interrupt service thread (IST) for your device driver with the following sequence of events in mind: 1. When an interrupt occurs, the microprocessor jumps to the kernel exception handler. 2. The exception handler disables all interrupts of an equal and lower priority at the microprocessor, and then calls the appropriate ISR for the physical interrupt request (IRQ). 3. The ISR returns a logical interrupt, in the form of an interrupt identifier, to the interrupt handler and typically masks the board-level device interrupt. 4. The interrupt handler re-enables all interrupts at the microprocessor, with the exception of the current interrupt, which is left masked at the board, and then signals the appropriate IST event. 5. The IST is scheduled, services the hardware, and then finishes processing the interrupt.
345
6. The IST calls the InterruptDone function, which in turn calls the OEMInterruptDone function in the OAL. OEMInterruptDone re-enables the current interrupt. A device driver must perform the following actions when its loads: Register its ISR with the kernel. The driver must register its ISR with the kernel unless the driver relies on the common OAL ISR function to handle its interrupt. The driver must register its ISR with the kernel so that the kernel calls the ISR when the appropriate physical interrupt occurs. Make an IRQ to SYSINTR mapping in the OAL's OEMInit function. -orThe bus driver that loads the driver must make an IRQ to SYSINTR mapping, which is the case with PCI bus driver.
If the driver does not install an ISR, any interrupts generated by the device are handled by a default ISR, which is installed by the OAL in OEMInit. The interrupt handler registration process registers an event that is associated with the system interrupt SYSINTR. After a device driver is loaded, the driver creates an interrupt service thread (IST), and then calls InterruptInitialize to register the event. The IST can then use WaitForSingleObject to wait on this event and register it with the interrupt handler. The IST is registered for one or more logical interrupts (SYSINTRs). If you use the Microsoft implementation of model device driver (MDD) for a particular driver, you do not have to write code to register the interrupt. The MDD layer of the driver registers the driver for interrupts. If you write a monolithic driver, you must implement code for registering the IST of the driver with the interrupt handler. To do this, use the CreateEvent function to create an event and the InterruptInitialize function to associate the event with a SYSINTR. If a device driver must stop processing an interrupt, the driver must use the InterruptDisable function. When the driver calls this function, the interrupt handler removes the association between the IST and the specified logical interrupt. The interrupt handler accomplishes this by calling the OEMInterruptDisable function to turn off the interrupt. The driver can register for the interrupt again later, if necessary. There may be times when you want to pass information between an interrupt service routine (ISR) and an interrupt service thread (IST). For example, because calling an IST each time an interrupt request (IRQ) arrives is a timeconsuming process, you might want to design an ISR to buffer IRQ data before calling the IST. The ISR would return SYSINTR_NOP until the buffer was full, and then would return the appropriate SYSINTR identifier when the ISR is ready for the IST to run. Once the IST runs, it can pick up the data that the ISR has been buffering. To pass data between an ISR and an IST:
346
1. Reserve physical memory for the ISR in your Config.bib file. Config.bib contains several examples of reserving physical memory for the serial and debug drivers. 2. Use the reserved memory in your ISR call. Because the ISR runs in kernel mode, the ISR can access the reserved memory to buffer data. Call the MmMapIoSpace function in your IST to map the physical memory to a virtual address. MMMapIoSpace calls the VirtualAlloc and VirtualCopy functions to map the physical memory to a virtual-memory address that the IST can access. You can also call VirtualAlloc and VirtualCopy directly. For example, you can allocate memory outside of the virtual memory space of a process by calling VirtualAlloc with its parameters set to the following values: dwSize >= 2 MB flAllocationType set to MEM_RESERVE flProtect set to PAGE_NOACCESS In Windows Embedded CE, an installable ISR can easily share data with an IST as the memory can be dynamically allocated instead of being reserved in the Config.bib file. The interrupt service thread (IST) is a thread that does most of the interrupt processing. The OS wakes the IST when the OS has an interrupt to process. Otherwise, the IST is idle. ISTs for a keyboard, touch screen, mouse, and display driver must call SetKMode(TRUE) to allow GWES to write to the shared memory heap. For the OS to wake the IST, the IST must associate an event object with an interrupt identifier. Use the CreateEvent function to create an event object. After an interrupt is processed, the IST should wait for the next interrupt signal. This call is usually inside a loop. When the hardware interrupt occurs, the kernel signals the event on behalf of the ISR, and then the IST performs necessary I/O operations in the device to collect the data and process it. When the interrupt processing completes, the IST should inform the kernel to re-enable the hardware interrupt. Table 10.3 Functions used by ISTs. Function Description InterruptInitialize Links the event with the interrupt identifier of the ISR. WaitForSingleObject Returns when the specified object is in the signaled state or when the time-out interval elapses. InterruptDone Instructs the kernel to re-enable the hardware interrupt related to this thread.
347
Usually, IST threads run at above-normal priority. They can boost themselves to a higher priority before registering their event with the kernel by calling CeSetThreadPriority . Table 10.3 shows the functions that the IST commonly uses. The following lists shows examples of what an IST might do at startup: Create a structure for storing interrupt values. Use CreateEvent as the IST trigger. Read the IRQ and SysIntr values from the registry and allow the OAL to map the IRQ to the SYSINTR value before the driver loads. Store the handle for the thread you create. The following PS/2 keyboard device driver code example from ..\WINCE600\Public\Common\OAK\Drivers\Keybd\Ps2_8042\Ps2keybd.cpp shows a typical IST.
BOOL Ps2Keybd:: IsrThreadProc( void ) { DWORD dwTransferred = 0; HKEY hk; DWORD dwStatus, dwSize, dwValue, dwType; int iPriority = 145; // look for our priority in the registry dwStatus = RegOpenKeyEx(HKEY_LOCAL_MACHINE, _T("HARDWARE\\DEVICEMAP\\KEYBD"), 0, 0, &hk); if(dwStatus == ERROR_SUCCESS) { // See if you have to enable your interrupt to wake the system from suspend. dwSize = sizeof(dwValue); dwStatus = RegQueryValueEx(hk, _T("EnableWake"), NULL, &dwType, (LPBYTE) &dwValue, &dwSize); if(dwStatus == ERROR_SUCCESS && dwType == REG_DWORD) { if (dwValue != 0) { m_pp2p->SetWake(TRUE); } } // get interrupt thread priority dwSize = sizeof(dwValue); dwStatus = RegQueryValueEx(hk, _T("Priority256"), NULL, &dwType, (LPBYTE) &dwValue, &dwSize); if(dwStatus == ERROR_SUCCESS && dwType == REG_DWORD) { iPriority = (int) dwValue; } // read our sysintr dwSize = sizeof(dwValue); dwStatus = RegQueryValueEx(hk, _T("SysIntr"), NULL, &dwType, (LPBYTE) &dwValue, &dwSize);
348

if(dwStatus == ERROR_SUCCESS) { if(dwType == REG_DWORD) { dwSysIntr_Keybd = dwValue; } else { dwStatus = ERROR_INVALID_PARAMETER; } } RegCloseKey(hk);
} if(dwStatus != ERROR_SUCCESS) { goto leave; } // set the thread priority CeSetThreadPriority(GetCurrentThread(), iPriority); m_hevInterrupt = CreateEvent(NULL, FALSE, FALSE, NULL); if ( m_hevInterrupt == NULL) { goto leave; } if ( !InterruptInitialize(dwSysIntr_Keybd, m_hevInterrupt, NULL, 0) ) { goto leave; } if (m_pp2p->WillWake()) { // Ask the OAL to enable your interrupt to wake the system from suspend. DEBUGMSG(ZONE_INIT, (TEXT("Keyboard: Enabling wake from suspend\r\n"))); BOOL fErr = KernelIoControl(IOCTL_HAL_ENABLE_WAKE, &dwSysIntr_Keybd, sizeof(dwSysIntr_Keybd), NULL, 0, &dwTransferred); DEBUGCHK(fErr); // KernelIoControl should always succeed. } m_pp2p -> KeybdInterruptEnable(); extern UINT v_uiPddId; extern PFN_KEYBD_EVENT v_pfnKeybdEvent; KEYBD_IST keybdIst; keybdIst.hevInterrupt = m_hevInterrupt; keybdIst.dwSysIntr_Keybd = dwSysIntr_Keybd; keybdIst.uiPddId = v_uiPddId; keybdIst.pfnGetKeybdEvent = KeybdPdd_GetEventEx2; keybdIst.pfnKeybdEvent = v_pfnKeybdEvent; KeybdIstLoop(&keybdIst); leave: return 0; }
349
The following code sample shows the implementation of the KeybdIstLoop function:
BOOL KeybdIstLoop ( PKEYBD_IST pKeybdIst ) { SETFNAME(_T("KeybdIstLoop")); UINT32 BOOL UINT rguiScanCode[16]; rgfKeyUp[16]; cEvents;
DEBUGCHK(pKeybdIst->hevInterrupt != NULL); DEBUGCHK(pKeybdIst->pfnGetKeybdEvent != NULL); DEBUGCHK(pKeybdIst->pfnKeybdEvent != NULL); SetThreadPriority(GetCurrentThread(), THREAD_PRIORITY_HIGHEST); wait_for_keybd_interrupt: if (WaitForSingleObject(pKeybdIst->hevInterrupt, INFINITE) == WAIT_OBJECT_0) { cEvents = (*pKeybdIst->pfnGetKeybdEvent) (pKeybdIst->uiPddId, rguiScanCode, rgfKeyUp); for (UINT iEvent = 0; iEvent < cEvents; ++iEvent) { (*pKeybdIst->pfnKeybdEvent)(pKeybdIst->uiPddId, rguiScanCode[iEvent], rgfKeyUp[iEvent]); } // cEvents could be 0 if this was a partial scan code, such as 0xE0. InterruptDone(pKeybdIst->dwSysIntr_Keybd); } goto wait_for_keybd_interrupt; ERRORMSG(1, (TEXT("KeybdIstLoop: Keyboard driver thread terminating.\r\n"))); return TRUE; }
350
10.3 DMA operations in Device Drivers

Direct memory access (DMA) is a method of transferring data from a device to memory, from memory to a device, or from memory to memory, without the help of a processor. You can perform common buffer and scatter/gather DMA using the CEDDK.dll or kernel functions. Common buffer DMA uses a contiguous buffer in main memory. Scatter/gather DMA uses multiple blocks at different memory addresses.. A standard DMA transfer occurs when a DMA controller performs the transfer. A DMA bus master transfer occurs when a peripheral device performs the transfer. Microsoft recommends that you use the CEDDK.dll functions for DMA. The CEDDK.dll functions call the kernel functions. Table 10.4 compares two ways to perform DMA, using CEDDK.dll functions and using kernel functions. Table 10.4 CEDDK vs. Kernel Functions for DMA. Using CEDDK.dll functions Using kernel functions CEDDK.dll provides these The kernel provides these functions for functions for obtaining a buffer obtaining a buffer for DMA transfers: for DMA transfers: AllocPhysMem HalAllocateCommonBuffer FreePhysMem HalFreeCommonBuffer HalTranslateSystemAddress CEDDK.dll functions can handle bus and hardware platformspecific address translations. CEDDK.dll functions are useful for common buffer DMA. CEDDK.dll functions use a default memory alignment of 64 KB.
You must handle hardware platform-specific address translations. You can call HalTranslateSystemAddress to translate the address. The kernel functions may be useful for scatter/gather DMA. The kernel functions allow you to change the default memory alignment.
The CEDDK.dll functions handle address translations between the system and the PCI bus or ISA bus for the DMA controller. You can support other bus types. The CEDDK.dll functions translate a physical RAM address into the corresponding bus-relative physical address for the DMA controller. To set up a common buffer for bus master DMA using the CEDDK.dll functions, a bus master DMA device driver can call HalAllocateCommonBuffer with the DMA_ADAPTER_OBJECT structure. The following code example shows a call to HalAllocateCommonBuffer . The code example is from the ES1371 driver located in ..\WINCE600\Public\ Common\OAK\Drivers\ WaveDev\PDD\ES1371 directory.
351
// Allocate an adapter object on the stack DMA_ADAPTER_OBJECT AdapterObject; AdapterObject.ObjectSize = sizeof(AdapterObject); AdapterObject.InterfaceType = PCIBus; AdapterObject.BusNumber = 0; // Allocate a single paged 4 KB output buffer dma_out_page[0] = (PUCHAR) HalAllocateCommonBuffer(&AdapterObject, 4096, &dma_out_logical_address, FALSE); if (!dma_out_page[0]) { ERRMSG("PDD_AudioInitialize: DMA Buffer Page Allocation Failed"); return FALSE; }
If the call to HalAllocateCommonBuffer succeeds, it returns the allocated buffer, or NULL if the call fails. The driver can use the allocated common buffer as a storage area for DMA transfers. The function also returns the physical bus-relative address of the buffer, which the function optionally provides to the DMA controller. You can also use the AllocPhysMem and FreePhysMem kernel functions for common buffer DMA transfers. If you use the kernel functions, call HalTranslateSystemAddress to translate the address you are passing to the DMA controller to avoid a memory violation. These functions take an alignment parameter, the CEDDK.dll functions use default alignment of 64 KB. For a common buffer DMA example with the kernel functions, see the ..\WINCE600\Public\Common\Oak\Drivers\Usb\Hcd directory. To set up scatter/gather DMA, you must use multiple pairs of base addresses and lengths simultaneously. The ATAPI driver located in the ..\WINCE600\Public\Common\Oak\Drivers\Block\Atapi directory is an example of scatter/gather DMA implementation.
10.4 A simple example device driver for the eBox

As an educational example of a simple stream interface driver, we will now develop a new device driver for the eBoxs serial port. It will be based on the earlier C/C++ example serial port program that talked directly to the serial port hardware. Recall that it used the CEDDK.lib functions that directly read and write I/O ports connected to the 16550 UART. To avoid confusion with the normal CE serial COM port drivers which will not be used, this driver example will use the new name KOM for the serial port. Our KOM port driver must be setup as a DLL subproject (not an application) and it must define and export the standard stream interface functions. The serial port s UART control and I/O operations needed inside each of these functions comes directly from the earlier example serial port code. The stream inter face driver code is shown on the following page. A number of OutputDebugString messages are included to track the drivers operation s in a debug build.
352
// // // // // // // // // // // // // // // // //
This is a Sample Stream Interface Device Driver Educational example intended to illustrate how stream drivers work using the serial I/O port hardware on the target system and show the use of READ_PORT_UCHAR and WRITE_PORT_UCHAR from the CE Device Driver Kit (CEDDK) Setup for X86 PC (CEPC) using 16550 UART compatiable serial port hardware Not intended to replace a good serial port device driver! Does not use interrupts, have any timeouts, or provide support for all of the serial port's features Would normally use OS API calls for this operation! FOR DEMO: Connect Ebox COM2: to PC with null modem cable Run HyperTerminal with 9600 Baud 8 data bits 1 stop bit no parity and no flow control
#include "stdafx.h" #include <windows.h> // For WRITE_PORT_UCHAR & READ_PORT_UCHAR functions // need to add to sources file include section: // ..\Wince600\ICOP_Vortex86_60A_x86\cesysgen\ddk\inc; \ // ..\Wince600\ICOP_Vortex86_60A_x86\cesysgen\oak\inc; \ #include "ceddk.h" // Also need to include CEDDK.lib in link (see sources file) // add $(_SYSGENOAKROOT)\lib\$(_CPUINDPATH)\ceddk.lib // to TARGETLIBS entries // Declare the Standard External Stream Driver Functions __declspec(dllexport) extern DWORD KOM_Init(LPCTSTR pContext, LPCVOID lpvBusContext); __declspec(dllexport) extern BOOL KOM_Deinit( DWORD hDeviceContext ); __declspec(dllexport) extern DWORD KOM_Open( DWORD hDeviceContext, DWORD AccessCode, DWORD ShareMode ); __declspec(dllexport) extern BOOL KOM_Close( DWORD hOpenContext ); __declspec(dllexport) extern BOOL KOM_IOControl( DWORD hOpenContext, DWORD dwCode, PBYTE pBufIn, DWORD dwLenIn, PBYTE pBufOut, DWORD dwLenOut, PDWORD pdwActualOut ); __declspec(dllexport) extern void KOM_PowerUp( DWORD hDeviceContext ); __declspec(dllexport) extern void KOM_PowerDown( DWORD hDeviceContext ); __declspec(dllexport) extern DWORD KOM_Read( DWORD hOpenContext, PUCHAR pBuffer, ULONG Count ); __declspec(dllexport) extern DWORD KOM_Write( DWORD hOpenContext, PUCHAR pBuffer, ULONG Count ); __declspec(dllexport) extern DWORD KOM_Seek( DWORD hOpenContext, long Amount, WORD Type ); void DBGOut(DWORD dwValue); void Setup_UART (PUCHAR Data_Port_Address); void Write_Serial_Character (PUCHAR Data_Port_Address, UCHAR Serial_Data);

UCHAR Read_Serial_Character (PUCHAR Data_Port_Address); PUCHAR Data_Port_Address; UCHAR Serial_Input_Data = 0; // ---------------------------------------------------BOOL APIENTRY DllMain( HANDLE hModule, DWORD LPVOID lpReserved ) { switch(ul_reason_for_call) { case DLL_PROCESS_ATTACH: OutputDebugString(L"KOM_DRIVER break; case DLL_PROCESS_DETACH: OutputDebugString(L"KOM_DRIVER break; case DLL_THREAD_ATTACH: OutputDebugString(L"KOM_DRIVER break; case DLL_THREAD_DETACH: OutputDebugString(L"KOM_DRIVER break; default: break; } return TRUE; } ul_reason_for_call,
353
DLL_PROCESS_ATTACH\n"); DLL_PROCESS_DETACH\n"); DLL_THREAD_ATTACH\n"); DLL_THREAD_DETACH\n");
// Stream Driver Init... DWORD KOM_Init( LPCTSTR pContext, LPCVOID lpvBusContext) { OutputDebugString(L"KOM_DRIVER - KOM_Init - Context: "); OutputDebugString(pContext); OutputDebugString(L"\n"); OutputDebugString(L"DemoDriver - Exit KOM_Init\n"); return 0x1234; } BOOL KOM_Deinit( DWORD hDeviceContext ) { OutputDebugString(L"KOM_DRIVER - KOM_Deinit\n"); OutputDebugString(L"KOM_DRIVER - Exit KOM_Deinit\n"); return TRUE; } // Stream Driver Open DWORD KOM_Open( DWORD hDeviceContext, DWORD AccessCode, DWORD ShareMode ) { OutputDebugString(L"DemoDriver - KOM_Open\n"); OutputDebugString(L"hDeviceContext - "); DBGOut(hDeviceContext); OutputDebugString(L"\n");
354
// Data Port Address for COM2: Data_Port_Address = (PUCHAR)0x2F8; // Sets up UART for 9600 Baud & No Interrupts with 8D NP 1S Setup_UART(Data_Port_Address); OutputDebugString(L"DemoDriver - Exit KOM_Open\n"); return 0x5678; } // Stream Driver Close BOOL KOM_Close( DWORD hOpenContext ) { OutputDebugString(L"KOM_DRIVER - KOM_Close\n"); OutputDebugString(L"hOpenContext - "); DBGOut(hOpenContext); OutputDebugString(L"\n"); // Add Close Function Code Here OutputDebugString(L"KOM_DRIVER - Exit KOM_Close\n"); return TRUE; } // Stream Driver IOCTL BOOL KOM_IOControl( DWORD hOpenContext, DWORD dwCode, PBYTE pBufIn, DWORD dwLenIn, PBYTE pBufOut, DWORD dwLenOut, PDWORD pdwActualOut ) { OutputDebugString(L"KOM_DRIVER - KOM_IOControl\n"); OutputDebugString(L"hOpenContext - "); DBGOut(hOpenContext); OutputDebugString(L"\n"); // Add IOCTL Function Code Here OutputDebugString(L"KOM_DRIVER - Exit KOM_IOControl\n"); return TRUE; } // Stream Driver PowerUP void KOM_PowerUp( DWORD hDeviceContext ) { OutputDebugString(L"KOM_DRIVER - KOM_PowerUp\n"); OutputDebugString(L"hDeviceContext - "); DBGOut(hDeviceContext); OutputDebugString(L"\n"); // Add PowerUP Function Code Here OutputDebugString(L"KOM_DRIVER - Exit KOM_PowerUp\n"); } // Stream Driver PowerDown void KOM_PowerDown( DWORD hDeviceContext ) { OutputDebugString(L"KOM_DRIVER - KOM_PowerDown\n"); OutputDebugString(L"hDeviceContext - "); DBGOut(hDeviceContext); OutputDebugString(L"\n"); // Add PowerDown Function Code Here OutputDebugString(L"KOM_DRIVER - Exit KOM_PowerDown\n"); } // Stream Driver Read DWORD KOM_Read( DWORD hOpenContext, PUCHAR pBuffer, ULONG Count ) { ULONG i; OutputDebugString(L"KOM_DRIVER - KOM_Read\n");

OutputDebugString(L"hOpenContext - "); DBGOut(hOpenContext); OutputDebugString(L"\n"); // Data Port Address for COM2: Data_Port_Address = (PUCHAR)0x2F8; // Read in Serial Data for (i=0; i<Count; i++) pBuffer[i] = Read_Serial_Character(Data_Port_Address); OutputDebugString(L"KOM_DRIVER - Exit KOM_Read\n"); return Count; } // Stream Driver Write DWORD KOM_Write( DWORD hOpenContext, PUCHAR pBuffer, ULONG Count ) { ULONG i; OutputDebugString(L"KOM_DRIVER - KOM_Write\n"); OutputDebugString(L"hOpenContext - "); DBGOut(hOpenContext); OutputDebugString(L"\n"); // Data Port Address for COM2: Data_Port_Address = (PUCHAR)0x2F8; // Write out Serial Data for (i=0; i<Count; i++) { Write_Serial_Character(Data_Port_Address, pBuffer[i]); DBGOut((DWORD)pBuffer[i]); }
355
//
OutputDebugString(L"KOM_DRIVER - Exit KOM_Write\n"); return Count; } // Stream Driver Seek DWORD KOM_Seek( DWORD hOpenContext, long Amount, WORD Type ) { OutputDebugString(L"KOM_DRIVER - KOM_Seek\n"); OutputDebugString(L"hOpenContext - "); DBGOut(hOpenContext); OutputDebugString(L"\n"); // Add Seek Function Code Here OutputDebugString(L"KOM_DRIVER - Exit KOM_Seek\n"); return 0; } void DBGOut(DWORD dwValue) { TCHAR tcTemp[10]; wsprintf(tcTemp,L"%ld",dwValue); OutputDebugString(tcTemp); }
356
void Write_Serial_Character (PUCHAR Data_Port_Address, UCHAR Serial_Data) // Write out a character to the serial port { UCHAR Status; // Wait for TX output ready bit=1 // Status I/O Port Address is Data I/O Port Address + 5 do{ Status = READ_PORT_UCHAR(Data_Port_Address + 5); // if UART transmit buffer full release remainder of time slice if ((Status & 0x40) == 0) Sleep(0); } while ((Status & 0x40) == 0); // Write data out on COM2: WRITE_PORT_UCHAR(Data_Port_Address, Serial_Data); return; } UCHAR Read_Serial_Character (PUCHAR Data_Port_Address) // Read in a character from the serial port { UCHAR Serial_Data, Status; // Wait for RX input ready bit=1 // Status I/O Port Address is Data I/O Port Address + 5 do{ Status = READ_PORT_UCHAR(Data_Port_Address + 5); // if UART recieve buffer empty release remainder of time slice if ((Status & 0x01) == 0) Sleep(0); } while ((Status & 0x01) == 0); // Read in new serial data Serial_Data = READ_PORT_UCHAR(Data_Port_Address); return Serial_Data; } void Setup_UART (PUCHAR Data_Port_Address) { UCHAR Temp; // Setup UART to 9600 Baud 8D,NP,1S no interrupts // Will need a good PC Hardware Reference Text and/or // the 16550 UART data sheet to fully understand this! // Disable COMx: Interrupts (use Programmed I/O) WRITE_PORT_UCHAR(Data_Port_Address + 1, 0); // Set Baud Rate to 9600 with clock Divisor settings // Put in set divisor mode Temp = READ_PORT_UCHAR(Data_Port_Address + 3); WRITE_PORT_UCHAR(Data_Port_Address + 3, Temp | 0x83); // Set Divisor LSB (note: 12 = 115200/9600) WRITE_PORT_UCHAR(Data_Port_Address , 12); // Set Divisor MSB WRITE_PORT_UCHAR(Data_Port_Address + 1, 0); // Back to normal operation mode (and set for 8D NP 1S) Temp = READ_PORT_UCHAR(Data_Port_Address + 3); WRITE_PORT_UCHAR(Data_Port_Address + 3, Temp & 0x03); return;
357
Recall that the Device Manager checks the registry for the device name passed in a CreateFile API call to determine which driver should be used. This registry entry need s to be setup for our new driver by editing the subprojects platform.reg file. The *.reg files are automatically merged and copied into the initial registry on the target device. Double click on a *.reg file to edit it using reg edit or edit it using Notepad. It needs to contain the following registry entry in the subprojects *.reg file so that the device manager can find it: [HKEY_LOCAL_MACHINE\Drivers\BuiltIn\KOM_DRIVER] "Dll" = "KOM_Port.Dll" "Prefix" ="KOM" "Index"= dword:1 "Order"= dword:0 "FriendlyName" = "KOM Port Demo Driver" "Ioctl" = dword:0 There are many different registry settings that control how a driver loads. Most are optional. Some registry settings are used by the Device manager and can be optionally used by all drivers. Custom registry entries can also be added that are referenced directly by the driver itself after it loads. DLL is a string value that specifies the dll filename to load. This value is required. Prefix is a three character string that is makes up the name of the driver. This value must be present in order to have a file handle based interface to the driver. The Prefix value is the same value that must be used in the stream driver entry points unless the DEVFLAGS_NAKEDENTRIES flag is set. Order is a dword value that provides a mechanism supporting load order dependencies. Drivers will be loaded in the order specified by the Order key. If this key does not exist the driver will be loaded at the end. Order should not be used unless there is a load order dependency to resolve. Index is a dword value that makes up the numeric portion of the device name. This value is optional as the Device manager will pick the next sequential value if it does not exist. IClass provides a mechanism to advertise capabilities to various system components. Flags provides a mechanism to control the way the driver is loaded. The DLL could be loaded in the process space using LoadLibrary or LoadDriver. In this example, we want to develop an actual device driver that is part of the kernel. For this to happen, t he new drivers DLL file also needs to be included in the kernel run-time image. To include a new file in the kernel open the driver s subproject *.bib file and confirm/add the following entry:
MODULES KOM_Port.dll
$(_FLATRELEASEDIR)\KOM_Port.dll
NK
SHK
358
This file is automatically setup in subprojects. Next, the driver subproject needs a *.def file to expose its functions. Create a *.def file using notepad or the editor in Platform builder with the following:
LIBRARY DemoDriver EXPORTS KOM_Init KOM_Deinit KOM_Open KOM_Close KOM_IOControl KOM_PowerUp KOM_PowerDown KOM_Read KOM_Write KOM_Seek
As an alternative to creating a *.def file, you can declare each external function using __declspec(dllexport) and extern c (in C++) prior to each external function definition in the C++ source code, Now after a build, the new driver s DLL file will be in the kernel. Device manager can find the driver when a CreateFile KOM API call is made by searching the registry. The driver s entry points are available to other programs. An application is now needed to test the new KOM driver by calling it and making sure device manager can find the driver and that the drivers functions work correctly. Another subproject is setup for KOM_Tester. The KOM_Tester code is shown below:
// // // // // // // KOM_Tester.cpp : Defines the entry point for the console application Serial Port File I/O Test Program for KOM_Port Driver FOR DEMO: Connect Ebox COM2: to PC with null modem cable Run HyperTerminal with 9600 Baud 8 data bits 1 stop bit no parity and no flow control
#include "stdafx.h" HANDLE hSerial; int _tmain(int argc, TCHAR *argv[], TCHAR *envp[]) { DWORD cBytes_out, cBytes_in; char cBuffer_out[] = "\f\n Hello KOM Serial World!\n\rType something and watch it echo back\n\rCtrl C to exit\n\r"; TCHAR cBuffer_in[80]; // Display message on console printf("\nOpening KOM2: Serial Port to test new KOM Driver - Type ctrl C on other device to exit\n\r");
359
// Open Serial Port COM2: for Read and Write // Note: COM1: is setup to send out Debug info // so COM2 becomes COM1 hSerial = CreateFile(_T("KOM1:"), GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0, NULL); // Check for file open errors if (hSerial == INVALID_HANDLE_VALUE){ printf("file open errors\n","%X", hSerial); Sleep(4000); return 0; } // Write to title out to serial port. if (!WriteFile(hSerial, cBuffer_out, strlen(cBuffer_out), &cBytes_out, NULL)) { printf("file write errors\n"); Sleep(4000); return 0; } cBuffer_in[0] = 0; // Read in characters, copy to console display and Echo (write) back // Loop until ctrl C (0x03) is typed while (cBuffer_in[0] != 0x03){ // Read back data any serial data and display if (ReadFile(hSerial, cBuffer_in, 1, &cBytes_in, NULL)){ if (cBytes_in == 0) break; // Display Data read back printf("%s",cBuffer_in, cBytes_in); // Echo characters back to sender if (!WriteFile(hSerial, cBuffer_in, cBytes_in, &cBytes_out, NULL)){ printf("\rfile write errors\n"); Sleep(4000); return 0; } } } // Close File CloseHandle(hSerial); return 1; }
After a build, the new kernel is downloaded and the KOM_Tester program is run to test the KOM_Port.DLL driver. The serial cables are connected and HyperTerminal or RealTerm is started on the development system. The text output on the eBox and development system displays should be the same as the earlier serial port example programs. In a debug build, the debug messages in the output window will indicate when the various KOM_XXXX entry points are called.
360
The following driver debug messages were displayed in the debug output window while running KOM_Tester:
Run Programs s KOM_Tester PB Debugger Loaded symbols for 'C:\WINCE600\OSDESIGNS\OSDESIGN7\OSDESIGN7\ RELDIR\ ICOP_VORTEX86_60A_X86_RELEASE\KOM_TESTER.EXE' s KOM_Tester 22:33:23 11/25/2006 Eastern Standard Time End s KOM_Tester 22:33:23 11/25/2006 Eastern Standard Time PB Debugger Loaded symbols for 'C:\WINCE600\OSDESIGNS\OSDESIGN7\OSDESIGN7\ RELDIR\ ICOP_VORTEX86_60A_X86_RELEASE\CONSOLE.DLL' 61200 PID:400002 TID:4880012 DemoDriver - KOM_Open 61200 PID:400002 TID:4880012 hDeviceContext 61200 PID:400002 TID:4880012 4660 61201 PID:400002 TID:4880012 61202 PID:400002 TID:4880012 DemoDriver - Exit KOM_Open 61203 PID:400002 TID:4880012 KOM_DRIVER - KOM_Write 61203 PID:400002 TID:4880012 hOpenContext 61204 PID:400002 TID:4880012 22136 61204 PID:400002 TID:4880012 61317 PID:400002 TID:4880012 KOM_DRIVER - Exit KOM_Write 61318 PID:400002 TID:4880012 KOM_DRIVER - KOM_Read 61318 PID:400002 TID:4880012 hOpenContext 61319 PID:400002 TID:4880012 22136 61319 PID:400002 TID:4880012 69052 PID:400002 TID:4880012 KOM_DRIVER - Exit KOM_Read 69066 PID:400002 TID:4880012 KOM_DRIVER - KOM_Write 69067 PID:400002 TID:4880012 hOpenContext 69067 PID:400002 TID:4880012 22136 69067 PID:400002 TID:4880012 69067 PID:400002 TID:4880012 KOM_DRIVER - Exit KOM_Write 69068 PID:400002 TID:4880012 KOM_DRIVER - KOM_Read 69068 PID:400002 TID:4880012 hOpenContext 69069 PID:400002 TID:4880012 22136 69069 PID:400002 TID:4880012 69221 PID:400002 TID:4e80012 KOM_DRIVER - DLL_THREAD_DETACH . . . 185145 PID:400002 TID:4880012 KOM_DRIVER - Exit KOM_Read 185159 PID:400002 TID:4880012 KOM_DRIVER - KOM_Close 185160 PID:400002 TID:4880012 hOpenContext 185160 PID:400002 TID:4880012 22136 185162 PID:400002 TID:4880012 185162 PID:400002 TID:4880012 KOM_DRIVER - Exit KOM_Close PB Debugger Unloaded symbols for 'C:\WINCE600\OSDESIGNS\OSDESIGN7\ OSDESIGN7\RELDIR\ICOP_VORTEX86_60A_X86_RELEASE\CONSOLE.DLL' PB Debugger Unloaded symbols for 'C:\WINCE600\OSDESIGNS\OSDESIGN7\ OSDESIGN7\ RELDIR\ICOP_VORTEX86_60A_X86_RELEASE\KOM_TESTER.EXE' 206855 PID:400002 TID:40b0002 KOM_DRIVER - DLL_THREAD_DETACH
As you can see from the debug output, the test program was loaded. Once it ran, it called KOM_Open. Several calls are made to KOM_Write and KOM_Read to transfer data typed in on the serial port connected to Hyperterminal running on the development system PC. Before the program exits after receiving a CTL C input character in the last KOM_Read, it makes a call to KOM_Close. KOM_init was also called during the initial boot process.
361
10.5 Production Quality Drivers

For a real production quality driver such as those provided with the OS, we would still need to make a large number of improvements to our simple KOM driver example. It should only allow one KOM_OPEN at a time, so that two applications do not access the serial port at the same time. A full set of IOCTL functions should be developed to support setting different baud rates, data bits, parity bit, stop bit(s), and handshaking modes. It should check for the overrun, framing, and parity errors reported by the UART. For a higher transfer rate, it could all be buffered and interrupt driven. Software timeout error loops should be considered for any hardware failure that would cause the driver to hang. A KOM_CLOSE immediately followed by a KOM_OPEN at a different baud rate could cause errors since several characters are buffered inside the UART. Either KOM_CLOSE or KOM_OPEN could wait until the UART buffers empty to solve this problem. Many API calls also have options so that they can be setup to work synchronously (wait until operation completes to return) or asynchronously (return before operation is completed). The I/O Resource manager should be made aware of the I/O ports used by the driver. If a device has several KOM ports, it could be converted to a layered device driver (MDD and PDD layers). A registry entry is needed for each instance of the KOM port with a different device array index, and the I/O base address to be used by the driver should also be added as a new registry key. Finally, all of these new features need to be well commented, fully documented, and thoroughly tested. You can find the actual source code for CEs serial device driver in several modules in the main shared source driver directory at \WINCE600\PUBLIC\COMMON\OAK\DRIVERS\SERIAL . A high-speed interrupt driven optional serial port driver DLL is available in the file \WINCE600\PUBLIC\COMMON\OAK\DRIVERS\SERIAL\ISR16550.dll . ISR16550.dll minimizes the time to signal the interrupt service thread (IST). This allows faster data transfers because there is a penalty for the system to schedule the IST. ISR16550.dll transfers data from the UARTs hardware buffer to a software receive first-in, first-out (FIFO) buffer and fills up the UARTs hardware transmit FIFO data from a software transmit FIFO buffer without any IST involvement. The IST is signaled only when the receiving buffer reaches its threshold and the transmitting buffer is empty. The IST is also signaled when the incoming data stream times out. Without interrupt driven device drivers or hardware handshaking, serial devices running at high baud rates will occasionally drop characters.
362
10.6 Stream Interface Drivers for USB Devices

The stream interface driver approach can also be used for USB devices. The shared-source code USB Web Camera driver is another example of a stream interface driver. It is an example of a somewhat more complex USB device driver that uses the same stream interface driver approach. In addition to the previously described stream interface driver entry points, three new entry points and a new registry entry are required in a USB stream interface driver. USBDeviceAttach is called by the OS when a matching USB device is inserted in the computer and an entry for the USB devices PID/VID or other matching entry is found in the windows registry in a subkey of HKEY_LOCAL_MACHINE\Drivers\USB\LoadCleints. It returns true, if it can operate the device and it also loads the driver. USBInstallDriver is called when an unknown device is inserted and a driver name is entered in the po p up dialog box that appears on the video display for an unknown USB device. USBUninstallDriver is called to remove registry entries and release other driver resources when the device is removed. A white paper along with complete source code is available that describes the operation and design of the stream interface USB web camera driver 49. The shared source code Phidgets Driver project was also based on this example 50.

The on-line help system in Visual Studio provided by Windows Embedded CE 6.0 contains additional information on developing device drivers. Source code for a wide assortment of PC-related I/O device drivers is provided with CE in the directory ..\WINCE600\PUBLIC\COMMON\OAK\DRIVERS The Phidgets and Logitech Web camera shared source code community projects are an excellent source of information on USB drivers. The URL for the CE shared source code community projects is: http://msdn2.microsoft.com/en-us/embedded/aa731151.aspx An example stream interface driver for CE 5.0 is developed and described in the article, SPOT the Geek and Windows CE Drivers, by Mike Hall at http://msdn2.microsoft.com/en-us/library/aa459176.aspx
49
50
Writing a Windows CE USB Webcam Driver, by Douglas Boling ( www.codeplex.com/cewebcam ) Windows CE Driver for Phidgets, (http://www.codeplex.com/PhidgetsWinCEDriver)
363

1. A device has a basic 8-bit parallel (GPIO) port. Compare and contrast three different approaches to talk to the device using C/C++ code. The three alternatives are in-line assembly language (assume X86 processor), built-in C functions that talk to I/O ports, and a full OS stream interface device driver. Include a short code segment for each alternative showing the code, function calls or CE APIs that would force an I/O write operation to the parallel port at address 0x3e0 in a user application. For the OS device driver, assume the device name for the parallel port is PPT:. Compare and contrast the advantages and disadvantages of each approach. Include issues such as memory used, execution time, portability to different processors, initial development time, I/O device access locks and scheduling, and ease of use by other developers. Assume that the device runs multiple applications simultaneously and that the application code is developed by a large group of software developers. 2. Describe the steps needed to develop a new CE OS stream interface device driver for an 8-bit parallel port on a device at address 0x3e0 named PPT:. Complete code is not required, just briefly describe and outline that various steps needed to write the driver and add it to the OS, so that application programs can use the new device driver. 3. Run the KOM driver and KOM tester example and reproduce the results described in the text. 4. Modify the KOM driver so that only one process can have it open successfully at a time. The second open should return an error code. Develop a new test program and verify that it works. 5. Add IOCTRL features to the KOM driver that will allow setting of the baud rate, parity, and number of stop bits. Develop a new test program and verify that it works. 6. Develop a test program that changes the baud rate in the middle of sending out constant patterns of data. If there are any problems such as invalid or missing characters, modify the code to resolve them. 7. Configure the I/O resource manager data so that it is aware of the I/O address ranges used by the KOM driver. Attempt to open both the KOM and COM port and see if open errors will result due to I/O address conflicts. 8. Study the source code for the example interrupt driven 16550 serial device driver and modify the KOM driver to make it interrupt driven.
CHAPTER 11
Advanced OS Topics
This Atronic slot machine runs Windows Embedded CE. In casinos, the slot machines are networked to a back office server that can monitor all activity. A random number generator determines the outcome and then the wheels spin to simulate a mechanical slot machine. Code and payoff odds are audited and certified by state gaming agencies. Photograph courtesy of Mike Hall.
366
11 Advanced OS Topics51
11.1 Porting the OS to a new device
For the eBox 4300, an existing BSP was used to develop the OS and applications. Having a BSP available made the process much easier. For a new hardware design, additional steps are required to initially bring up the OS on a new platform and develop a new BSP. The new device must also of course be using one of the X86, ARM, SHx or MIPS family of processors that is supported by the compiler and OS.
Windows CE Platform Development Process
Device Bring-Up Platform Development Application Development
Hardware Design
Develop Custom Drivers Testing and Integration Custom Windows CE Catalog Items
Load ROM Monitor
Boot Minimum Kernel on Hardware Create Boot Loader Testing and Integration Applications and Middleware Develop and Integrate Catalog Items Testing and Integration
Testing and Integration
OAL Development
BSP Development
Figure 11.1 The Process of porting CE to a new target device.
To develop an OS design based on the Windows Embedded CE OS for new hardware, you must complete the following major tasks as seen in Figure 11.1.
51
Portions of the material presented in this Chapter were obtained from or have been derived from the CE 6.0 on-line help files, MEDC 2006 conference presentations by members of Microsofts CE design team, and Microsofts Windows Embedded CE Professional Training Materials. Reprinted with Permission of Microsoft Corporation.
367
These steps are outlined below: Create an initial board support package (BSP) for your specific target device. The BSP should include the boot loader, OEM adaptation layer (OAL), and any drivers needed. Examples are available for each family of processors and BSPs may already be available for similar hardware setups that provide an initial starting point. The eBox BSP was based heavily on the CEPC BSP that was already available for X86 systems. Create an OS design, based on a standard or custom BSP, that you can use to create a run-time image that you can download to a standard development board (SDB), which is also called a hardware platform. Create and customize device drivers for your final target BSP. Customize the OS design with additional subprojects and Catalog items. Build the run-time image, download it to your SDB, and then debug the run-time image by using the debugging tools found in the CE 6.0 integrated development environment (IDE). When the run-time image is complete, export a software development kit (SDK) for the application developers. On some target devices like the eBox 4300, much of this work has already been done and the devices manufacturer provides a CE BSP to users of the device. Users then use the manufacturers BSP and select the OS features needed to build a custom OS for their product. When a complete BSP is available, a new OS can be created and downloaded to the device in a few minutes.
11.2 Developing a BSP for a new board design

A board support package (BSP) is the common name for all board hardwarespecific code. It typically consists of the following: The boot loader The OEM adaptation layer (OAL) Board-specific device drivers The BSP creation process involves the following tasks: Developing a boot loader Developing an OAL Creating device drivers Modifying run-time image configuration files If you do not have a BSP, you can create a new one or clone an existing initial BSP that is designed for similar hardware. Table 11.1 shows the elements that are typically contained in a board support package (BSP).
368
Table 11.1 Elements of a Board Support Package (BSP). Element Boot loader OEM adaptation layer (OAL) Device drivers Run-time image configuration files Description During development, downloads the OS images. Links to the kernel image and supports hardware initialization and management. Supports peripherals on-board or are attached at run time. When created, a BSP can be reconfigured through environment variables and .bib and .reg file modifications.
11.3 Developing a Bootloader for a new device

The boot loader is a utility that is an integral part of the OEM device development process. The purpose of the boot loader is to place the run-time image into memory, and then jump to the OS startup routine.
Bootloader/ startup
kernel.dll
NKGLOBAL
oal.exe
Figure 11.2 The Initial Startup Sequence for CE
The CE startup sequence is shown in Figure 11.2 and has the following operations: 1. The Bootloader initializes hardware, jumps to the exe base of oal.exe (StartUp) 2. Oal.exe::Startup calls KernelInitialize with OEMAddressTable if necessary (nkldr.lib) 3. Oal.exe:: KernelInitialize sets up MMU, etc., jumps to entry point of kernel.dll 4. Kernel.dll calls oal.exe:: OEMInitGlobals (oemmain.lib) 5. Oal.exe:: OEMInitGlobals exchanges pointers to global structures 6. Kernel.dll calls into entry point of kitl.dll (KitlDllMain in kitlcore.lib) to exchange pointers to global structures for KITL
Startup library
OEMInit Globals() Globals()
OEMGLOBAL
KITL IOCTL
kitl.dll
369
The boot loader can obtain the run-time image in a number of different ways, including loading it over a cable connection, such as Ethernet, a universal serial bus (USB), or serial connection. The boot loader can also load the OS from a local storage device, such as Compact Flash, or a hard disk. The boot loader might store the run-time image in RAM or in nonvolatile storage, such as flash memory, electrically erasable programmable read only memory (EEPROM), or some other storage device for later use. Using the boot loader during the board support package (BSP) development process saves time. You can quickly download a new run-time image to a target device using a boot loader rather than manually transferring the run-time image to a target device using a flash memory programmer or IEEE 1149.1-compliant test access port and boundary-scanning technology. In some cases, a boot loader is included in the final OEM product. In many final OEM products, the boot loader is removed from the product and the system reset process bootstraps the run-time image, which is stored on the device. However, hardware platforms that do not efficiently support this ability, such as x86 platforms, or hardware platforms that need to perform pre-boot tasks, such as run-time image updates, might include the boot loader in the final product. Although each boot loader differs in the tasks it carries out and the way it performs them, the most common boot loader downloads the run-time image over Ethernet into RAM on a target device. Several examples are provided with the OS documentation and source code.
11.4 Modifying the OEM Adaptation Layer

The Original Equipment Manufacturer (OEM) adaptation layer (OAL) of the operating system is designed to isolate and minimize the operating system changes needed to port the OS to each new hardware platform. As seen in Figure 11.3, the OAL contains the lowest level of routines that communicate directly with the systems hardware. The kernel uses the OAL routines to talk to hardware. The Kernel Interface Transport Layer (KITL) is used by the development system for communications with the target device. An OEM adaptation layer (OAL) is a layer of code that logically resides between the CE kernel and the hardware of your target device. Physically, the OAL is linked with the kernel libraries to create the kernel executable file.
370
kernel.dll
NKGLOBAL
oal.exe
OEMGLOBAL
KITL IOCTL
kitl.dll
IOCTL library
OS Timer library
Timers
Interrupt library
Startup library
Cache library
RTC library
RTC
Caches
Hardware
USB port
Ethernet port
Serial port
Figure 11.3 Porting CE to a new target device requires changes to the OAL routines.
The OAL facilitates communication between your operating system (OS) and your target device and includes code to handle interrupts, timers, power management, bus abstraction, generic I/O control codes (IOCTLs), and so on. Creating the OAL is one of the more complex tasks in the process of getting a CEbased OS to run on a new hardware platform. In general, the easiest way to create an OAL is to copy the OAL implementation from a working OS design on similar hardware, and then modify it to suit the specific requirements of your hardware platform. If you must create an OAL from the beginning, the task can be greatly simplified by approaching the development process in stages. Each stage adds a little more functionality than the previous one and provides a convenient separation point where new functionality can be fixed and validated before proceeding to the next step. Example OAL code is provided with the OS. The production-quality OEM adaptation layer (OAL) available in CE was designed to simplify and shorten the process of developing an OAL. It provides an improved level of OAL componentization through code libraries, directory
371
structures that support code reuse, centralized configuration files, and a consistent architecture across processor families and hardware platforms. The processor and hardware platform framework provided by the productionquality OAL enables you to develop the most basic CE kernel, a Tiny Kernel image for initial testing. The production-quality OAL provides the following improvements over the previous OAL model: A common set of processor-specific components OAL software components A standard directory structure Conventions for BSP development
In CE, you can clone an existing BSP. However, the ..\WINCE600\Platform\<Hardware Platform Name> BSP directory contains minimal code files and these are mainly configuration files. Most of the BSP code files are located in the ..\WINCE600\ Platform\Common directory and do not have to be modified unless your hardware platform implementation is significantly different from the CE implementation. You now reference the software components as libraries. The OAL libraries are a collection of functional, static libraries that you can assemble, in a modular approach, to create an OAL or boot loader. The individual libraries conform to a set of APIs common across all CPU architectures. The hardware library is organized and implemented in a consistent fashion according to hardware architecture, part number, and functional-level to help you determine the level of hardware support needed and to create a self-documenting directory structure. The production-quality OAL allows you to use consistent hardware across a family of processors. To accomplish this, the hardware library implements the core functions for OAL functionality that interact at the chip level. Board-level operations, such as IRQ routing or glue-logic interactions, remain in the ..\WINCE600\Platform\<Hardware Platform Name> directory, but they are simplified and abstracted across all architectures, whenever possible. You can now extend the functionality in your hardware platform by using callbacks. For example, in the interrupt code for the CPU architectures, a particular CPU interrupt timer has been implemented. However, because some aspects of how interrupts are wired to the system are still board-dependent, there is no comprehensive set of interrupt routines for every hardware platform. Instead, the built-in callbacks can call into OEM code and you can customize how you want the interrupts to be handled. Figure 11.4 shows how the OAL, boot loader, drivers, and run-time image configuration files interrelate with the BSP and the standard development board (SDB) or hardware platform.
372
Figure 11.4 BSP Structure
11.5 Hardware Debug Tools for Embedded Systems

When initially bringing up a new embedded computer board, special external hardware debug tools are often used. These include devices such as in-circuit emulators (ICE), in-target probes (ITP), and special purpose logic analyzers attached to hardware debug or trace port pins coming from the processor. On early generation processors, you could trace the instruction execution flow using a logic analyzer attached to the processor to memory bus. But newer processors are deeply pipelined and contain an instruction cache, making this approach of limited use for detailed debug information. Some small system on a chip (SoC) microcontrollers use only on-chip memory, so in this case the processor memory bus is internal to the chip. Software breakpoints will not work on code running from ROM (i.e., PC BIOS or a ROM Bootloader) since the special call/jump instructions needed to implement a software breakpoint cannot be written to ROM. Special processor debug/trace port pins were developed on many processors in response to these issues. To support the processor hardware debug/trace ports, an extra connector or processor socket is typically required on the embedded computer board. This may require some initial PCB design considerations to support debugging. On many processors with advanced high-pin count packages such as BGA, it may be impossible to access the pins needed without this special debug connector or a socket. A special adapter on the hardware debug tool connects to the processor debug or trace port pins using this connector or socket and it allows instruction level tracing of the processor. It also often includes support for hardware breakpoints, downloading memory, and even programming flash.
373
Keep in mind that when you are first setting up a new board, the software debug tools will not work until the OAL, an initial BSP, and OS are working. So these hardware debugging tools are very useful for the initial debug stages on a new board. Unfortunately, ICE modules, ITP modules, or the processor debug port adapter tools for logic analyzers can cost several thousand dollars and a new one is needed for each different type of processor. An ARM hardware debug tool is shown in Figure 11.5 and an X86 hardware debug tool is shown in Figure 11.6. Even just a few LEDs on a board attached to a GPIO port can also be very handy to have some idea of exactly what code is executing by inserting code to output to the LEDs at critical points. Oscilloscopes and logic analyzers can also monitor a few pins on a GPIO port to obtain some information including timing of events.
Figure 11.5 This hardware debug tool is tracing the instruction execution of an XScale (ARM family) processor using a general purpose Tektronix logic analyzer. The logic analyzer is running Windows XP. Special software disassembles code to provide the XScale assembly language mnemonics. Image courtesy of Nexus Technology.
374
Figure 11.6 This hardware debug tool is tracing the instruction execution of a P4 (X86 family) target processor using an in-target probe (ITP) adapter box with special software running on a desktop PC running Windows XP. It disassembles code to provide the X86 assembly language mnemonics and displays register contents. Image courtesy of American Arium.
11.6 Moving a new OS image to the eBox for standalone booting

In the final version of an embedded device, the OS and any built-in applications would automatically boot standalone by using a local copy of the code. This code is typically stored in the devices Flash memory. To boot a new
375
OS on the eBox using a local copy instead of downloading over a network connection each time, use one of the following methods: Make a bootable USB flash drive (see Appendix C for details). Boot from the USB flash drive and replace the NK.BIN file with your new version. The eBox BIOS setup option to boot from USB only appears when a USB drive is connected. Each new OS project generates a new NK.BIN file in the projects (reldir) release directory in the debug or release subdirectory. You can replace the old NK.BIN OS image file on the eBoxs internal flash drive. This shows up as C in DOS and Hard Disk or DOS in CE. It is a good idea to just rename NK.BIN and keep the old copy. There is room for a couple OS images on the internal flash drive. Do not delete any of the other files on the internal flash drive, as they are needed for the boot process.
You can copy NK.BIN from a USB flash drive, a CF flash card, or use Target remote tools file viewer, if your device is attached in VS 2005. The remote file export option is a bit slow as it takes somewhere around 5 minutes. You will need to reboot the eBox and exit to DOS at the boot prompt and fix the file name to remove an extra ~1 that appears in the NK.BIN filename on the internal flash drive. After copying the new NK.BIN, use boot option 1 to boot the new local NK.BIN from the internal flash drive. You may also want to edit the initial eBox boot option menu to change display resolutions and even eliminate the need to select a boot option. Edit the DOS config.sys and autoexec.bat files on the internal flash drive to make any changes. The eBoxs DOS includes the EDIT program. LoadCEPC has several command line arguments to setup the initial display resolution and IP address that you may want to change. Read through the config.sys and autoexec.bat files. If you accidentally erase the critical files on the internal flash drive they can be restored using a bootable USB flash drive (see Appendix C). When you have a working OS that you want to boot directly on the eBox there are some other build options to consider. At some point, you will want to switch to a release build. In a release build the debug messages will not slow it down and the kernel is around 40% smaller since the debug messages are not included. When you switch to a release build the first time you will need to reenter the build options and environment variables and then build the release version. There also may be other components that you will want to leave out of a final release build. On a release build, for an OS that is not still connected to the desktop PC while running for debugging, be sure to uncheck the Enable KITL build option in the project properties window. If the desktop is not connected, with KITL enabled it will try to communicate with the desktop PC. It eventually times out, but the
376
process really slows down the target system. The Autolaunch subproject is useful to automatically start applications at boot time (see Appendix A).
11.7 Tools for Testing

In a production quality system, extensive testing will be required on the final OS build prior to the release of a new product. Testing software often takes as much time and effort as the original development process. The Windows Embedded CE 6.0 Test Kit (CETK) is a tool that you can use to test device drivers that you develop for the CE operating system. The CETK architecture is seen in Figure 11.7. The CETK incorporates a collection of command-line tests into a graphical user interface. The test tools in the CETK support the CPUs and hardware platforms that CE supports.
Development Workstation CETEST.EXE
CE 6.0 Device ActiveSync, KITL, Winsock Clientside.EXE
CETK Test DLLs Log
TUX.EXE
Kato.DLL
TUX Test DLLs
Figure 11.7 The CE Test Kit (CETK) Architecture
CETK provides multiple test kits. Each one provides a combination of CETK tests. Some CETK tests appear in multiple test kits, and some have a different
377
command line in each test kit. A test kit tests a specific category of CEbased devices. The name of the test kit indicates the category of target devices that the test kit tests, for example, generic CEbased devices, or Windows Mobile-based Pocket PCs and Smart phones. The CETK tool consists of a server application that runs on your development workstation seen in Figure 11.8 and client software that runs on each target device that you connect to the CETK. The CETK uses the Tux test harness, Kato logging engine, device driver loader, and Tux extender technologies to create and run test cases.
Figure 11.8 The CE Test Kit (CETK) UI running on the development PC.
The Application Verifier tool seen in Figure 11.9 assesses the stability of an application and detects common programming mistakes. The tool can detect and pinpoint memory leaks, handle leaks (such as critical sections and DLLs), and leaks in graphics device interface (GDI) objects. The tool can also detect some forms of heap corruption. Application Verifier attaches to an application or DLL and performs tests at runtime. With the tool, you may be able to diagnose subtle problems with an
378
application that would otherwise be difficult to diagnose on CE. It can check standalone applications, code that runs while the device is booting (when debugging is not possible), and on system files and drivers. Application Verifier is also extensible. Each test that Application Verifier runs is referred to as a shim. The tool inserts the shim into the code path between the calling function and the intended target function. A shim loads into the process space, and the kernel redirects calls from other libraries to the shim. A developer with a specific problem can write a shim to focus on that problem.
Figure 11.9 The CE Application Verifier tool.
The CE Stress tool provides an environment where functional units of a CE based run-time image are exercised for an extended period of time. You can use the CE Stress tool to verify that these functional units are stable after prolonged use. The CE Stress tool can help you identify whether a functional unit leaks memory, crashes, hangs, or fails to function after extended continuous operation.
379
In addition, the CE Stress tool verifies that functional units of a run-time image interact appropriately with one another in arbitrary combinations. It can also help you identify whether functional units deadlock, time out, or fail to operate when competing for resources. The CE Stress tool seen in Figure 11.10 includes a client/server harness and a collection of test modules. The harness runs the test modules in random sequence in a loop for an arbitrary duration
Figure 11.10 The CE Stress Testing tool.
The test modules perform functional testing. Each test module performs a number of tests on the functional part of the operating system (OS). The tests might include simple calls to an application programming interface (API) or might simulate a more complex scenario.
11.8 Porting an Existing Application to a Different OS

One task that many embedded system developers may face when designing a new embedded device is porting an existing application program originally written for a different OS to the devices new OS. It is not a simple as recompiling the applications source code. Even though the original source code may be available to be recompiled, extensive changes and effort may still be required. Any section of code that uses OS APIs will need to be changed to
380
use the APIs supported in the new OS. The amount of effort required depends on the nature of the application. Applications that only use the OS APIs for simple file operations are relatively easy to port. The basic file system APIs are similar on most operating systems. Applications with a complex user interface (UI) will be more complex to port as there is less similarity in these APIs between the different operating systems. Some applications with a complex GUI or that rely heavily on features unique to a specific OS will require so much effort to port that it may actually be easier to start over. Desktop applications may need to be redesigned for a smaller screen and devices without a full keyboard. Porting applications between the Windows desktop operating systems and Windows CE tends to be easier than a totally different OS, since Windows CE uses a subset of the desktop Windows OS APIs. Of course, any APIs not in this subset will need to be rewritten and mapped into supported APIs. There are even third party automated tools (i.e., wxWidgets) and special libraries available (ie., POSIX, Win32, WinSock) that can be used when originally developing an application that will help port it to several operating systems. It is also possible to manually produce one version of the applications source code that will run on multiple operating systems using the compilers preprocessor directives such as # define, #ifdef , #else, and #endif strategically placed the around the applications API calls. A single master # define statement is changed to select the OS. Unfortunately, this would also increase the applications initial software development time and effort. As an example, two useful open source applications described earlier in Chapter 9 that were ported as a student project are now available as Windows CE ports on the eBox52. GOCR is an optical character recognition program53. GOCR s input is a bit map ima ge file and the output is a text file. The eSpeak speech synthesis program converts a text file to human speech output in a *.wav file format 54. These applications both have a simple command line syntax and use the basic file system APIs making them easier to port. Since the underlying application code is somewhat involved, uses complex algorithms, they provide features not available in the OS, and they have a simple UI, these are the type of applications that make ideal candidates for porting.
11.9 Safety-Critical Coding

When writing code for an embedded device for safety-critical applications, extra precautions must be taken in addition to thorough testing. Safety-critical applications include control applications such as vehicles, aircraft, biomedical, and industrial control applications where a software failure can cause catastrophic results. Many projects and organizations have extensive safecoding rules and procedures.
52 53
http://users.ece.gatech.edu/~hamblen/489X/S08PROJ/OCR_TTS/ http://jocr.sourceforge.net/ 54 http://espeak.sourceforge.net/
381
A short list of the 10 top rules for safety-critical C\C++ coding typically includes the following: 1. Restrict all code to very simple control constructs no goto statements, direct, or indirect recursion. 2. Give all loop structures a fixed upper bound. This does not include nonterminating loops. 3. Do not use dynamic memory allocation after initialization. Memory allocators can sometimes have unpredictable behavior. 4. Functions should only be 1 page long. When humans cross a page boundary the error rate increases. 5. The average function should have around two assertions. Assertions must be used to check for anomalous conditions. 6. Declare all data objects at the smallest possible level of scope. 7. Each calling function must check the error codes returned and each called function must check for valid parameters. 8. The preprocessor must only be used for header files and simple macros. 9. The use of pointers must be limited. No more than one level of dereferencing. 10. All code must compile with all compiler warnings enabled. Code analysis tools should also be used. Code must be modified to eliminate all warnings (even seemingly incorrect warnings). Note that many of these rules indirectly suggest a very conservative approach on adopting new languages and new versions of software when writing safetycritical code. Some software license agreements also limit the use of software in such applications to limit the manufacturers legal liability exposure. As an example, defective software in biomedical devices has actually harmed patients and lead to multi-million dollar lawsuits. CE includes a version of the PREFast static code analysis tool. To enable the code analysis tool select a subproject, right click, select properties , and select the C\C++ tab. Find the code analysis setting line and change it from the default setting of no to yes. After the next build operation, a log report is generated with additional warnings. The code analysis tool can identify buffer overruns, semantic issues in the use of HRESULT, potential and actual memory use problems, and incorrect operator usage. In addition, it identifies many items that may simply be typos, but appear in code as format mismatches, inappropriate casting, and so on. CE also includes the security-enhanced C Runtime library and supports the use of safe string functions. The C Runtime Library (CRT) has been augmented to include secure versions of functions that pose security risks. The older, insecure versions of these functions are now deprecated, and their use results in compile-time warnings. In many cases, the safe string functions enable string operations to work securely with Unicode or extended character sets.
382
11.10 Licensing and IP issues for Embedded Systems

When developing a real product, intellectual property (IP) and licensing issues need to be resolved early in the design process. Legal agreements can be quite complex and require significant time to work out. Most OS vendors charge a few thousand dollars for the development tools, and then often charge a per device license fee. A few OS vendors charge a substantial one-time fee. Even designers using an Open Source license for a commercial product need to fully understand the legal implications of all of the license agreements. Many devices will also require additional applications and perhaps device drivers supplied by third parties. These also require additional legal agreements and licensing fees. In some cases, outside consultants work under contract to write new drivers or applications for the new device. All of these fees need to be determined and included in the product cost estimates and planning early on in the design process.
Figure 11.11 The CE Run-time License Assessment tool lists features present in an NK.BIN file.
The current commercial fees for CE 6.0 run around US $1000 for the development tools (including Visual Studio) and US $3 or US $16 per device.
383
The charges vary depending on the level of source code provided and applications licensed to the OEM. A special tool is available to determine the license type by examining the NK.BIN kernel file as seen in Figure 11.11. In Platform Builder, this tool is accessed by Tools Platform Builder 6.0 Run-time License Assessment Tool. This tool is also useful to list the features present in a previously generated NK.BIN kernel file.

The on-line help system in Visual Studio (filtered by Windows Embedded CE 6.0) contains additional information on bootloaders, the OAL, developing a BSP, SDK, and the CETK. The textbook, Building Powerful Platforms with Windows CE by James Y. Wilson and Aspi Havewala, although it was written for an earlier version of CE it is still a useful source of information on the boot loaders and the OAL. Additional explanations of the safety-critical coding guidelines can be found in The Power of 10: Rules for Developing Safety-Critical Code, Gerard Holzmann, IEEE Computer, June 2006. An interesting in depth discussion of software engineering coding practices and project management can be found in Code Complete, Second Edition and Software Estimation: Demystifying the Black Art by Steve McConnell.

1. Configure the eBox to automatically boot a local copy of your custom NK.BIN OS run-time image. Save the eBox factory default files first so that they can be restored later. 2. After configuring the eBox to automatically boot a local NK.BIN, configure the eBoxs registry to automatically run a sample application at startup. (see Appendix A) 3. Make a bootable USB flash drive that automatically boots from USB and runs a sample application at startup.(see Appendix B) 4. Modify your kernel so that it includes the remote display application. Boot the OS and run CERHOST to export the eBox display to the development system PC. (see Appendix C) 5. Run the PREFast static code analyzer on an application program or an OS source code example and examine the report file generated. Try to explain any problems uncovered.
384
6. Run the Run-Time License Assessment tools on your custom NK.BIN file. Save a screen capture image of the results. What license type is required? 7. Now that you understand the features and capabilities of CE 6.0 and the eBox 4300, use the eBox to build an interesting project of your own design.
385
Appendix A: Automatically running an Application

To automatically start running application(s) whenever CE starts, a new registry entry is required. When Windows Embedded CE begins loading, the kernel starts the file system and examines the HKEY_LOCAL_MACHINE\Init registry key to identify what applications to run. To control which applications run at system startup, create launch registry values. Launch registry values do not need to be sorted in the registry, although you can specify dependencies. You can specify up to 32 applications. Launch registry values have optional dependencies as denoted by the Depend nn registry value. Depend nn registry values specify applications that Windows Embedded CE must be running before the Launch nn applications run. Dependnn registry values begin with the keyword, Depend, followed by the same decimal number as the Launch nn registry value. The Depend nn registry values define an order in which Windows Embedded CE launches applications. One or more dependent applications can be specified per Dependnn value. Dependent applications are specified as a series of Words in hexadecimal notation. The registry entry is added to the OS Design Projects Project.reg registry file (not Platform.reg ). Here is an example: [HKEY_LOCAL_MACHINE\init] LAUNCH9x= myapplication.exe Depend9x=hex:0A,00,14,00,1E,00
Where x is a single digit (same on both lines and can be used only once). The typical basic application related dependency values are included. Applications launch in numeric order. The application can be included as a subproject in the OS Design Project or it can be loaded from non-volatile storage device such as the internal Flash drive, a USB Flash drive, or a CF card. The full path is required including device name for non-volatile storage. For the path, recall that in C/C++ to put a \ in a string you must use \\. Subprojects show up in the \ Windows directory on the device and are hidden by default. To setup the eBox to boot automatically, from the boot option menu exit to a DOS prompt. Modify your config.sys file so that it selects the proper LOADCEPC boot option without waiting for keyboard input. On the eBox edit config.sys. This starts the DOS editor (the mouse will not work here since no DOS mouse driver is loaded!). You can move around using the cursor keys. By changing the menudefault=LOCAL,15 line to the desired boot menu option is one easy way to do this. 15 on this line means a fifteen second delay before the default menu option is automatically selected, so use a smaller value to automatically boot faster. LOCAL is a label for one of the boot options in
386
autoexec.bat. Change it to the desired boot option. Once you have made the desired changes, use ALT+F, select Save and then Exit . To copy the new kernel file to the eBox for a local boot, see the section in Chapter 11, Moving a new OS image to the eBox for standalone booting. Unfortunately, while you can start an application with this technique, you cannot pass the application any command line parameters and wait until the network is fully configured and functioning properly. This is critical for network applications or applications that require command line options. To work around these issues, the Autolaunch application 55 has been developed that can start an application after the network is up, add a delay, and pass it command line parameters. It can also start multiple applications. When it runs it checks the registry startup folder, [HKEY_LOCAL_MACHINE\Startup], for applications to start after a specified delay. The Autolaunch application actually starts by using a [HKEY_LOCAL_MACHINE\init] registry entry as described earlier. Here is the default entry setup in the Autolaunch subproject s registry file: [HKEY_LOCAL_MACHINE\Init] "Depend99"=hex:0a,00,14,00,1e,00,32,00 [HKEY_LOCAL_MACHINE\Init] "Launch99"="AutoLaunch.exe" [HKEY_LOCAL_MACHINE\Startup] "Process1"="cerdisp -c" "Process1Delay"=dword:00001388 "Process2"="ConmanClient2.exe" "Process2Delay"=dword:0 So the first \Init registry key starts Autolaunch. Autolaunch then runs code that waits for the network to come up. It then walks through the registry \Startup entries and starts them after a specified delay time (in ms.). The default startup entries start both cerdisp -c (the CE remote display application described in Appendix B) and Corecons conmanclient2 (used to deploy code and debug). Edit the startup entries and time delays (in ms.) as required for your project and add more processes to start as needed for your application.
55
The Autolaunch subproject was developed by James Wilson and Mike Hall and is available free at www.learningce.com/Downloads/796.aspx . An article is also posted on http://blogs.msdn.com/mikehall .
387
If you disable Corecons network security feature, you do not need to use the second Corecon setup step to run the cmaccept program. Turning off security could put your target device at risk if it is connected to a publicly accessible network. The following registry setting can be used to disable Corecon network security:
[HKEY_LOCAL_MACHINE\System] CoreConOverrideSecurity=dword:1
For projects that are using the serial ports, you may also want to disable CEs serial debug messages. The /C:0 command line option on the LOADCEPC command found in the eBoxs Autoexec.bat file used to boot CE will disable the default serial debug messages sent out on COM1:. If you are using Windows Vista and upgraded the eBox to the most recent version of LOADCEPC for more reliable network downloads, the /C:0 option no longer works so use /C:4 instead. This sends serial debug messages to a non-existent COM4: port. In either case, some early debug messages will still appear on COM1: prior to the OS boot during a network boot operation. Any serial device that might lock up due to these early serial debug messages should be placed on COM2:.
388
Appendix B: The Remote Display & Desktop Applications

Remote Display - CERHOST If you do not have an extra monitor, keyboard and mouse to directly attach to the eBox or you are building a headless device (i.e., no display on eBox) you can use the CE remote display host application (CERHOST ) to view the Eboxs video display on the development PC as seen in the Figure below. A networking connection is required between the two computers.
Figure B.1 The CE remote host application exports the eBox display to the development PC.
For a quick demo of the remote host application, boot the factory default OS on the eBox 4300 (Use Boot Option 1). The remote display program, cerdisp is set to run automatically after the eBox boots. Next, start the CERHOST application running on the development PC. If you used the default install locations, it can be found on the development system PC in the directory, C:\WINCE600\PUBLIC\COMMON\OAK\BIN\I386.
389
On the PC in the CERHOST main application window, select File Connect. Find and select the eBox4300 target on the dialog window that pops up as seen in Figure B.2 and then click OK. A remote display window from the eBox similar to Figure B.1 should appear on the PC in a few seconds. When the CERHOST window is activ e, the PCs keyboard and mouse function as if they were attached to the eBox. If a keyboard, mouse and display is attached to the eBox they will also work. If you do not see an active target device to connect with, the firewall settings may need to be modified. Add an exception for the Platform Builder CE Remote Display Host, if not already enabled. This option may not appear in the firewalls list of programs until CERHOST is run the first time.
Figure B.2 The CE remote host application on the PC connects to the eBox4300.
To setup for a remote display on a headless device in a new OS build several simple steps are required: 1. If no keyboard will be present on the eBox later, modify your config.sys file so that it selects the proper LOADCEPC boot option without always waiting several seconds for keyboard input. On the eBox, exit to the DOS boot option. To enable recovery from errors in this step and to restore the eBox to the original factory setup later on, first copy the original config.sys to another filename (i.e., config.old). Edit config.sys by changing the menudefault=LOCAL,15 line to the desired boot menu option is one easy way to do this. (The mouse will not work in edit since no DOS mouse driver is loaded!) You can move around in the editor using the cursor keys and use the ALT+F key for menu selections. 15 on this line means fifteen second
390
2.
3.
4.
5.
6.
7.
delay before the default menu option is automatically selected, so use a smaller value. LOCAL is a label for one of the boot options (internal flash boot) in autoexec.bat. If you want to download new OS images over the network (instead of booting from flash) each time change the default settings. Add the Remote Display Application in the OS Design Projects catalog view. It is under Core OS CEBASE Core OS Services Debugging Tools. This includes the CERDISP process that exports and imports display information to the development PC. Using the cerdisp c command in the Autolaunch 56 subproject in your OS Design Project, start the eBox remote display application (see Appendix A for more Autolaunch information). This subproject adds code that automatically runs at startup to setup the remote display and the required communications. As an alternative, the cerdisp application can also be manually started on the eBox by typing cerdisp c in the command window. (assuming of course that it is not setup as a headless device). Build a new kernel with the features above and download it to the eBox. The CERDISP application should start running on the eBox when it boots. If you still have a monitor attached to the eBox, CERDISP shows up as a small multicolored globe type icon on the bottom right of the display when it is running as seen in Figure B.1. The remote display host application supports a maximum color depth of 16bpp and the default is 32. The default values are all OK, unless you changed the display resolution from the factory default value. Start the CERHOST application running on the development PC. If you used the default install locations, it can be found in the directory C:\WINCE600\PUBLIC\COMMON\OAK\BIN\I386. You may need to modify the firewall settings and add an exception for the Platform Builder CE Remote Display Host, if not done earlier. This option may not appear in the firewalls list of programs until it is run the first time. On the PC in the CERHOST application window as seen in Figure B.1, select File Connect. Find and select the correct eBox4300 number as seen in Figure B.2 and then click OK . A remote display window from the eBox should appear on the PC in a few seconds. When the CERHOST window is active, the PCs keyboard and mouse function as if th ey were attached to the eBox.
56
The Autolaunch subproject was developed by James Wilson and Mike Hall and is available free at http://www.learningce.com/Downloads/796.aspx. An Autolaunch article is also posted on the web at http://blogs.msdn.com/mikehall.
391
Remote Desktop - CETSC The Remote Desktop 57 catalog item features under Core OS CEBASE Applications End User can be added to the eBox OS build for the reverse situation where you wa nt to export the PCs display back to the eBox. Running the Cetsc application on the Ebox, one can connect to and remotely control a Microsoft XP or Vista PC as seen in Figures B.3 and B.4. The Remote Desktop service will need to enabled on the PC. It is possible to do both Remote Display and Remote Desktop operation at the same time.
Figure B.3 When CETSC is started on the eBox, this dialog box appears to connect to a PC using Remote Desktop
Figure B.4 The eBox display is seen connected to a PC running Windows XP using Remote Desktop.
57
http://msdn.microsoft.com/en-us/library/ms879793.aspx has additional details on Remote Desktop and http://www.golod.com/2005/10/enabling-multiple-remote-desktop-sessions-in-windows-xp-professionaland-media-center-edition-2005/ has details on enabling multiple remote desktop connections.
392
Appendix C: Making a bootable USB drive for the eBox

If you accidentally erase critical files on the eBoxs internal flash drive and it no longer boots, or want to boot your new OS from a USB drive, a bootable USB drive is needed. To boot from an external USB drive, the USB drive needs to be reformatted in a special way (FAT) and it needs a copy of the Win98 (DOS 7.0) boot files. Earlier versions of the DOS boot files do not support USB. A bootable USB drive may also be required to perform any future BIOS updates for the eBox when they become available. Step 1: First you will need the Win98 (DOS 7.0) boot files on a floppy on the development system PC. You can also get a program to create this boot floppy from BootDisk.com or insert a floppy disk, open explorer, right click on A:, choose Format, and check the option to create an MS-DOS startup disk. Step 2: Plug the USB drive (64MB - 2G) into the development system PC and reformat it to make it bootable (any existing files on the USB drive will be destroyed). A special Windows XP utility the HP USB Disk Storage Format Tool from HP is available free at the following URL, http://www.pcworld.com/downloads/userreviews/fid,64963/userreviews.html. It is used on the development PC to reformat the USB drive and copy the boot files to it. Install and then run the HP USB Disk Storage Format Tool. Select your USB drive, then select FAT (not FAT32) for the file system format and click Create a DOS startup disk. It then prompts for the location of the Win98 boot files from step 1. (NOTE: Users have reported that a few brands of USB drives may not work correctly as boot drives. In case of problems with the HP tool, a more complex alternative USB reformat and boot setup process can be found at http://www.weethet.nl/english/hardware_bootfromusbstick.php ) Step 3: Next copy all of the files you need to the new bootable USB drive. A copy of all of the eBox 4300 factory default boot files for Windows CE 6.0 is available from ICOP or can be copied from any functional eBox. These are handy to restore an eBox's internal Flash drive to the factory default status. Step 4: Plug the USB drive into the eBox. The BIOS option to boot from USB does not appear unless the USB drive is plugged into the eBox. Step 5: Turn on the eBox and hit the delete key quickly to enter the BIOS setup mode. In the BIOS Advanced CMOS Settings menu find the "1st BOOT Device entry, USB RMD-FDD should now appear as a boot option and select it as the first boot device. Hit ESC to exit back to the main BIOS menu. Save the new BIOS settings.
393
Step 6: Restart or Power off and then power on the eBox. It should now boot from drive A: , the USB drive (CE -USB Storage). If you need to repair/replace any files on C: (the eBoxs internal flash drive) you can use DOS command mode to copy or boot Windows CE first and use it to copy files from A: (CE -USB Storage) to C: (CE hard disk or DOS). Once you have a bootable USB Flash drive, you may find it more convenient to always boot from the new USB drive and leave the internal flash drive setup with the factory default files. The Autolaunch subproject described in Appendix A can also be used to automatically start applications.
394
Appendix D: Information on the CD-ROM Design Files

The CD-ROM autoruns its index.html web page that includes additional instructions and provides web links to locations to download other software needed such as the eBox BSP, any text errata, and software updates to this material. The CD-ROM accompanying this text includes all of the texts code examples in the directory \Designs. The Subprojects_C_C++ directory includes C/C++ examples setup as subprojects and the Projects_Csharp directory contains C# examples setup as projects. Using the CD-ROM, copy the project files to your machines hard drive to the CE 6.0 OS design directory (default install path is C:\WINCE600\OSDesigns\MyOS). The C/C++ examples are setup as subprojects. Subprojects can also be copied to any new OSDesign by copying the subprojects directory and all of its contents to the MyOS\MyOS directory. After copying files, the new subproject must then be added to the design using the add existing subproject command. C# examples are standalone projects. To keep the size reasonable, all OS design projects have been cleaned. Each project will need to be re-built using Build Build Solution (see Chapter 7) to generate a new kernel file (NK.BIN). The CE Licensing terms do not allow the free distribution of OS kernels (NK.BIN files), posting of NK.BIN files on public web sites, or public release of the CE source code without permission. C/C++ examples are included as subprojects (located after the OS Design) in the solutions view. After building and downloading the new kernel, you can run these subproject example programs using Target run programs or manually run them from the eBox. C# examples are all standalone projects in order to support debugging. C# example projects need to be deployed to the target system (see Chapter 7) after the OS boots, or copied to non-volatile storage media on the target device using a flash drive or CF card.
395
Appendix E: Common I/O connector pin assignments

Several of the more commonly used I/O connector pin assignments are shown in this appendix. These are handy if you need to make a custom cable or attach a test instrument to probe signals. The view is from the I/O connection pin side of the connector (i.e., from panel on back of eBox and not inside where the individual wires attach). On the eBox, the PS/2 connector is designed for use with a PS/2 Y cable with two connectors, one for the keyboard and one for the mouse. The eBox does not have a parallel printer connector, it is included here only since it is very commonly found on other devices. Most signals use the standard 5V digital logic levels. Recall that the COM serial port signals use special RS-232 voltage levels that can be as high as +12V and as low as -12V. The VGA red, green, and blue video color signals are low voltage analog signals. Signal pairs that end in + or - operate in differential mode (i.e., the signal is the voltage difference between the two signal pairs). On many connectors, small pin numbers can be found molded into the plastic case surrounding each pin. If only one mark is found on a connector or a stripe on a ribbon cable going to a connector, it is typically pin 1.
VGA 15-pin D-sub Connector
Pin # Signal Name Pin # Signal Name Pin # Signal Name
5 1 6
1 2 3 4 5
MRed MGreen MBlue NC GND
6 7 8 9 10
GND GND GND NC GND
11 12 13 14 15
NC Vcc HSYNC VSYNC Vcc
15
11
USB - For connection to external USB

1 4
Pin # Signal Name Pin # Signal Name Pin # Signal Name 1 2 Vcc USB 3 4 USB+ GND 5 6 NC NC
COM 9-pin D-sub Connector

1 5
Pin # Signal Name Pin # Signal Name Pin # Signal Name 1 DCD 4 DTR 7 RTS 2 3 RXD TXD 5 6 GND DSR 8 9 CTS RI
PS/2 - Keyboard and Mouse 6-pin Mini-Din

2 6 5 1 3 4
Pin # Signal Name Pin # Signal Name Pin # Signal Name 1 KBCLK 3 GND 5 PMDATA 2 PMCLK 4 KBDATA 6 SB5V
396
eBox Power - DC-IN (5V) 3-pin Mini-Din Lock Pin

1 3 2
Pin # Signal Name Pin # Signal Name Pin # Signal Name 1 5VDC 2 GND 3 NC
Ethernet - RJ-45 Connector

Pin # Signal Name Pin # Signal Name Pin # Signal Name 1 2
8 2, 1
FTXD+ FTXD FRXIN+
4 5 6
NC NC FRXIN
7 8 9
NC NC
Parallel Printer (LPT) - DB25 Pinout (DB25 Male Connector)

13
Pin # Signal Name Pin # Signal Name Pin # Signal Name 1 2 3 4 5 6 7 8 9 Strobe Data bit 0 Data bit 1 Data bit 2 Data bit 3 Data bit 4 Data bit 5 Data bit 6 Data bit 7 10 11 12 13 14 15 16 17 18 Acknowledge Busy Paper out Select Autofeed Error Reset Select (Dir) Signal groun d 19 20 21 22 23 24 25 --Signal ground Signal ground Signal ground Signal ground Signal ground Signal ground Signal ground
25
14
397
Index
.
.NET Compact Framework, 197, 285 Sleep, 256 SmsClose, 306 SmsOpen, 306 SmsReadMessage, 306 SmsSendMessage, 306 Synchronization Primitives, 157 USBDeviceAttach, 362 USBInstallDriver, 362 USBUninstallDriver, 362 WaitCommEvent, 258 WaitForSingleObject, 270 wavein, 280 waveout, 280 WRITE_PORT_UCHAR, 261 WriteFile, 256 ASCII, 57 ASIC, 44 ASP.NET, 300 Assembly Language, In-line, 45, 267 AT command set, 303 ATL, 138 Audio I/O, 78 Autolaunch, 386
A
A/D hardware, 74 AC devices, 84 AC97, 78 Active server pages (ASP), 300 ActiveX, 138 Address Decoder, 37 AGP, 50 Analog I/O, 74 API Calls in CE AllocPhysMem, 350 CeGetThreadPriority, 151 CeSetThreadPriority, 151 CloseHandle, 256 Console.WriteLine, 286 CreateEvent, 270 CreateFile, 256 CreateProcess, 301 CreateSemaphore, 276 CreateThread, 270 DispatchMessage, 282 EnterCriticalSection, 275 FreePhysMem, 350 GetCommStatus, 258 GetMessage, 282 GetProcAddress, 295 GetThreadContext, 151 GetTickCount, 275 GPSCloseDevice, 316 GPSdemo, 316 GPSGetDeviceState, 316 GPSGetPosition, 316 GPSOpenDevice, 316 HalAllocateCommonBuffer, 350 HalFreeCommonBuffer, 350 HalTranslateSystemAddress, 350 InterruptDisable, 345 InterruptDone, 346 InterruptInitialize, 346 LeaveCriticalSection, 275 LoadLibrary, 295 PlaySound, 280, 301 Random, 275 READ_PORT_UCHAR, 261 ReadFile, 256 SetCommEvent, 258 SetCommStatus, 258 SetEvent, 270 SetThreadContext, 151
B
Baud Rate, 65 bib file, 188 Bluetooth, 101, 182 Board Support Package, 185 Bootable USB drive, 392 BSP, 185 Build System Configuration Files, 187 buzzers, 80
C
C#, 285 C# Example Console Application, 286 Create Remote GUI, 324 Phidgets, 293 Serial Port, 287 Windows Application, 237 C/C++ Example File System I/O, 256 In-Line Assembly Language, 267 Producer Consumer Problem, 274 Serial Port I/O, 258 Using Audio APIs, 280 Using CEDDK I/O Functions, 261 Using Phidgets, 295 Using Threads and Synchronization, 270, 274 Windows Application, 281
398

Embedded OS, 23 Embedded Processors, 23 Embedded System Design Process, 28 Embedded System I/O Architectures, 36 Embedded System Memory Technologies, 29, 32 Embedded Systems, 18 Enfora modem, 302 Environment Variables used for Paths, 266 ESpeak, 300 Ethernet Network Interface, 94 Events, 270
Calling C/C++ functions from C#, 288, 302, 310, 313 Camera Driver for CE, 114 CameraDshowApp, 298 CamTest2, 297 CAN Bus Interface, 85 CaptureFramework, 298 CardBus, 50 Catalog, 185 Catalog Item, 184 CD-ROM Design Files, 394 CE Build System, 186 CEDDK, 46, 261 CEFileWiz, 293 Cell Phone Modem, 120 Cell phone radio, 302 CellCore, 183 CEPC, 187 CERHOST, 388 CETK, 376 CETSC, 391 CIL, 285 CLR, 285 Code Division Multiple Access (CDMA), 183 COM, 138 Component, 185 Config.bib file, 189 Configuration, 185 Corecon, 241 CriticalSection, 275 CSMA/CD, 97
F
FCL, 285 File Systems, 148 FPGA, 44 FTP server, 298
G
Garbage collection, 286 General Packet Radio Services (GPRS), 183 Global Positioning System (GPS), 313 Global System for Mobile Communications (GSM), 183, 303 GOCR, 319 GPIO, 45, 65 GPS Intermediate driver, 316 GSMSP, 306 GWES, 150
D
D/A hardware, 74 DC motor, 81 DCD, 67 DCE, 67 Deploying C#, 241 Design files for CE, 394 Design Template, 184 Device Driver, 165 Device Driver Example Code, 351 Device Drivers, 338 Differential GPS, 313 DirectShow, 298 Disabling Serial Debug Messages, 387 DMA, 55 Driver circuit, 80 DSR, 67 DTE, 67 DTR, 67
H
Handwriting Recognizer Engine (HWX), 312 Hard Real-Time, 21 Hardware Debug Tools, 372 Hardware Platform, 185 H-bridge, 81 Hive Based Registry, 169 Hypertext Markup Language (HTML), 298 hysteresis, 84
I
I/O connector pin assignments, 395 I/O handshaking, 52 I/O Port, 41 I/O Transfers, 52 I2C Bus Interface, 71 IEEE Standard 1149.1, 369 1284, 65 802.11, 101 802.15.1, 101
E
eBox, 106 eBox network setup for CE Development, 216

802.15.4, 101 802.3, 94 Input Port, 42 Interfacing motors and relays, 80 Internet Server Application Program Interface (ISAPI), 300 Interprocess Communication in CE, 160 Interrupts, 53 Interrupts in CE, 161 IrDA, 182 iRobot Create, 321 ISA Bus Interface, 36 PCB, 118 PCI Bus Interface, 46 PCI Express, 50 PDD, 165 Phidgets, 113, 292 PhidgetsDrivers, 293 Phonemes, 300 Platform Builder, 183 Platform Invoke (P/Invoke), 288 Platform.bib file, 189 Porting Applications, 379 power transistor, 81 Priority inversion, 154 Priority Levels, 153 Processes, 150 Programmable Automation Controllers, 85 Programmed I/O, 52 Project, 185 PS/2 keyboard, 68 PS/2 mouse, 70 PSoC, 115 PWM, 81
399
K
keyboard. See PS/2 keyboard
L
LCD touch panels, 310 LIN Bus Interface, 87 LOADCEPC, 387 Logitech QuickCam, 114, 297
R
Radio Interface Layer (RIL), 183 Real-Time, 21 Real-Time OS, 22 Real-Time Performance in CE, 155 reg file, 188 Registry, 168 relays, 80 Remote Desktop, 391 Remote Display, 388 Remote Tools, 272 Kernel Tracker, 273 Process Viewer, 273 Zoom, 274 Robot base for eBox, 121, 123 Robot design projects, 321 Robotics Connections Stinger robot kit, 322 Robotics Studio, 123 RS-232 Voltage Levels, 66 RS-232C Serial I/O Interface, 65 RTOS, 22, 155 RTS, 67 Run-Time Image, 184
M
Make Binary Image Tool, 188 MDD, 165 Memory Architecture, 141 MFC, 138 MMU, 30 Module, 185 mouse. See PS/2 mouse Multitasking, 152
N
National Marine Electronics Association (NMEA), 315
O
OAL, 369 OMAC, 22 Optical character recognition (OCR), 318, 380 optical isolation, 84 OS Design, 184 Output Port, 43
S
Safe Coding, 380 Scan Codes, 68 Scheduling, 152 SDK, 232 Semaphore, 276 Sensors, 116
P
Parallel I/O Interface, 64 Parallel Port, 45 Parity Bit, 66
400
Serial Debug Messages, 110, 217, 387 Serial Interface, 65 Servos, 119 Short Message Service (SMS), 303 Short Message Service support (SMS), 183 SIE, 77 SIM Toolkit, 183 Soft Real-Time, 21 Software Installation, 196 Software Updates, 198 Software-based input panel (SIP), 312 solenoids, 80, 81, 84 solid state relay, 84 Sources File, 265 Speak, 301 speakers, 80 Speech Synthesis, 300, 380 SPI Bus Interface, 70 stack size, 321 Start Bit, 66 stepper motors, 83 Stop Bit, 66 Stream Interface Driver, 339 Subproject, 185 Subscriber Identity Module (SIM), 183 Synchronization Primitives, 157 Sysgen, 194
U
UART, 66, 262 Unicode, 57 USB device driver, 362 USB Interface, 75 USB microcontroller, 76 USB Video Standard, 297 USB Web Camera, 114, 296 USB, booting from, 392 User Mode Driver, 166
V
Verilog, 44 VHDL, 44 Video Electronics Standards Association (VESA), 312 Virtual Memory, 31, 142 Voice over Internet Protocol (VOIP), 183 Vortex86 SoC, 110
W
WAAS, 313 Web Camera, 114, 296 Web Server (HTTPD), 298 webcam.dll, 297 WiFi, 101, 183 WiFi Card for eBox, 120 Win32, 138 Windows CE, 136 Wireless Application Protocol Support (WAP), 183 Wireless Network Interfaces, 101
T
Target Device, 185 TCP/IP, 98 Telephony APIs (TAPIs), 310 Telephony Service Provider (TSP), 183 Telnet Server, 298 Testing in CE, 376 Text-to-Speech (TTS) engine, 300 Threads, 150 Time Slice in CE, 153 Touch Screen (Stylus), 312 Transcriber Handwriting Recognition, 312 triacs, 84 Tristate output, 37
X
X86 System, 51 Xenarc LCD, 311
Z
ZigBee, 101

Intro To Embeddedwith Win Embed CE2 ND Ed

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Intro To Embeddedwith Win Embed CE2 ND Ed

Hochgeladen von

Copyright:

Verfügbare Formate

INTRODUCTION TO EMBEDDED SYSTEMS

USING WINDOWS EMBEDDED CE

Introduction to Embedded Systems using Windows Embedded CE

INTRODUCTION TO EMBEDDED SYSTEMS

1.10 Laboratory Exercises _________________________________________________ 33

2 Introduction to Embedded System I/O Architectures _______________ 36

3 I/O Interfacing Standards for External Devices ___________________ 64

4 Network Interface Standards __________________________________ 94

Introduction to Embedded Systems using Windows Embedde d CE

5 The eBox 4300 Embedded Computer System ____________________ 106

6 Architecture of a Real-Time Embedded OS - CE 6.0 R2 ___________ 136

7 Building a customized CE Kernel _____________________________ 194

8 Application Programming in CE ______________________________ 256

Introduction to Embedded Systems using Windows Embedde d CE

9 Adding External I/O Devices and New Features _________________ 292

10 Introduction to I/O Device Drivers ____________________________ 338

11 Advanced OS Topics________________________________________ 366

Introduction to Embedded Systems using Windows Embedde d CE

Introduction to Embedded Systems using Windows Embedded CE

Introduction to Embedded Systems using Windows Embedde d CE

Table P.1 A Lecture Schedule for a Semester-based Embedded Systems Class

Chapters 1-11 Chapters 1-11

Introduction to Embedded Systems using Windows Embedded CE

Table P.2 A Lecture Schedule for a Quarter-based Embedded Systems Class

Introduction to Embedded Systems using Windows Embedde d CE

Download the thirty minute design project video at http://users.ece.gatech.edu/~hamblen/videos/Design_Projects_0023.wmv

Introduction to Embedded Systems using Windows Embedded CE

Introduction to Embedded Systems using Windows Embedde d CE

Introduction to Embedded Systems using Windows Embedded CE

Introduction to Embedded Systems using Windows Embedded CE

1 Introduction to Embedded Systems

1.1 Examples of Embedded Systems

Introduction to Embedded Systems using Windows Embedde d CE

Introduction to Embedded Systems using Windows Embedded CE

Communications Consumer Electronics

Introduction to Embedded Systems using Windows Embedde d CE

1.2 Real-Time Operating Systems

External Input Event

Process New Data

Output Response to Event

System Response Time

Introduction to Embedded Systems using Windows Embedded CE

Introduction to Embedded Systems using Windows Embedde d CE

1.3 Operating Systems for Embedded Systems

1.4 Processors and Software used in new Embedded System Designs

Introduction to Embedded Systems using Windows Embedded CE

Figure 1.4 Processor bit size used in new embedded designs.

Introduction to Embedded Systems using Windows Embedde d CE

More Than 5 0.00% 10.00% 20.00% 30.00% 40.00% 50.00% 60.00%

Figure 1.6 Number of Processors in each Embedded Device

Introduction to Embedded Systems using Windows Embedded CE

Commercial OS None Internally Developed Open Source 0.00% 5.00% 10.00%15.00%20.00%25.00%30.00%35.00%40.00%45.00%

Figure 1.7 Use of Real-Time OS Kernels in New Embedded Designs .

Introduction to Embedded Systems using Windows Embedde d CE

Figure 1.8 Commercial Operating Systems used in New Embedded Designs.

Figure 1.9 Programming Languages used in Embedded Devices.

Introduction to Embedded Systems using Windows Embedded CE

1.5 Introduction to the Embedded System Design Process

Introduction to Embedded Systems using Windows Embedde d CE

1.6 Factors in the Pricing of Embedded Devices

Figure 1.11 Elements that contribute to the list price of a product.

Introduction to Embedded Systems using Windows Embedded CE

1.7 Development of an Embedded Systems Design