1

Introduction to Embedded Systems Using Windows

Embedded CE

A Tutorial Approach withLaboratory Exercises for

Windows Embedded CE 6.0 and the eBox 2300 SoC Embedded Computer

© Copyright 2007 Georgia Institute of Technology and James O. Hamblen, Portions © Copyright 2006 Microsoft Corporation, reprinted with permission from Microsoft Corporation. ActiveSync, ActiveX, Developer Studio, DirectX, Microsoft, MS-DOS, Visual Basic, Visual C++, Visual C#, Visual Studio, Wind32, Windows, Windows NT, Windows XP, 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.

Chapter 1: Introduction to Embedded Systems

2

What is an Embedded System?

• Any electronic device that incorporates a computer in its implementation.

• The user of the device is often not even aware that a computer is present.

• The computer is used primarily to provide flexibility and to simplify the system design.

Some Interesting Examples of Embedded Systems:

3

Product: Sonicare Elite toothbrush.

Microprocessor: 8-bit

Has a programmable speed control, timer, and charge gauge

Product: Any PC Mouse, Keyboard,

or USB Device

Microprocessor: 8-bit

MicrocontrollerInside view of a Microsoft Mouse

4

Product: Any Disk Drive

Microprocessor: Dual 32-bit Marvel ARM

SOC & mixed signal DSP

Product: Any Printer

Microprocessor: Intel, Motorola, or ARM 32-bit RISC

5

Product:Vendo Vue 40 vending machine.

Microprocessor: Two 16-bit Hitachi H8/300H Processors

A robot hand dispenses items

Product: Creative Labs Zen Vision:M Video & MP3 Player.

Microprocessor: TI TMS320 DSP

6

Product: Cannon EOS 30D Digital Camera

Microprocessor: DIGIC II Image Processor

Product: NASA's Twin Mars Rovers.

Microprocessor: Radiation Hardened20Mhz PowerPC

Commercial Real-time OS

Software and OS was developed during multi-year flight to Mars and downloaded using a radio link

Photograph courtesy of NASA/JPL CALTECH

7

Product: Sony Aibo ERS-7 Robotic Dog.

Microprocessor: 64-bit MIPS R7000.

OS: Aperios -Sony’s Real Time

OS

Used in Robocup Soccer Teams

Product: Radiant Systems Point-of-Sale

(POS) Terminal

Microprocessor: Intel X86 Celeron

OS: Windows XP Embedded

Look for one next time you order fast food!

8

Product: High End Systems DL2 Digital Media Server

Microprocessor: X86

OS: Windows XP Embedded

Used for lighting effects in shows and rock concerts

Product: Microsoft’s Smart Personal Object

Technology (SPOT) watch

Microprocessor: 32-bit ARM with FM Radio

Chip

Downloads News using extra bandwidth on FM radio stations in major

cities

9

Product: Agilent Oscilloscope

Microprocessor: X86

OS: Windows XP

Product: Tektronix Logic Analyzer

Microprocessor: X86

OS: Windows XP

10

Product: Kuka Industrial Robot

Arm

Microprocessor: X86

OS: Windows CE OS & Others

Kuka robot arms welding a Mercedes

Product: Pavion Portable GPS Navigation &

Multimedia System

Microprocessor: ARM , DSP

OS: Windows CE

Also plays MP3s and Videos

11

Product: HP iPAQ Pocket PC

Microprocessor: Marvel XSCALE

(ARM)

OS: Windows CE

Product: Motorola Q Pocket PC Phone

Microprocessor: TI OMAP (ARM+DSP)

OS: Windows Mobile 5.0(Windows CE OS)

12

Product: HP iPAQ Pocket PC Phone

Microprocessor: TI OMAP (ARM+DSP)

OS: Windows CE

Product: Atronic Slot Machine

Microprocessor: X86

OS: Windows CE

Slots are networked to a casino’s back office

computer system. State Gaming agencies audit code and payoff odds.

13

Product: Dresser Wayne Ovation iX Gas Pump

Microprocessor: Marvel Xscale (ARM)

OS: Windows CE

Displays video ads &is networked to a gas station’s back office

computer system. Also has remote maintenance features.

Product: Bernina Artista 200 Sewing Machine

Microprocessor: Marvel StrongARM

OS: Windows CE

Can download new images from the internet and sew them

14

Product: LG VoIP Phone

Microprocessor: Freescale i.MX21

ARM

OS: Windows CE

Product: Gumstix Connex Embedded Computer

Board(size of a stick of gum)

Microprocessor: Marvel 400Mhz Xscale

OS: DrumStix community project developing a BSP

for Windows CE

Great low-power CE target board for student projects.

15

Product: ICOP eBox 2300 System on a Chip (SoC) PC 4.5 x 4.5 x 1.5 inches

Microprocessor: 200Mhz Vortex86 (X86)

OS: Windows CE

Low-cost CE target board for student projects

XRAY, MRI, and Ultrasound imaging systems, patient monitors, heart pacers.

Biomedical

Communication Satellites, network routers, switches, hubs.

Communications

Engine control, anti-lock braking systems, traction control systems, air bag controls, heating and air conditioning controls, GPS mapping, Satellite Radio, On-board Diagnostics.

Cars

Aircraft autopilots, avionics and navigation systems, automatic landing systems, guidance systems, engine controls.

Aircraft & Military Systems

More Examples of Embedded Systems

16

Keyboards, mice, printers, scanners, displays, modems, hard disk drives, DVD drives, graphics cards, USB devices.

Computer I/O devices

Data acquisition systems, oscilloscopes, voltmeters, signal generators, logic analyzers.

Electronic Instrumentation

Elevator controls, surveillance systems, robots, CNC machines, Programmable Logic Controllers, industrial automation and control systems.

Industrial Equipment

Microwave ovens, dishwashers, DVD players, televisions, stereos, security systems, lawn sprinkler controls, thermostats, cameras, TVs, clock radios, answering machines, satellite or cable box, appliances.

HomeElectronics

Examples of Embedded Systems - Continued

Cell phones, portable MP3 players, Video players, Personal Digital Assistants (PDAs), electronic wrist watches, handheld video games, digital cameras, GPS systems.

Personal Devices

Industrial robots, autonomous vehicles, space exploration robots (i.e. Mars robots)

Robots

Video Game systems, “Aibo”, "Furby“, and “Elmo” type robot toys.

Toys

FAX machines, copiers, telephones, calculators, cash registers.

OfficeMachines

Examples of Embedded Systems - Continued

17

Importance of Embedded Systems

• Ratio of Embedded Devices / Desktop PCs is greater than 100

• The typical house may contain over 50 embedded processors

• A high-end car can have over 50 embedded processors

• Embedded systems account for the most of the world’s production of microprocessors!

Challenging System Design Goals• Reliability

– Can’t Crash, may not be able to reboot– Can’t update many embedded devices

• Performance & Power– Real-time issues in many applications– May need to run on battery power– Limited memory and processing power

• Cost– Fast time to market on new products– Consumer Products are very cost competitive

18

Real-Time System• A real-time system responds to events.

Process New Data

External Input Event

External Output Event

Example: An Automobile airbag system.When the airbag’s motion sensors detect a collision, the system needs to respond by deploying the airbag within 10ms or less.

– or the system fails!

• A real-time system must respond to external inputs and produce new outputs in a limited amount of time.

• The response time needs to be bounded. Response times that are too long cause real-time systems to fail.

• General purpose desktop Operating Systems are not designed for real-time use

• Real-time Operating Systems need to be initially designed for real-time use in order to provide fast bounded response times

Real-Time System

19

Hard & Soft Real-Time Systems• Soft Real-Time System

– Critical tasks get priority. Normally meets the real-time response constraint.

– Example: A Multimedia Player could skip a video frame or audio sample occasionally and a user might not notice.

• Hard Real-Time System– A new output response must be computed by the specified time

bound or the system will fail.– Examples: In an aircraft flight control system when the pilot moves

the control yoke, the flight control surfaces need to move quickly in response or the aircraft could crash.

– Virtual memory page swapping and garbage collection routines needed for object oriented languages can cause problems in Hard Real-Time systems

Multi-Tasking and Scheduling• Many embedded systems are real-time

systems with several inputs and outputs. Multiple events are occurring independently.

• Programming is simplified by 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.

• OS provides Synchronization Primitives

20

Product: TMIO ConnectIO Oven

OS: Windows CE

Also refrigerates food before cooking and is controlled over the internet or via phone

Internet Oven: Example Tasks

How would all of these tasks be scheduled?

Is synchronization needed anywhere?

What networking and communications support is needed?

Would an OS help?

•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 (for timed cooking)•Update time and temperature display on front panel•Check for Internet communications and handle messages•Check for Phone communications and handle messages

21

Why have an OS in an embedded device?

• Support for multitasking, scheduling, and synchronization

• Support for a wide range of I/O devices

• Support for file systems

• Scheduling and buffering of I/O operations

• Support for networking

• Memory management

• Support for graphics displays

• Security and Power Management

Example: A recent 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 on their own!

• Typical Embedded OS license fees are a few dollars per device – less than a desktop OS

• Some very simple low-end devices might not need an OS – but new devices are getting more complex

Why have an OS in an embedded device?

22

Memory in an embedded device

• Need both volatile and non-volatile memory

• Flash memory frequently used instead of Disks– Less power, smaller, and more reliable

• Store OS and applications in Flash memory

• Boot from Flash Memory at power up

• Flash is very slow compared to RAM– Copy code to SRAM or SDRAM to execute?

• Need development tools that support code storage and execution in ROM

Typical Software Development Tools Used for Embedded Applications

•Compiler - compile C/C++ and in-line assembly language

•Linker – links compiled application code, OS, and runtime libraries

•Memory Image tools – tools to place code in non-volatile memory at a given physical memory address

•Debugger – tool to debug OS and applications programs

•Loader – load OS at power on and applications. Also a tool to download new code from the development system is typically provided.

23

What is actually being used in New Embedded Designs?

• What Types of Processors are used?

• What Operating Systems are used?

• What Programming Languages are used?

• Will examine data from a 2006 Market Survey of design engineers by EETimes and Embedded Systems Design Magazine

Processor Bit Size Used in New Embedded Designs

0.00% 10.00% 20.00% 30.00% 40.00% 50.00% 60.00%

4-bit

8-bit

16-bit

32-bit

64-bit

Data was derived from EETimes and Embedded Systems Design Magazine 2006 Embedded Market Survey

24

Processor Architectures Widely Used in New Embedded Designs

• ARM• X86• PowerPC• MIPS• Xscale (ARM)• Renesas SuperH

32-64 bit Annual Processor Sales

0.00% 5.00% 10.00% 15.00% 20.00% 25.00% 30.00% 35.00% 40.00%

PowerPC

SuperH

MIPS

X86

ARM

Processor Sales Volume

Based on 2002 sales data

25

Processor Selection Issues• Software Support

– OS, Compilers, Debug Tools, Applications• Price• Performance• Power

– Battery Life (MIPS/Watt), Cooling (Fan?)• Desktop PC 100 W vs. Battery power 200 mw

• Availability– Long term availability, Multiple Vendors?

ARM Processors• 32-bit RISC low-power design from an English IP

company, ARM ltd (Advanced RISC Machines) http://www.arm.com/

• ARM’s processor designs are licensed to over 100 chip manufacturers. ARM does not make chips.

• Used in many devices such as Cellphones, iPod Nano, Cameras, Handheld Games, HDTVs, and Set-Top boxes. 80% of ARM processors are in phones

• Good performance/power makes it a very popular choice in low power and battery operated devices.

• ARM’s thumb instruction subset is coded into 16-bits and decompressed on-the-fly to full 32-bit instructions. Can switch from 16-bit to 32-bit instructions on the sub-routine level.

26

X86 (IA-32) Processors• Based on the Intel X86 CISC instruction set used in

processors in PCs since the mid 1980s• Low cost due to widespread use in PC technology• Processors and support chips are available from multiple

vendors• A wide processor performance range is available• Most X86 processors for desktop PCs have been

optimized for performance and not low power• The major desktop PC processor vendors (Intel, AMD)

are moving on to newer designs and 64-bit architectures –but other manufacturers are making X86 processors for embedded devices

Number of Processors Used in New Embedded Designs

Data was derived from EETimes and Embedded Systems Design Magazine 2006 Embedded Market Survey

0.00% 10.00% 20.00% 30.00% 40.00% 50.00% 60.00%

More Than 5

3-5 Processors

2 Processors

1 Processor

27

Use of Real-Time OS Kernels in New Embedded Designs

0.00% 5.00% 10.00% 15.00% 20.00% 25.00% 30.00% 35.00% 40.00% 45.00%

Open Source

Internally Developed

None

Commercial OS

Data was derived from EETimes and Embedded Systems Design Magazine 2006 Embedded Market Survey

Open Source OS?• “Free” OS can cost more for product development• More time to develop kernel, device drivers & product can

increase labor cost more than the commercial OS license fees saved

• Some other licenses still required for many devices in addition to free OS (real-time kernel, browser, encoders & decoders, encryption, media player)

• Open source license model may require that you publish your device’s source code

• Some Studies even show a recent decline in Open Source OS use: – http://www.embedded-forecast.com/EMFTCD2003v3.pdf– http://www.embedded.com/showArticle.jhtml?articleID=187203732

28

Commercial Operating Systems used in New Embedded Designs

0.00% 5.00% 10.00% 15.00% 20.00% 25.00% 30.00%

Others

Palm

Green Hills

Symbian

Wind River

Microsoft Emb.

Data was derived from EETimes and Embedded Systems Design Magazine 2006 Embedded Market Survey

Programming Languages Used in New Embedded Designs

0.00% 10.00% 20.00% 30.00% 40.00% 50.00% 60.00% 70.00%

Others

Assembly

Java

C#

C++

C

Data was derived from EETimes and Embedded Systems Design Magazine 2006 Embedded Market Survey

29

Conclusions

• Embedded devices can be found everywhere in large numbers!

• Most new devices are using 32-bit processors

• Most new devices with an OS use a commercial off-the-shelf OS

• The C family (C, C++, C#) is the most widely used language for embedded systems

Product Life Cycle

Figure 1.10 The Embedded device product life cycle phases, Design, Development, and Production.

• Design Review • Build Prototype • Product Testing

Design Phase

Production

Phase

Development

Phase

• Design Concept • Product Planning

• Pilot Production • Mass Production • Technical Support

30

Embedded System Design Cycle

• Short Product Development Cycle – 6 to 12 months (and getting shorter!)

• Software and Hardware must be designed in parallel

• Software run on emulator or similar board until final hardware becomes available

• Production may be offshore

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

Processor

Main Memory

(SDRAM or SRAM)

Flash Memory

(non-volatile storage)

31

Chapter 2: Introduction to Embedded System I/O

Architectures

A single bus architecture was used on early computers.

Processor

Memory

I/O

Hardware

System Bus

But Modern systems are more complex and actually contain a hierarchy of different busses!

32

A First Generation Bus Example: ISA

• ISA bus used in early PCs for Plug-in Cards• Address Bus (SAx)

– Originally 16 bits then expanded to 24• Data Bus (SDx)

– 8 bits then 16 bits – EISA expanded it to 32 bits

• Bus Status Signals– MEMR, MEMW, IOR, IOW

• 5V TTL signals

A3 A2 A1 A0

Address Decoder Output

Digital Logic Review: A simple address decoder circuit for 4-bit address (A3..A0) = 0xA

Would need to decode more address bits in an actual system

33

Tri-state logic gate outputs are used to drive most bus signals

input output

tri-state control input

control input output 0 0 High Z 0 1 High Z 1 0 0 1 1 1

Hardware allows only one tri-state gate at a time to drive a bus signal!

Works just like a large multiplexer:One of several inputs connects to the output

Legacy PC I/O address assignments

I/0 address range I/O device 000h – 200h Reserved for Internal Devices:

Interrupt & DMA controllers, timers278h - 27Fh Parallel Printer (LPTx:) 2E8h - 2EFh Serial Port 4 (COM4:) 2F8h - 2FFh Serial Port 2 (COM2:) 378h - 37Fh Parallel Printer (LPT1:) 3B0h - 3BBh MDA Adapter 3BCh - 3BFh Parallel Printer (LPTx:) 3C0h - 3CFh VGA/EGA Adapter 3D0h - 3DFh CGA Adapter 3E8h - 3EFh Serial Port 3 (COM3:) 3F0h - 3F7h Floppy Controller 3F8h - 3FFh Serial Port 1 (COM1:)

Original PC design only decoded low 10 I/O address bits to save hardware

34

An Example ISA Bus I/O Write Operation

Valid Address

Valid Data

Bus Clock

Address

I/O Write

Data

Clock data into a register on this edge!

An Example ISA Bus I/O Read Operation

Valid Address

Valid Data

Bus Clock

Address

I/O Read

Data

35

Typical I/O Input Port Hardware Operation

Data Bus bit x

Bus I/O Read Command Device’s I/O Address Decoded

Address Decoder Circuit

Address Bus Data bit x in from I/O Device

One tri-state gate is needed for each bit on the data bus

Tri-state Control

Typical I/O Output Port Hardware Operation

Device’s I/O Address Decoded

Bus I/O Write Command

Data Bus

R e g i s t e r

Data out to I/O Device

Clock

Address Bus Address Decoder Circuit

36

Options for Building Custom I/O ICs

• Full custom VLSI devices and Application Specific Integrated Circuits (ASICs) have very high setup costs – a very large volume is required to recover development cost. Typically made only by the major chip vendors.

• Field Programmable Gate Arrays (FPGAs) are programmed by the end user. Low development costs, but higher unit costs, slower clock rates, and higher power levels. – only a moderate volume needed to recover development costs

Using an HDL to design I/O hardware

-- VHDL-based Address Decoder for 0x3E0 PORT_IO_DECODE <= '1' WHEN ADDRESS = X"3E0" AND AEN='0' ELSE '0';

-- VHDL-based I/O Input Port - use tri state buffers DATA <= PORT_DATA_IN WHEN PORT_IO_DECODE = '1' AND IOR = '0' ELSE "ZZZZZZZZ";

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

37

Software for I/O port transfers

• Can use in-line assembly language in C/C++

• Most C/C++ compilers have built-in function calls for I/O port input and output

• C# can call C/C++ functions in a DLL

In-line Assembly Example for X86

// I/O Input Routine // I/O Output Routine__asm{ __asm{

mov dx, IO_address mov dx,IO_addressin al, dx mov al,IO_datamov IO_data,al out dx, al

} }

Problems: Does not port to other processors and many people do not understand assembly language!

38

Windows CE C/C++ I/O Port R/W Functions

• READ_PORT_UCHAR(I/O_Address)– Returns 8-bit input value from port

• WRITE_PORT_UCHAR(I/O_Address,I/O_Data)– Sends 8-bit data value to output port

• Found in CE Device Driver Kit (CEDDK)• Need to link to CEDDK.lib library and include

CEDDK.h – modify sources file for this• Typically used in low-level device drivers

A Second Generation Bus - PCI

• 32-bit Multiplexed Address and Data Bus (AD)• Address sent on first clock cycle• Bus command sent on first clock cycle (C/BE)• Data on subsequent clock cycles • Bus Clock rates 33 to 512Mhz• One Data transfer per clock is possible• Supports Data Bursts (example to follow)

39

PCI Bus Command C/BEInterrupt Acknowledge 0000 Special Cycle 0001 I/O Read 0010 I/O Write 0011 Reserved 0100 Reserved 0101 Memory Read 0110 Memory Write 0111 Reserved 1000 Reserved 1001 Configuration Read 1010 Configuration Write 1011 Memory Read Multiple 1100 Dual Address Cycle 1101 Memory Read Line 1110 Memory Write and Invalidate 1111

PCI Bus Commands (C/BE)

PCI Read Burst Cycle

Bus Clock

Frame #

AD

C/BE#

IRDY#

TRDY#

DEVSEL#

0 1 2 3 4 5 6 7 8

Address Data1 Data2 Data3

Bus-Cmd BE#’s

AddressPhase

DataPhase

DataPhase

DataPhase

Bus Transaction

40

PCI Read Burst CycleClock Cycle Description of PCI operation

0 Bus is idle 1 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).

2 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)

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

4 The target sets TRDY high to indicate it need an additional clock cycle for the next data transfer.

5 The second data transfer occurs when both TRDY and IRDY are low. The initiator saves the target data.

6 The target drives the data value, but the initiator requests an additional clock cycle by set IRDY high.

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

8 All bus signals are tri-stated or driven to the inactive state.

PCI Write Burst CycleBus Clock

Frame #

AD

C/BE#

IRDY#

TRDY#

DEVSEL#

0 1 2 3 4 5 6 7 8

Address Data2 Data3

Bus-Cmd BE-3

AddressPhase

DataPhase

DataPhase

DataPhase

Bus Transaction

Data1

BE-1 BE-2

41

PCI Write Burst CycleClock Cycle Description of PCI operation

0 Bus is idle 1 The initiator sets FRAME low, places the address on the Address/Data (ADx) lines, and

the bus command (write) on the Command/Byte Enable (C/BE) lines (address phase). 2 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 it’s address range and it is responding to the command. When both IRDY and TRDY are low the target saves the data. (data phase)

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

4 The initiator sets IRDY high and the target sets TRDY requesting an additional clock cycle.

5 The initiator drives new data and byte enables and sets IRDY low. The initiator sets FRAME high indicating the final data transfer.

6 The target drives the data value, but the initiator requests an additional clock cycle by set IRDY high.

7 The initiator sets IRDY low to complete the third data transfer. The target saves the data value.

8 All bus signals are tri-stated or driven to the inactive state.

Accelerated Graphics Port (AGP)

• Newer Graphics cards were consuming most of the PCI bus bandwidth

• Solution: Move graphics card to its own PCI bus

• A connection with only 1 device is technically a port and not a bus.

• Extra clock phase signals were added to increase clock rate 2X, 4X, and 8X

42

Software for PCI devices

• Each PCI device has a 256 byte configuration area

• At power up each device can respond with manufacturer and device type information

• Allows system to locate and load device drivers at power up

• Memory and I/O base addresses are configured with software (no jumpers)

Third Generation Bus – PCI Express

• High-Speed Serial line(s) are used to transfer PCI signals

• Fewer signal lines are used, but with much higher bandwidth on each signal line– More stringent design restrictions on drivers, length,

loading, crosstalk, and terminations• Clock rates from 2.5 Gbps to 10 Gbps• Can combine serial lines into groups called

lanes to provide more bandwidth to a device• No changes needed in software – works the

same as PCI

43

Vortex86-based Embedded PC Hardware Block Diagram

Vortex86 Architecture• Contains Northbridge and Southbridge chips on

the processor chip• Northbridge connects to processor, memory and

provides PCI bus• Southbridge and Ethernet devices connect to

PCI bus• Southbridge provides Low Pin Count (LPC) bus• ISA bus bridge for PC 104• Super IO chip provides legacy PC IO interfaces

44

I/O Transfers• I/O devices are orders of magnitude slower than a

Processor. Handshake lines are used to synchronize each transfer.

• I/O device sets a hardware handshake line when it is ready to transfer data. (input ready, output ready)

• Before any data transfer, the Processor must check that the I/O device is ready by reading the device’s handshake line.

• Handshake line bits are connected to another I/O port (status port). Typically the next I/O address after the I/O data port.

• When the Processor reads or writes the data port, the handshake line is usually reset in hardware.

I/O Transfer Methods

• Programmed I/O (Software Polling)

• Interrupt Driven I/O

• Direct Memory Access (DMA)

45

Programmed I/O• Processor must read and check I/O ready

bits for proper value before a transfer. Requires looping, reading status port, and constantly waiting for correct value.

• Processor then inputs or outputs data value to/from I/O device.

• This approach is limited to systems with just a few I/O devices – Processor overhead to loop and check in software

Programmed I/O Pseudo Code

// loop until output ready=1do { // read status and mask off ready bit

status = read_port(status_port_address);output_ready = status & 0x01;

}while (output_ready == 0);// output new data valuewrite_port(data_port_address, data_value);

46

Interrupts• I/O ready signals generate a hardware Interrupt

signal. Eliminates Processor I/O ready wait loops.

• An interrupt signal stops the Processor at the next instruction and the Processor calls the Interrupt service routine (ISR)

• Interrupt service routine transfers the data• Interrupt routines must save all registers on the

stack for the interrupt return to work (ISRs like subroutines - but “called” by a hardware signal)

Interrupts• Interrupt control hardware is needed to support

and enable/disable multiple interrupt signals• Lower number interrupts typically have a higher

priority (can even interrupt a higher number interrupt’s ISR) Gives fast I/O devices priority.

• Most modern processors have a vectored interrupt system. Each interrupt jumps to a different ISR address (X86 uses a table lookup of addresses in low memory to jump to ISR)

47

Servicing an Interrupt

1. Currently Running Process is Interrupted

3. ISTLaunched(Optional)

2. ISRCodeexecutes

4. ISRReturns

…….Mov…Add…………..…….………….………………..…….…..…..….…….

……Mov..Out..…….Reti

……….……………..……..……..…….……...

Interrupts – Other Issues• Interrupt latency time – set by longest instruction

or longest block of code that disables interrupts. Determines the max time to respond to an interrupt. ISR may launch an interrupt service thread (IST) to complete operations so that it can return in less time.

• Some critical code (non reentrant) might require that interrupts be disabled. Most machines have an enable and disable interrupt instruction. But doing this impacts interrupt latency time.

48

Interrupts• Interrupt controller hardware is needed to set

priority and enable/disable each interrupt signal

• Additional bus signals needed– ISA – IRQx lines– PCI – INTx lines

• For security, the OS must control all interrupt hardware, the vector table, and the ISRs.

Direct Memory Access

• A DMA controller transfers blocks of data directly to/from memory and the I/O device.

• DMA controller is a state machine with an address pointer and a counter. Counts down number of memory locations for transfer and drives bus address and control lines (is a Bus Master)

• Processor not involved in transfer once it starts

49

Direct Memory Access

• DMA controller and Processor must both share the bus. Need bus arbitration hardware to control bus access (DMAs or Processor).

• DMA controller interrupts Processor when it’s block transfer is complete.

• Processor programs DMA controller’s address register and counter to start a new transfer.

• Need hardware for each DMA controller and an interrupt system

DMA Bus Cycle

• Processor does not drive the bus during a DMA bus cycle

• Bus Arbitration hardware is needed to support multiple bus masters

ProcessorWith

Cache

MemoryI/O

Hardwareusing DMA

System Bus

50

Direct Memory Access• Need new bus signals for DMA. DMA controller must

request a bus cycle and wait until it is granted by bus arbitration hardware– ISA – DRQx and DACKx– PCI – REQx and GNTx

• For security, the OS must control all DMA hardware.• DMA normally used for high-speed block transfer devices

like disk drives (disks transfer sectors)• Processor and DMA controllers can work in parallel on

different tasks (overlap of computation and I/O)

Tradeoffs

Transfer Technique Hardware CPU Overhead

Programmed I/O

Interrupt

DMA

51

Device Independent I/O• Operating systems provide support for the

underlying I/O hardware. • Many of the I/O devices can be supported in

applications programs by using the basic file system API calls. (i.e. Parallel and Serial Ports)

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

OS File I/O Operations• 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.

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

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

• Close: Close the open file. For a write operation, close flushes all write buffers and updates the directory entries for the new file.

52

Windows Embedded CE File I/O API Calls

• Open with CreateFile• Read with ReadFile• Write with WriteFile• Seek with SetFilePointer• Close with CloseHandle

Unicode and ASCIICharacter Encoding

• For international market will need to support different languages – www.unicode.org/charts/

• Unicode is a 16-bit character code that supports scripts for different languages

• ASCII is an 8-bit character code for English (Basic Latin Script)

• Have to work with both and convert!

53

ASCII Character to Hexadecimal Conversion Table

0 1 2 3 4 5 6 7 8 9 A B C D E F 0 NUL SOH STX ETX EOT ENQ ACK BEL BS HT LF VT FF CR SO SI 1 DLE DC1 DC2 DC3 DC4 NAK SYN ETB CAN EM SUB ESC FS GS RS US 2 SP ! " # $ % & ' ( ) * + , - . / 3 0 1 2 3 4 5 6 7 8 9 : ; < = > ? 4 @ A B C D E F G H I J K L M N O 5 P Q R S T U V W X Y Z [ \ ] ^ _ 6 ` a b c d e f g h i j k l m n o 7 p q r s t u v w x y z { | } ~ DEL

•Example: Find “A” in the table above. It is in row 4 and column 1, so it’s ASCII value is 0x41.•In Unicode, the first 128 characters are the same as the 8-bit ASCII character with a high byte of all zeros to pad it to 16-bits.

Important ASCII Control Characters (<0x20)

• ASCII characters below 0x20 are control codes, they do not print a character - they perform control operations

• LF (line feed) - Moves the cursor down to a new line, but not to the left. “\n” in C/C++/. Some systems automatically add CR to a LF.

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

• 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 display window in terminals. “\f” in C/C++/.

54

Windows Embedded CE

• Unicode by default (but sometimes ASCII)• New C type TCHAR for Unicode strings• _T(“hi”) makes a Unicode string• Functions are provided to convert between

ASCII and Unicode– WideCharToMultiByte and

MultiByteToWideChar

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.

55

Figure 2.16 A Tektronix logic analyzer with optional software setup to capture and disassemble anARM processor’s 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

56

Common Digital I/O Interfacing Standards for External Devices

•Parallel Port•Serial Port•PS/2•SPI & I2C•Analog I/O•USB•Audio AC97

Parallel Port transfer of an 8-bit data value to a printer

Data Lines

Busy

nStrobe

nAck

Data Valid

1 2 3 4

57

Parallel Printer I/O Operation• 1. Computer waits for port’s output ready

bit (i.e. busy=0)• 2. Computer outputs a new 8-bit data

value• 3. Computer toggles strobe control line• 4. Computer must wait for ack to pulse low

before any data or strobe line changes• Printer can be busy for long time periods

(out of paper, offline, page feed…etc)

RS-232 Serial Interface

• Transmit and Receive data lines• No clock signal exchanged – Sender and

receiver need to have same baud rate• Baud rate is the clock rate of the bits• Normal Bits: Start, 8 Data, Stop• Voltage levels: a 1 is >3V and a 0 is <-3V• Special RS232 voltage level converter

chips are typically used

58

RS-232 Serial Interface

• UART is the name for the hardware used for a RS-232 Serial Interface

• UART – Universal Asynchronous Receiver Transmitter

• Early PCs had a UART chip, but this functionality is now found inside a larger chip that also contains other I/O features

RS-232C Serial interface transmission of an 8-bit data value

0 0 0 0 1 0 1 0

StartBit

0 1 2 3 4 5 6 7 StopBitData Bit number

Mark (1)

Space (0)

0x50 = ASCII “P”

LSB MSB

59

Personal System 2 (PS/2) Interface• IBM standard from an early PC• Used in low-cost keyboards and mice• Two signal lines: clock & data• Keyboard sends key scan codes• Mouse sends 3 byte data packets• 11bits sent: Start, 8 Data, Parity, Stop• Can also send commands to Mouse and

Keyboard• Uses Open Collector TTL bus signals

– 1 Pull-up resistor– Device can only force signal low

• Small microcontroller used in a PS/2 device

PS/2 Keyboard Transmission of a Keyboard Scan Code

PS/2 Clock

PS/2 Data

Start 0 1 1 0 1 0 0 0 Parity Stop Bit Data Bits (low to high) Bit Bit

Scan code 16H for “1” key

60

Serial Peripheral Interface (SPI)

• Developed by Motorola in the 1980s• Works like a shift register for input and output• 4 signals: clock, shift-in, shift-out, and chip

enable• Chip enable turns on a tri-state driver on each

slave devices shift-out pin• Two setup modes: one large shift register with

chip enables all connected or independent shift registers each with a chip enable

• Common in A/D and D/A chips

The two SPI slave device configuration options.

MasterCS0CS1CS2

SCLKSDO

SDI

Slave

Slave

Slave

SDI SDO

SDI

SDO

SDI

SDO

MasterCS0CS1CS2

SCLKSDO

SDI

Slave 0

Slave 1

Slave 2

SDI SDO

SDO

SDO

SDI

SDI

61

Inter IC (I2C) bus• Developed by Philips in 1980s• Low pin count serial interface used to connect

chips on a circuit board• Also used by Intel in the PC motherboard

System Management Bus (SMB) • 7 bit address• 1 bit Read/Write• 8 Data bits• Probably have one in your TV

I2C interface serial transmission of an 8-bit data value

1 2 7 8 1 29 8 93-7ACK

ACK Signalfrom Slave

Byte Complete Clock Line HeldLow while serviced

ACKSTART STOP

SDA

SCLS P

ACK Signalfrom Receiver

MSB

3-6

Address DataR/W

62

Analog I/O• Analog inputs – convert to digital using an Analog

to Digital converter (A/D or ADC)• Analog output – convert digital output to analog

using a Digital to Analog converter (D/A or DAC)• A/D outputs and D/A inputs can be attached to

digital I/O ports• Design issues to consider – number of bits of

accuracy, conversion time delay, and sample rate needed by application

Figure 3.6 The MCP3008 10-bit 200Ksps A/D chip used in Phidget modules has an SPI interface.

63

Universal Serial Bus (USB)

• 1-bit serial sent over twisted pair wire• USB Packets contain address and data• Up to 127 devices on bus• Special purpose low-cost USB single chip

microcontrollers are used.• Length is limited to a few feet – a bus and

not a network

A low-cost USB Microcontroller is typically used in USB Devices

USBConnector

+5V

D+D-

GND

USBTransceiver

SerialInterfaceEngine(SIE)

bytes

bytes USBInterface

Program & Data(RAM & ROM)

GeneralPurpose

Microprocessor

I/O Ports

64

USB Data Rates

• USB 2.0 – Up to 480 Mbps• USB 1.0 – 12 Mbps and 1.5 Mbps• USB 2.0 supports USB 1.0 devices• Needed higher USB 2.0 data rates for

external drives and video

USB Enumeration

• Hot pluggable – longer power and ground (outer) pins on USB connector

• At power up, software (OS) can read product and vendor ID codes (PID/VID)

• Codes are used to locate device driver• The required Device Driver is loaded• The new device is assigned its USB

address (0..127) with a command

65

The USB Serial Interface Engine (SIE) handles USB packets

Token Packet H/S PktData Packet Token Packet H/S PktData Packet

PayloadData

OUT

ADDR

ENDP

CRC5

DATA1

ACK

CRC16

PayloadData

OUT

ADDR

ENDP

CRC5

DATA0

ACK

CRC16

D+

USBTransceiver

SerialInterface

Engine

(SIE)D-

PayloadData

PayloadData

ACK

USB Packets

• Contain a packet type• USB Address and Endpoint fields• Each device can have several endpoints• Endpoint is a hardware buffer between the

SIE and the firmware running on the microcontroller (typically 8-64 bytes)

• CRC error code checked and Ack sent back

66

Serial Interface Engine (SIE)

• Special hardware unit that handles sending and receiving high speed serial USB packets

• Serial data rates needed are too high to handle using only software running on the microcontroller

• Microcontroller only transfers bytes to/from endpoints in the SIE

USB Software

• OS typically has a USB driver that handles enumeration and loads driver for device

• Some common USB device drivers may be provided with OS (storage, serial, keyboard, mouse)

• Most other devices need a device driver from the manufacturer

67

CE USB Software Support

• OS handles USB enumeration• Includes USB storage and serial driver• Example USB driver shared source code

projects for Phidgets sensor boards and Logitech QuickCam Pro Web camera

• Some common USB drivers included (Flash, WiFi, Mouse, Keyboard)

Figure 3.9 A USB protocol analyzer captures and displays the USB packets exchanged with a USB Flash Drive (www.usbdeveloper.com) .

68

Audio• For PCs, AC 97 is a common audio

standard• Needs analog signals so A/D and D/A

hardware is used inside the Audio IC• Analog mixers can add analog signals

from different sources• Audio driver typically provided with OS

Figure 3.9 Realtek ALC202 AC97 Device Block Diagram

69

Driving Motors and Relays

• High current devices like motors, relays, solenoids, buzzers, and light bulbs can require more than 500MA of current

• Even though voltage levels may be the same, digital outputs from a GPIO (parallel) port typically drive only 5-20MA of current

• They cannot drive high current devices directly and trying to do so will likely blow out the output circuit

Driver Circuits• A higher current driver circuit must be added

after the digital output pin and before the device• A driver circuit typically uses a discrete power

transistor• For DC motors, consider using an H-bridge

circuit module. It contains four power transistors than can also reverse the motor.

• Diodes are often used for additional protection across the load on motors and relays. When you turn off the current in an inductive load it generates a reverse voltage spike that might damage the transistor (back EMF). The diode shorts it out.

70

CAN and LIN Bus• Serial Buses Developed for Automotive Industry

in mid 1980s – More advanced than RS232 Serial

• CAN is used to connect car subsystem processors together, has multiple bus masters, & uses 2 wires

• LIN is used to connect a processor with it’s smart sensors, a single master, & uses only 1 wire

• LIN used at lower levels along with CAN at higher levels in the system

• Both are now found in other embedded devices

Car Body Network with CAN & LIN

CAN

CAN

Power Train

Light

Sub-Bus

ITS

Window Lift

InteriorLight

Lock

Mirror

Lock

Mirror

Lock

Lock

Seat

Htng

Seat

Htng

Instruments

CentralBody Ctrl

Climate

Universal Motor

Universal Panel

Light

Roof

1 backbone, 13 nodes8 subnets, 1-8 local nodes52 nodes total

St-Wheel Panel

x6Htng

Htng

Seat

Wiper

Trunk

WHtg

Universal Light

71

Controller Area Network (CAN)

• Messages contain a message number and not an address

• Lower number messages have priority• Each devices checks the message

number to see if it needs to handle the message

• Data rates up to 1M Baud• Special CAN chips are available

Message Frame

Arbitration FieldBus Idle Control Data Field CRC Field ACK EOF Int Bus Idle

11 Bit Identifier DLC Data (0-8 Bytes) 15 BitsSOF

RTR r0r1 Delimiter

Slot

Figure 3.10 A CAN 2.0A Message Frame

72

Local Interconnect Network (LIN)

• Can be implemented with a UART and microcontroller firmware

• Data rates up to 20K Baud• Only one bus master• Lower cost, lower data rates, and 1 less

wire than CAN

SyncBreak

SyncField

IdentField

DataField

DataField

DataField

DataField

Check-SumField

Message Frame

Header Response

InterframSpace orBreakInterbyte Space

In_Frame Response Space

Figure 3.11 A Typical LIN Frame Consisting of Synch Break, Synch Field, Identifier, Data Field and Checksum.

73

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

Figure 3.14 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 I2C bus signals. Images courtesy of Prodigy Test Solutions.

74

Chapter 4: Network Interface Standards

Networking

• Ethernet Frames• Ethernet LAN• The TCP/IP Protocol Suite• Software APIs for networking

75

Network Interfaces• Ethernet is the most widely used network

interface • Details found in IEEE Standard 802.3• Data is transferred in Ethernet Packets (Frames)• Data rates: 10Mbps, 100Mbps, and now 1Gbps• Low-cost Ethernet controller chips are used

– Often attaches directly to a PCI bus• Original Idea: each network device is assigned a

unique 48-bit address by the manufacturer (MAC address)

An Ethernet FramePreambleSFD

56 bits of alternating Is and Os.Start field delimiter, flag (10101011)

Preamble SFD DestinationAddress

SourceAddress

LengthPDU CRCData and Padding

7 bytes 1 byte 6 bytes 6 bytes 2 bytes 46 to 1500 bytes 4 bytes

• 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 (PDU) - 16-bit sub-protocol label field with length or type• Data Payload – The data being sent• CRC (or Frame Check Sequence), a CRC value computed on the entire

frame. Used to detect bit errors occurring during transmission.

76

A Small Ethernet Network

Ethernet Medium

Computer

A

Compu ter

BComputer

D

PrinterC

CSMA/CD• Carrier sense multiple access with

collision detection (CSMA/CD)• Device waits for medium to be idle• Device starts transmitting data• Device Listens to data to detect a collision• When collision detected, stop and wait for

a random amount of time before starting over

• Works a bit different in 1 Gbps Ethernet

77

Statio n

A

Station

B

Station

D

Station

C

Segment 1 Segment 2

Bridge

An Ethernet Bridge Connecting Two Segments

TCP/IP Protocol

• Application Protocols – HTTP, SMTP, SSH, etc.

• Transport Protocols – TCP, UDP• Network Communication Protocols – IP• Network Topology – Ethernet, Wi-Fi,

Token Ring, etc.

78

Network Protocol Layers

Data

TCPData

TCPHeader

IP DataIP

Header

Frame DataFrameHeader

FrameTrailer

Application Protocols

Transport Protocols

Internet Protocols

Network Topology

Network Software Support• Ethernet controller hardware filters, buffers,

sends, and receives Ethernet packets• Software is still needed to implement protocols• OS typically provides software to implement the

network protocols (TCP/IP, HTTP, FTP, etc.)• OS may also support networked file systems• Common network applications (i.e. browser,

telnet, ftp) may be provided with OS or available from third parties

79

Windows Embedded CE Networking Software

• Includes a TCP/IP Protocol Suite• Supports sockets model programming

interface in Windows Sockets (Winsock) • Also has some higher level API interfaces

such as WinInet & WinHTTP• Comes with browser & ping applications.

Wireless Networking Standards

• WiFi - IEEE Standard 802.11• Bluetooth - IEEE Standard

802.15.1• ZigBee - IEEE Standard 802.15.4• Features of each on the next slide

80

Feature 802.11b/WiFi 802.15.1/Bluetooth 802.15.4/ZigBee Application Area

Web, Email, Video Cable Replacement Control & Monitoring

Target Cost $25 $15 $5 Memory Requirement

1MB+ 250KB 4KB - 32KB+

Battery Life .5-5 Days 1-7 Days 100-1000 Days Network Size 11,000+ 7 20-250 Peak Data Rate

1, 2, 5.5, 11, (54-802.11g) Mbps

1Mbps 250 Kbps @ 2.4 GHz

40 Kbps @ 915 MHz

20 Kbps @ 868 MHz

Power Consumption (targeted)

1.5 W active @ 20 dBm

45 mW sleep

80 mV active @ 0 dBm

100 mW sleep

60 mW active @ 0 dBm

5–2000 mW sleep (mode dependent)

Adjacent Channel Rejection

>35 dB 0 dB 0 dB

Receiver Sensitivity

–80 dBm –70 dBm –85 dBm –92 dBm @

868/915 MHz Range Line of Sight

~200 m @ 11 Mbps ~500 m @ 1 Mbps

~30 m ~100 m, Class 1

~50 m @ 0 dBm

Range—Indoor (approx.)

~40 m @ 11 Mbps ~100 m @ 1 Mbps

~10 m ~30 m, Class 1

~10 m @ 0 dBm

Number of Channels

11 - DSSS 79 - FHSS

79 16 @ 2.4 GHz 10 @ 915 MHz 1 @ 868 MHz

Modulation Technique

GFSK—FHSS BPSK/QPSK—DSSS

GFSK O-QPSK @ 2.4 GHz

BPSK @ 868/915 MHz

Maximum Transmit Power

20 dBm—FHSS 30 dBm—DSSS

20 dBm 30 dBm

Figure 4.5 The free Ethereal Network Protocol Analyzer capturing and decoding network traffic on a desktop PC. The PC just loaded a short web page from a remote server (see HTTP packets). (www.ethereal.com)

81

Chapter 5: The eBox 2300 Embedded Computer

System

CE Target Hardware: eBox 2300Hardware Features:• Vortex86 200Mhz SoC• 128MB SDRAM• 256MB Flash• VGA • 10/100Mbps Network• AC97 Audio• PS/2 Keyboard & Mouse• CF Slot• 3 - USB V1.1 Ports• 2 - RS-232 Serial Ports• Int. Wireless LAN (Optional)• Fanless Design• Low Power: 7-15 watts @5V• Small: 4.5 x 4.5 x 1.5 inches

82

Software for eBox 2300• Windows Embedded CE Development Tools are free for

schools and students from the MSAA Program– Need Visual Studio 2005 with CE 6.0 tools (C,C++,C#)– Can download & debug on eBox using a network cable– 180 Day free trial versions are also available

• Board Support Package (BSP) for CE 6.0– An eBox 2300 BSP is being developed and will be free– Includes all I/O drivers needed for board

• AMI ROM BIOS included on board• Flash drive preloaded with Windows Embedded CE

– Runs LoadCEPC from DOS to boot CE OS – Select CE boot sources from network, Flash, or USB

Inside the eBox 2300

BIOS ROMBIOS ROM

128MB SDRAM128MB SDRAM256MB FLASH256MB FLASH

PS/2, USB, VGA, PS/2, USB, VGA, serial, & Network serial, & Network connectorsconnectors

Vortex86 SoCVortex86 SoC

Ethernet Ethernet ControllerController

Audio CODECAudio CODEC

Bottom of PCB: Bottom of PCB: Mini PCI & Mini PCI & CF slotCF slot

83

Vortex86 System on a Chip (SoC) is used to build the eBox

CPU-Vortex 86 Vortex 86North Bridge

Vortex 86South Bridge

Super I/OW83697HF

Com1

Com2

PS/2 Keyboard

PS/2 Mouse

USB 1.1 x 3

RJ45

Line In

Line Out

Mic In

AC97CodeC

AC97

32.768KHz

RTCBattery

Ethernet LANRTL8100B

LAN210/100M

ControlLogic

AMI BIOS 256

Doc/Flash

SDRAM 128M

Ultra IDEFlash

CFSlot

VGA

LPCPC1

64-Bit

Vortex 86-SoC

+5V Input +5V

SB+5V

+3.3V

SB+3.3V

+2.5V

+1.8V

SB+1.8V

Mini-PC1

Vortex86 SoC Chip• Includes an X86 200Mhz Processor core• Includes traditional Northbridge and Southbridge

PC motherboard features• A few additional parts are needed to provide the

I/O features typically found on a PC• External SDRAM and FLASH devices are

required• Using SoC approach reduces size, cost, and

power• Runs Windows Embedded CE using standard

PC hardware reference platform (CEPC)

84

eBox 2300 MSJK• Special model for students and schools• Includes CE preinstalled on Flash Drive• All cables needed for CE development work• Includes the two serial port option• Available with Educational Discount (around $145

Qty 10)• Internal Wireless Option (add around $40)• For School Orders & Student Orderswww.embeddedpc.net/academic/ebox2300.html

Figure 5.5 The eBox VGA display output after successfully booting Windows Embedded CE 6.0.

85

Table 5.1 eBox 2300 Device Drivers for CE 6.0

eBox-2300 Peripherals CE 6.0 Drivers

Video (SiS-550) Vortex86_Display

(Driver included with ICOP eBox BSP)

Audio (SiS-7019) Vortex86_Audio

(Driver included with ICOP eBox BSP)

Ethernet (RealTek-8100) RTL8139 (Driver provided with CE 6.0)

Serial Ports (16550 UART) Com16550 (Driver provided with CE 6.0)

USB Ports (USB 1.1 Host) OHCI (Driver provided with CE 6.0)

USB Flash Drive USB Storage Class (Driver provided with CE 6.0)

CF storage card ATAPI & Compact Flash / PC Card Storage (ATADISK) (Driver provided with CE 6.0)

IDE Disk ATAPI (Driver provided with CE 6.0)

MiniPCI (internal slot) PCI Bus (Driver provided with CE 6.0)

Internal 802.11 Wireless Card (optional)

(VIA VT6655 - US only) VIA VT6655 (Driver provided by VIA & ICOP)

Adding Peripherals to eBox 2300• Can attach any PS/2 keyboard and mouse• Use any standard VGA monitor• PC style audio speakers and microphone• USB Flash drives• Other USB devices that have CE drivers available• Serial device (one port normally used for CE

Debug)• CF cards that have CE drivers available• Standard 10/100Mbs Network connection• Can add internal Mini PC Wireless card with

antenna

86

Adding External I/O using USB• Phidgets USB Devices ( www.phidgets.com )• Supports Servos, Digital, & Analog I/O (50-125 Hz)• Numerous plug-in sensor modules available• Free Driver & source code shared projects for CE

Other USB I/O options• Various USB devices built using FTDI USB chipsets

( www.DLPdesign.com/usb/ DLP-D245PB-G)• Lower board cost than Phidgets ($40), but more hardware

effort is required. • The DLP-245PB-G has both digital and analog I/Os.• Some have free CE drivers (6.0 status?)• DIP modules plug into a standard .1” protoboard

87

Serial I/O options• Cypress PSoC Evaluation Kit (CY3210)• Mixed-Signal Microcontroller with digital and analog I/Os.• Low Cost ($17 academic pricing) but need to develop

Firmware for serial commands (www.cypress.com/CUAP) • For 16x2 LCD panel add $17 • Serial Interface and Small Protoboard on PCB• Free graphical software tool, C compiler

USB WebCam• USB webcam driver for Windows CE• Supports Logitech QuickCam Pro 5000 ($65)• Free Driver & source code shared project for CE(http://msdn.microsoft.com/embedded/usewinemb/ce/sharedsrccode/)• Also new CE 6.0 USB Camera driver at

www.microsoft.com/downloads

88

Low Cost Sensors

Figure 5.10 Low-cost sensors from left to right: Line following, IR proximity, shaft encoder, GPS, Sonar, IR distance, Electronic Compass, CMOS Camera

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 mounted on a special surface mount to DIP adapter board that allows it to plug directly into a .1 inch student protoboard.

89

Low Cost R/C Servos

Figure 5.11 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 modified and used as robot drive motors for small robots. A Phidgets servo controller is available. A 1-bit digital Pulse Wide Modulation (PWM) signal is used to control servos.

Internal Wireless Kit

Figure 5.13 The internal 802.11 wireless kit for the eBox 2300 MSJK. Photograph courtesy of ICOP.

90

Cell Phone Modem

Figure 5.14 The Enfora SA-GL GSM/GPRS Stand Alone Cell Phone Modem can be used with CE and the eBox. (www.enfora.com) Photograph courtesy of Enfora Inc.

Low-cost Robot Base for the eBox

Figure 5.15 The iRobot Create robot base can be used as a low-cost robot base for the eBox 2300. 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.

91

Some Student Projects using the eBox 2300

Figure 5.11 This project displays scrolling RSS web news feeds on the Phidgets LCD display.

92

Figure 5.12 VoIP Phone system using two eBoxes running CE 6.0.

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

93

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

Figure 5.15 Digital I/O from the Phidgets LCD interface board attached to the robot’s control signals. The laser rangefinder is seen in the upper left.

94

Figure 5.16 This Student project developed a CE USB HID driver and GUI for a USB PSoC board.

Figure 5.19 This eBox Phidget project is a scanner built using an IR distance sensor with pan and tiltservos. Note the clever use of the eBox mounting holes and a plastic sheet to attach the external hardware. Photograph courtesy of Dan Slaeker.

95

Figure 5.23 Students mounted an eBox on this R/C plane along with a GPS receiver and a small battery. They recorded flight data and displayed the data using Google earth.

Figure 5.23 Several Phidgets mounted on a plastic case for CE eBox student lab projects. 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. Wires are hidden inside the case.

96

Chapter 6: Architecture of a Real-Time

Embedded OS – CE 6.0

Windows Embedded CE 6.0• Initial version developed in mid 1990s• Supports ARM, MIPS, SHx, and X86 processors• Hard real-time OS• Not a port of Desktop Windows - Designed from

scratch for embedded devices• Core technology used in Windows Mobile

SmartPhone and PocketPC devices• Default setup has a look and feel similar to the

Desktop Windows OS

97

Windows Embedded CE 6.0• Kernel size 400K to 40M – Depends on

features included in OS build• Tools provided include C/C++/C#

compiler, OS build tool (Platform Builder), and debugger

• Hard drive not required – typically boots from Flash memory device

• CE Development tools run as a Visual Studio 2005 add on

Virtual Memory Address Space

• Designed primarily for 32-bit processors with Virtual memory mapping (232 - 4G)

• Virtual memory used for memory protection of kernel

• 2G of Virtual memory address space setup for Kernel Space

• 2G of Virtual memory address space setup for User Space

98

. . . .

. .

Process CodeUser VM

User VMMemory Mapped files

User DLLs

CE Kernel

File system

GWES

Drivers

2 GBKernelSpace

2 GBper

Process

Up to 32 KProcesses

Figure 6.1 The Windows Embedded CE 6.0 Virtual Memory Space Model.

OAL . DLL

FILESYS NETWORK

DEVICE .DLLKERNEL . DLL

Applications

SHELL

Drivers

Hardware

Boot Loader

COREDLL / WINSOCK / COMMCTRL / WININET / COMMDLG

KernelSpace

UserSpace ServicesServicesServices

User ModeDrivers

GWES

SERVICES . EXEServicesServicesServicesServices UDEVICE . EXE

DLLKCOREDLL

Figure 6.2 Windows Embedded CE 6.0 Architecture.

99

CE User Processes

• Shell – Standard or custom interface for device

• Services.exe hosts n number of services• UDevice.exe hosts n number of user mode

drivers

CE Kernel

• FilesSys.dll provides file system support and communicates with file system drivers (FSD)

• GWES.dll is the Graphics, Windowing, and Events Subsystems

• Networking DLLs Networking services• Device.dll provides device driver services• Kernel provide basic OS services• API calls use KCOREDLL.dll to get to other

kernel services

100

Application Programs in CE

• CE Supports Threads• Uses a critical subset of the Desktop

Windows APIs – around 2,000 vs. 20,000• Means CE application source code can be

recompiled and run on the Desktop Windows OS, but the reverse is not true

• Sample browser, Media player, WordPad applications included with OS.

Application

ServiceKernel

Figure 6.3 CE 6.0 System Calls

101

Kernel

• New Kernel (NK.bin) module• Core of the operating system• Base level functions in kernel: process,

thread, and memory management• Includes some file management functions• Kernel services allow applications to use

the core functions

Figure 6.4 CE 6.0 Kernel Architecture.

102

Memory Setup In CE• 4GB 32-bit Virtual Memory Address Space• 2GB User Space in Virtual Memory

Address Space• 2GB Kernel Space in Virtual Memory

Address Space

NOTE: Remember that Physical memory size is independent of the Virtual Memory Address Space!

Figure 6.5 User Space Virtual Memory Mapping

Shared User DLLs 512 MB

RAM Backed Mapfiles 256 MB

Shared System Heap 255 MB

Process space 1 GB per process

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

0x00000000

0x40000000

0x80000000

103

Figure 6.6 Kernel Space Virtual Memory Mapping.

0x80000000

Kernel Space 2 Gigabytes

Fixed mapping independent of

user space

0xFFFFFFFF

All XIP DLLs in kernel

Uncached access to physical memory

Kernel Virtual Memory Shared by all kernel Servers and drivers

System Trap AreaCPU Specific VM

Kernel VM(if supported by CPU)

256 MBKernel VM

256 MB

Object Store (128MB)

Kernel XIP DLLs (128 MB)

Static Mapped Uncached

512 MB

Static Mapped Cached512 MB

Table 6.1 CE 6.0 Virtual Memory Map.

Mode Range Size Description Comments Kernel 0xF0000000 -

0xFFFFFFFF 256 MB

CPU specific VM

System call trap area. Kernel data page.

Kernel 0xE0000000 - 0xEFFFFFFF

256 MB

Kernel VM, CPU dependent

Kernel space virtual memory, unless disallowed by the CPU, such as SHx.

Kernel 0xD0000000 - 0xDFFFFFFF

256 MB

Kernel VM Kernel space virtual memory, shared by all servers and drivers loaded in kernel.

Kernel 0xC8000000 - 0xCFFFFFFF

128 MB

Object store RAM based storage for RAM file system, CEDB databases, and RAM-based registry. Legacy data store.

Kernel 0xC0000000 - 0xC7FFFFFF

128 MB

Kernel XIP DLLs

XIP DLLs for the kernel and all servers and drivers loaded in the kernel.

Kernel 0xA0000000 - 0xBFFFFFFF

512 MB

Statically mapped Uncached

Direct access to physical memory bypassing the CPU cache.

Kernel 0x80000000 - 0x9FFFFFFF

512 MB

Statically mapped Cached

Direct access to physical memory accessed through the CPU cache.

User 0x7FF00000 - 0x7FFFFFFF

1 MB

Unmapped for protection

Buffer between user and kernel spaces.

User 0x70000000 - 0x7FEFFFFF

255 MB

Shared system heap

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.

104

User 0x60000000 - 0x6FFFFFFF

256 MB

RAM backed map files

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.

User 0x40000000 - 0x5FFFFFFF

512 MB

User mode DLLs Code and data

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.

User 0x00010000 - 0x3FFFFFFF

1 GB

Process User allocatable VM

Executable code and data User VM (heap) virtual allocations: 1 VM allocations start above the exe

and grow up. User 0x00000000 -

0x00010000 64 KB

CPU dependent user kernel data

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

Figure 6.7 Example of Virtual to Physical memory mapping on a device.

105

What is in Memory?

• OS Kernel• Application Code & Data• Object Store – File System, Registry, Built-

in Compact Data Base• Memory Mapped Files

File System

• FilesSys.dll provides file system support and communicates with file system drivers (FSD)

• CE supports two kinds of file systems, files systems controlled by file system drivers & registered file systems.

• File system drivers (FSDs) are provided for a variety of file systems

106

Table 6.2 File Systems and Storage Management Catalog. Catalog

item name Description

Compression An application programming interface (API) that compresses the data in the RAM and ROM file systems, as well as the database volumes.

Database Support An API that provides built-in CEDB database support. Bit-based 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.

RAM and ROM File System

A file system driver capable of reading data from the ROM file system and the RAM file system in the object store.

ROM-only File System

A file system driver capable of reading data from the ROM file system.

Hive-based Registry

A registry system that stores data inside files, or hives, which can be kept on any file system.

RAM-based Registry

A system that stores all registry data within the object store.

Storage Manager The Storage Manager is responsible for all external storage items, such as file systems, file system filters, and partitioning.

Binary Rom Image File System

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

CD/UDFS File System

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.

EDB Database Engine

An API that provides enhanced database functionality, including support for transactions, access by multiple users, multiple sort orders, key properties and databases.

FAT File System A file system driver that supports the file allocation table (FAT) file system.

Extended FAT File System

A file system driver that supports the Extended FAT file system.

Partition Driver A driver that interprets the partitions on a storage device for the Partition Manager.

Storage Manager Control Panel

Applet

A control panel application that allows a user to manipulate storage devices.

Transaction-safe FAT File System

(TFAT)

A transaction-safe FAT file system that ensures the file allocation table is not corrupted during power cycles.

System Password An API that provides support for authentication on a device to prevent unauthorized access.

Release Directory File System

A functionality that provides support for the Release Directory File System

Silent FATFS UI Builds the Fatutil.dll file for a device with no graphical user interface (GUI) components.

107

Processes and Threads

• 2GB of Virtual Memory per process• Up to 32,000 Processes• Each Process has one or more threads• Thread – basic unit of execution managed

by scheduler• Many threads per process – limited by

system resources (memory)

Processes and Threads

• Preemptive scheduling with 256 priority levels

• Round-robin scheduling of threads with same priority

• Highest Priority 0 threads run to completion

• Time slice 1-100ms (100 ms is Default)

108

Priority Levels

Table 6.3 Priority Levels

Range Description 0 through 96 Reserved for real-time above drivers. 97 through 152 Used by the default CE-based device drivers. 153 through 247 Reserved for real-time below drivers. 248 through 255 Maps to non-real-time priorities.

Priority Scheduling

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

109

Priority Inversion• A mutex or critical section held by a lower-

priority thread delays the execution of a higher-priority thread when both are contending for the same resource.

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

• Changes Scheduling of threads around – so would like to avoid inversion, if possible

Figure 6.10 Priority Inversion Example.

110

Real Time Performance of CE

• Results based on hardware test setup• 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 Results Interrupt

Response Times ISR starts

IST starts

Minimum 1.2 µs 31.7 µs Average 3.3 µs 67.2 µs Maximum 13.3 µs 103.0 µs

111

Real-Time Performance of CE 6.0

Hard Real-Time

Cycle Variation or Jitter (Cycle Variation or Jitter (µµs)s)

500 us500 us

1 ms1 ms

5 ms5 ms

10 ms10 ms

20 ms20 ms

100 ms100 msR

espo

nse

Cyc

le T

ime

Res

pons

e C

ycle

Tim

e

Hard Real-Time

00 1,000 1,000 µµss 5,000 5,000 µµss 10,000 10,000 µµss100 100 µµss

Soft RealSoft Real--TimeTime

Linux?

WindowsXP

Windows CE

Figure 6.10 Figure 6.10 CE RealCE Real--Time Performance Measurements showing Response Cycle TimeTime Performance Measurements showing Response Cycle Time. . Soft and Hard Soft and Hard RealReal--Time categories are based on OMAC study and OS times are withoutTime categories are based on OMAC study and OS times are without any third party realany third party real--time time extensions to the OS.extensions to the OS.

Synchronization Primitives

• Critical Sections• Mutexes• Semaphores (counting)• Events – used to indicate something

happened

112

Interprocess Communication

• Both the Shared Memory and Message Passing Models are supported in CE

• Can share a heap in memory• Memory mapped files and Pointers• Point to Point Message Queue APIs• Message Queuing (MSMQ) for

communications between different devices

Interrupt Processing• Interrupt Service Handler (ISH) in Kernel

decides which ISR to call• Uses an Interrupt Service Routine (ISR)

and an Interrupt Service Thread (IST)• ISR handles basic interrupt tasks quickly,

starts IST and returns• IST can complete remainder of task later• Using both an ISR and IST reduces

Interrupt Latency

113

Figure 6.11 Processing an Interrupt in CE with an ISR and IST.

Device Drivers

• Abstracts device functions• Manages operation of devices• Drivers can be layered (MDD and PDD

layers) or monolithic• Stream Interface for devices that produce

and consume streams of data• Many standard drivers are provided with

the OS

114

User Mode Driver

• Allows an intermediate driver to load in User mode

• Cannot directly access hardware• Some drivers will be more stable in user

mode• Reflector in kernel makes a user mode

driver work as if it was a kernel mode driver

11

User ApplicationUser ApplicationUser Mode Driver Host ProcessUser Mode Driver Host Process

udevice.exeudevice.exeUser Mode DriverUser Mode Driver

Parent Bus DriverParent Bus Driver

Reflector ServiceReflector ServiceDevice ManagerDevice Manager

11

22

33 55

44

66User Mode

Kernel Mode

Figure 6.12 User Mode Driver Architecture

115

Registry

• Stores configuration information for applications, drivers, and the OS

• OS uses registry to locate and load device drivers

• Same basic setup as the desktop Windows OS registry

• Space is limited, so keep any new entries short!

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.

116

Device Manager

• Manages Devices and their Interfaces• Decides which drivers to load• Uses Registry to find drivers• Runs continuously

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 nopmif

Pmif provides the interface to Power Manager DLL entry points. Nopmif provides the stubbed version of the Power Manager entry points.

117

Table 6.6 Processes that Load Drivers. Process Drivers File System (FileSys.dll)

FileSys.dll loads file system drivers. For more information, see the section on File Systems.

Device Manager (Device.exe)

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.

Graphics, Windowing, and Events Subsystem (GWES.dll)

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.

Security Best Practices

• Use Mutual Authentication• Avoid storing user credentials on the

device• Use smart cards to store credentials• Use pass-through authentication• Use a strong authentication protocol• Avoid using plain text passwords

118

Power Management

• Critical for Battery Operated Devices (i.e. Cell Phones!)

• Support for Power Management is built into CE at both the system level and at the individual hardware device API level

No power

Clear filesystem

Clear RAM

On

Critcal off

Idle

Suspend

Scheduler idleAny interrupt

Activity timer time-out

Wake-up events

Critical battery-low event

Persistent storage file system?

Clean boot signaled?Yes

No

Yes

No

No

Yes

Power-on reset

Warm boot

Battery backuplevel reaches

zero

Persistent storage file system?

Clean boot signaled?

Yes

Power-on reset

No

Figure 6.13 CE 6.0 Power States and Transitions.

119

Table 6.7 Power State Transitions. Transition Description Power-on reset

Target device clears working RAM and initializes the file system.

Cold boot First application of power, for example, when a backup battery is installed.

Warm boot

Transition from the On power state. A warm boot clears the working 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-to-Suspend

Transition to a stopped microprocessor, as a result of certain events. A device driver's XXX_PowerDown (Device Manager) function is called.

Suspend-to-On

Transition of a stopped microprocessor to full-power operation based on specific wake-up events. A device driver's XXX_PowerUp (Device Manager) function is called.

On-to-Critical off

Transition when critically low battery power is detected. You must implement the function for transitioning to the Critical Off state for your device.

Figure 6.14 CE 6.0 Power Manager Architecture.

120

Security

• Control access to the device• Protect against unauthorized

applications• Secure data storage and file systems• Secure network and internet

connections

Security Tools

• Authentication• Authorization• Encryption• Repudiation

121

Figure 6.15 CE Security System Architecture.

Networking

• Critical in most embedded devices• Support for Networking is a major

component of a modern OS• CE includes a TCP/IP protocol suite• CE includes common Network Utility

Programs (ping, ipconfig, netstat…)• CE supports WinSock, WinInet, and

WinHTTP APIs

122

Table 6.8 TCP/IP Services Service Description

Dynamic Host Configuration Protocol (DHCP) client

DHCP clients are dynamically assigned with various configuration parameters, such as an IP address, subnet mask, default gateway, and other critical network configuration information.

Windows Internet Name Service (WINS)

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

Domain Name System (DNS) client

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.

Extended DNS Querying and Update

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.

Dial-up (PPP/SLIP) support.

CE implements dial-up networking with Remote Access Service (RAS) and Point-to-Point Protocol (PPP).

TCP/IP network printing

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.

Simple Network Management Protocol (SNMP) extension agent

The SNMP extension agent provides an MIB-2 subagent that allows the state of TCP/IP to be monitored and controlled.

Wide area network (WAN) support

This service provides users with access to the Internet.

TCP/IP connectivity utilities

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.

Network Utilities

Many network troubleshooting tools are available for CE, for example, ipconfig, iPv6, ipv6tun, netstat, ping route, and tracert.

Internet Protocol Helper (IP Helper)

IP Helper provides application programming interfaces (APIs) that assist in the network administration of the local computer.

Remote Procedure Call (RPC)

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.

Windows HTTP Services (WinHTTP)

WinHTTP provides developers with a server-supported, high-level interface to the HTTP/1.1 Internet protocol..

Windows Internet (WinInet)

WinInet handles all communication between an application and Winsock.

Windows Sockets (Winsock)

Applications access the TCP/IP stack through the Winsock interface.

123

Figure 6.16 CE Networking & TCP/IP Architecture.

OS Build System

• The Platform Builder Tool is used to build a new OS Kernel

• Both a GUI-based interface and a batch command mode build is supported

• New kernel can be downloaded to a target system

• Several files are critical to understanding the build system (Examples follow later)

124

Figure 6.17 Platform Builder is the tool used to build a new OS kernel image.

Figure 6.18 Steps in Developing a new OS Run-time image.

125

Figure 6.19 The CE Build system.

Build System Files

• Used to control the OS build operation• More complex than just make files!• Controls which code is in kernel• Controls where code is loaded in memory• Also sets up initial registry, file system,

and data base on device

126

Table 6.9 Source Code Configuration File Types. File type Description

Dirs File Identifies additional subdirectories that contain more source code. Makefile File

Contains the variables needed to compile and link the source code.

Module-Definition File

Contains the statements defining an executable or dynamic-link library.

Sources File

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)

Table 6.10 Run-time Image Configuration Files. File type Description

Binary Image Builder File

(*.bib)

Defines the modules and files to be included in the run-time image.

Registry File (*.reg)

Defines the registry keys and values for a run-time image created during a cold boot.

File System File (.dat)

Defines the RAM file system directories, files, and links for a run-time image created during a cold boot.

Database File (.db)

Defines the databases to be included in the object store of a run-time image created during a cold boot.

String File (.str)

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.

127

Table 6.11 Scope of Run-time Image Configuration Files. File name Scope

Common.bib, Common.reg, Common.dat, Common.db, Common.str

These files apply to the Common project, which contains the core CE-based modules and components.

IE.bib, IE.reg, IE.dat, IE.db, IE.str

These files apply to the IE project, which contains the components that support the Microsoft Internet Explorer modules.

Wceappsfe.bib, Wceappsfe.reg, Wceappsfe.dat, Wceappsfe.db, Wceappsfe.str

These files apply to the Wceapps project, which contains the components that support WordPad word processing software and Inbox electronic messaging software.

Wceshellfe.bib, Wceshellfe.reg, Wceshellfe.dat, Wceshellfe.db, Wceshellfe.str

These files apply to the Wceshellfe project, which contains the components that support the CE-based shell modules.

Msmq.bib, Msmq.reg, Msmq.data, Msmq.db, Msmq.str

These files apply to the MSMQ project, which contains Message Queuing Server modules.

Platform.bib, Platform.reg, Platform.dat, Platform.db, Platform.str

These files apply to the hardware platform.

Project.bib, Project.reg, Project.dat, Project.db, Project.str

These files apply to the workspace that contains your CE-based run-time image.

Config.bib This file applies to your run-time image. It contains MEMORY and CONFIG sections for the run-time image.

128

*.Bib entry to add mydll.dll to kernel

Name Path Memory block Section override Type MYDLL.DLL %_WINCEROOT%\RELEASE\MYDLL.DLL NK SHC

Chapter 7: Building a customized CE Kernel

129

Tutorial I: Building a new OS kernel using the eBox BSP

Building a Custom OS• See 7.2 for software installation instructions• Start Visual Studio 2005• Create a new OS Design Project• Select the correct BSP• Choose an initial Design Template• Select/Deselect Individual OS components• Set OS build and environment variables• Build OS

Note: Turn off on-access virus scanning!

130

Figure 7.1 The Visual Studio 2005 IDE

Figure 7.2 Creating a new OS Design Project.

131

Figure 7.3 The Windows Embedded CE 6.0 Design Wizard.

Figure 7.4 Selecting the eBox 2300 BSP in the Design Wizard.

132

Figure 7.5 Selecting a Design Template in the Design Wizard.

Figure 7.6 Selecting a Design Template Variant in the Design Wizard.

133

Figure 7.7 Selecting Applications and Media options in the Design Wizard.

Figure 7.8 Selecting Networking and Communications options in the Design Wizard.

134

Figure 7.9 A Security Warnings on a selected OS option.

Figure 7.10 The Catalog Items View (left column) is used to select individual items for the OS.

135

Figure 7.11 The Configuration Manager can be used to select Debug or Release OS Builds.

Figure 7.12 The Property Pages Window is used to set Build Options and Environment Variables.

136

Figure 7.13 Adding an Environment Variable using the Property Pages Window.

Figure 7.14 OS Build succeeded with no errors.

137

Tutorial II: Downloading a new OS kernel to the eBox 2300

Downloading the new OS• Setup network connection to target device• Set Target Device Connectivity Options• Attach Target Device• Target device sends Bootme request• New OS downloads to device• Device boots OS• Debug messages display on PC

Note: Watch out for firewall settings!

138

Figure 7.15 Setting up the target device connectivity options.

Figure 7.16 Detecting and Selecting the CEPCxxxxx target device to download.

139

Figure 7.17 Attaching the target device for downloading.

Figure 7.18 The target device is downloading the new OS image.

140

Figure 7.19 The target device display is seen running the new OS image.

Tutorial III: Creating, compiling, and debugging a

C/C++ Subproject

141

Creating a new C/C++ Subproject

• Create a new Subproject in OSDesign Project• Add C/C++ source code file(s)• Specify include and library files (in sources file)• Build Subproject without errors• Rebuild OS• New OS now includes new subproject code• Can use Target -> Run Programs to execute

new subproject code after downloading and booting new OS

Figure 7.20 Adding the C/C++ MyHelloWorld Subproject to the OS Design Project.

142

Figure 7.21 Select a typical “Hello World” C/C++ application and generate the code.

Figure 7.22 Setting up a breakpoint in the “Hello World” C/C++ application.

143

Figure 7.23 The eBox console display while running the “Hello World” C/C++ application.

Figure 7.24 Stopping at the breakpoint in the “Hello World” C/C++ application.

144

Figure 7.25 Switching the MyOS project to a Release build.

Tutorial IV: Generating a new SDK for use by

application developers

145

Software Development Kit (SDK)

• Needed by application developers• Includes files and info needed on API’s

included in each OS design project• Do not need an OS design project to

develop applications when an SDK is available

• Required for C# project development

Creating a SDK

• Open OSDesign Project• Use Project -> Add new SDK• Setup the SDK properties windows• Build All SDKs• Output is an *.msi install file• Install *.msi file to support applications

development

146

Figure 7.26 Setting the SDK property page names to MySDK.

Figure 7.27 Setting the install file name to MySDK.

147

Figure 7.28 Including managed code (C#) support in the new SDK.

Tutorial V: Creating and Building a C# Project

148

C# Projects

• C# code is platform independent• C# needs to be setup as a separate

project (not a subproject like C/C++ code)• C# needs an SDK for each OS design• C# uses a graphical design tool for GUI

design• After designing the GUI, C# code is added

to respond to events

Figure 7.29 Creating a C# Project.

149

Figure 7.30 The new HelloCSWorld project is created and it opens a Forms design window.

Figure 7.31 A textbox and a button is added to the Form using the toolbox.

150

Figure 7.31 A textbox and a button is added to the Form using the toolbox.

Tutorial VI: Deploying new application code

to the target device

151

C# Code Deployment• C# is code is deployed after the OS boots so a

different network communications setup is needed than is used for the initial OS boot process (several setup steps are required)

• Need to setup and specify Target’s IP address• Target must then run two communication

programs (ConmanClient2 and CMaccept)• C# code can then be deployed to target and

debugged over network connection• A second instance of Visual Studio is required to

debug C/C++ and C# code at the same time

Figure 7.33 First step in setting up the target device’s IP address for deploying code.

152

Figure 7.34 Second step in setting up the target devices IP address to deploy.

Figure 7.35 Final step, type in the target device’s actual IP address.

153

Figure 7.36 Start the Corecon components running on the target device.

Figure 7.37 Select the MySDK Device to connect.

154

Figure 7.38 The Corecon components are running on the target device and it is connected.

Figure 7.39 The new C# application has been deployed and is running on the eBox.

155

Figure 7.40 The new C# application’s textbox changes after the button is clicked.

Chapter 8: Applications Programming in CE

156

Applications Programming in CE

• Subset of Desktop APIs• C/C++ and C# supported• May need to link to CE *.lib files for some

APIs (modify sources file)• Console Applications require support for

console in kernel• Source Code for Examples on CDROM

Console Applications in CE• Simplest programming model in CE• Outputs plain text to console window• Console window appears after first printf• No support to read input from keyboard• Can read command line parameter• Uses stdio.h and not fstream.h• Will have Windows examples later

157

FileIO Example Program• Demo of File system API calls• File name is in Unicode• Uses CreateFile to create a new file• Writes to File with WriteFile• Closes file with CloseHandle• Opens file again for read with CreateFile• Reads file with ReadFile• Closes file with CloseHandle• Uses Sleep(ms) for time delay

// 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);

// Check for file open errors if (hFile == INVALID_HANDLE_VALUE){ printf("file write open errors\n"); Sleep(1000); return 0;

158

} 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; }

Serial IO Example• Uses same File System APIs to read and write

data from serial port.• COM1 normally tied up with debug messages in

CE (COM2 becomes COM1)• GetCommStatus and SetCommStatus APIs are

used to setup the baud rate, number of bits, and handshake options

• SetCommEvent and WaitCommEvent APIs are used to notify program that new serial data is available

159

Serial IO Demo• Serial port is setup for 9600 baud, 8 data

bits, no parity, 1 stop bit, and no handshake

• To run demo attach eBox COM2 to an unused COM port on the desktop PC using the null modem cable provided with the eBox

• Start HyperTerminal on the desktop PC and set COM settings

Figure 8.1 HyperTerminal running on development system and communicating with eBox COM Port

160

// 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 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; }

161

// Function to set COM port options BOOL ModifyCommSettings (HANDLE hComPort) { 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; }

162

Port IO Example• Operates the same as the previous serial port

example• Instead of File Systems APIs this code talks

directly to the serial port I/O hardware (A 16550 UART)

• Uses the CEDDK library functions WRITE_PORT_UCHAR & READ_PORT_UCHARto read and write I/O ports

• Intended to demo the use of CEDDK functions (not replace device driver!)

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

163

// 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; 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; }

164

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; }

Sources File• Need to include CEDDK.h header file• Need to link to CEDDK.lib• Requires new lines in subproject’s sources file

(controls the subproject’s build operation)• Includes go in INCLUDES section• Libraries go in TARGETLIBS section• “/” is the continuation character• Blank lines matter!• Path variables typically used

165

Table 8.2 Environment Variables used for Paths Environment variable Description

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

_FLATRELEASEDIR Defines the directory where the released source code and binary files will be placed. The default is %_WINCEROOT%\ PBWorkspaces\%_TGTPROJ%\RelDir\%_TGTPLAT%\%_TGTCPUFAMILY%_Release.

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.

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

_PROJECTROOT Defines the location of the project you are building; for example, %_PBWORKSPACEROOT%\WINCE500 \%PBCONFIG%.

_PUBLICROOT Defines the location of public projects. The default is %_WINCEROOT%\Public.

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

_TGTPROJ Defines the name of the current active workspace.

ILASMIO Example Program• Operates the same as the previous serial port

examples• X86 in-line assembly language is used for I/O

port read and write operations (instead of CEDDK functions)

• Will only work on X86 Processors• Example of how low-level code can use

assembly language to talk to hardware• Should only use assembly language when

absolutely necessary – in just a few of the lowest level OS routines

166

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; }

Thread and Synchronization Example Program

• Uses CreateThread API to create a thread• Sleep used for time delays• CreateEvent sets up an event• SetEvent signals an event• WaitForSingleObject waits until the event

is signaled

167

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

168

// 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; }

169

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.

170

Figure 8.6 The kernel tracker displays all of these events.

Other Remote Tools• 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

171

Producer Consumer Problem

• Producer Thread put items in shared buffer

• Consumer Thread takes items out of shared buffer.

• A circular buffer is used (wraps around) with an in and out pointer.

• Critical Sections used on access to global data in first try (need mutual exclusion)

// 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);

172

// Producer while (1){ // Check for Buffer Full while (count == 4) { printf("Buffer Full - Producer Waiting\n"); Sleep(0); }; // Insert new item into Buffer // Shared Global Variables - use Critical Sections EnterCriticalSection (&CriticalSection); 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"); Sleep(0); }; // 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; }

173

Figure 8.7 The Producer Consumer Problem.

Producer Consumer Problem• While loops consume CPU time and

power• Count violates mutual exclusion rule• Use three semaphores

– One for mutual exclusion lock– One to detect buffer full and block– One to detect buffer empty and block

• Different initial values used for semaphores

174

// 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 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; }

175

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; }

Figure 8.8 Sample Output from the second Producer Consumer Problem using Semaphores.

176

Audio Example Program

• Uses PlaySound to play a *.wav file• Uses eBox AC97 Audio Device• Need a speaker or headphone connected

to audio output jack on front of eBox• OS also has waveIn and waveOut API

calls for audio

// 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; }

177

Windows Application

• Windows Applications do not directly request I/O read operations from the mouse or keyboard

• The OS sends messages (mouse and keyboard events) to a Windows Application and it then responds to them

• Push vs. Pull Technology

Windows Application

• All Windows Applications have the program entry point WinMain

• WinMain registers the Window class• WinMain then creates, displays, and

updates the new Window• WinMain always ends with a Windows

Messaging (While) Loop

178

Windows Messaging Loop

• Translates and Dispatches messages to the Window

• Stays in Windows Messaging While Loop as long as application is running

• Blocks waiting for each new message• Messages that are Dispatched cause the

OS to activate the Windows callback function

Windows Callback Function• The function that handles the applications

messages• Called by OS when a message is

generated for the Window• A case (switch) statement is used to

decode the message• The action for each message is coded into

each case• After the message is processed, the

callback function returns

179

Table 8.3 Common Hungarian Notation Prefixes Used for Variables in Windows Programs

Variable Type Hungarian PrefixInteger i or n Word (16-bit) w or s Double Word (32-bit) dw Long (32-bit signed) l Char c String (zero terminated) sz Pointer p Long Pointer lp Handle h Window Handle hwnd Structure Size cb

// WinAPP.cpp : Defines the entry point for the application. // #include "stdafx.h" #include "resource.h" #define MAX_LOADSTRING 100 // Global Variables: HINSTANCE hInst; // current instance TCHAR szTitle[MAX_LOADSTRING]; // The title bar text TCHAR szWindowClass[MAX_LOADSTRING]; // The title bar text // 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);

180

// 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) { 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; }

181

// // 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); 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; }

C# Applications

• C# has a syntax similar to Java• Also called managed code• Compiles to the Common Intermediate

Language (CIL) – (like Java Byte Codes)• One version of code for all processors• .NET Compact Framework executes CIL

code (like Java Virtual Machine)

182

C# Advantages

• Middleware provided to make programming of GUI and networking easier (programmers are more productive)

• Built in threads and synchronization• More run-time checking on array bounds

and data types (safe code)• No direct pointer manipulations (like Java)

C# Disadvantages• .NET Compact Framework increases

kernel size by several MBs.• C# runs a bit slower and uses more

memory than C/C++• Periodic Garbage Collection routines have

a negative effect on real-time performance• Items above are bigger issues on a small

embedded device than on a desktop PC with lots of memory and a fast processor

183

C# Hello World Console Application

using System; namespace HelloNET {

public class Hello { public static void Main() { Console.WriteLine("Hello NETCF World"); } }

}

C# Serial Port Hello Worldusing 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(); } } }

184

C# Window Applications

• GUI designed using graphical tools (Visual Studio Application Designer)

• Tool automatically generates C# code• Can generate Windows Applications

quickly• Most time is spent writing code manually

to handle events (hitting buttons etc.)• Example earlier in C# Tutorial

Phidgets Driver Subproject• Phidgets are USB-based modules that can

be added to the eBox for additional I/O such as digital and analog I/O and sensors

• A PhidgetsDrivers subproject is provided to easily add the Phidgets drivers files to the CE kernel

• Adds registry entry for Phidgets• Needed in any application that uses

Phidgets

185

Figure 8.9 This Phidget USB device contains a LCD with digital and analog I/O.

Figure 8.10 The Phidget C# demo programs running on an eBox with several Phidgets attached.

186

C/C++ Phidget API Calls

// 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"));

See the PhidgetLCD Subproject for a complete example

C# Phidget API calls

• See source code for applications seen in previous screen capture

• All of these sample C# Phidget applications are in the WindowsCE.NetExamples project

187

Calling C/C++ functions from C#

[DllImport("Users.dll")] private static extern uint Userfunction( . . .);

• C# can call C/C++ Functions

• Must expose C/C++ Functions in a DLL

• Special Interface is called “P/Invoke”

Chapter 9: Introduction to I/O Device Drivers

188

Device Drivers• Device drivers help provide a layer of

abstraction between the hardware and the user’s application programs

• A user developing an application does not need to understand the low-level hardware details of each interface.

• Applications programmers can be more productive working at a higher level of abstraction using device drivers

• Numerous Drivers come with the OS• New or unique hardware may require that the

user write a new device driver

Table 9.1 CE Device Driver Libraries Library Description

Microprocessor-native libraries

Device drivers for high integration microprocessor-native 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-specific OAL support libraries

OAL functions for devices such as a real-time clock, timer, and a debug Ethernet controller that are common to a microprocessor. 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.

189

BSP or hardware platform-specific 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.

Other common peripheral 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.

Stream Interface Driver• Best choice for a simple driver for a device that

produces and/or consumes streams of data• Driver is a DLL & has 12 Standard Entry Points• Applications use standard file system APIs • Device Manager checks registry for device name

on Open to locate driver library• Probably will want to use CEDDK functions in

driver code to communicate with hardware

190

Monolithic Stream Interface Driver

Stream Interface Stream Interface

Device Manager

MDD

PDD

Device

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

Application

File System

Stream Interface Driver

(Loaded at Boot up)Window CE

Kernel

DeviceManager

Hardware Platform Built-inDevice

HardwareSoftware

Interrupt EventsOAL

CreateFile

Figure 9.2 Stream Interface Architecture

191

Table 9.2 Stream Interface Driver Functions.

Programming element

Description

XXX_Close (Device Manager)

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.

XXX_Deinit (Device Manager)

This function de-initializes a device. It is called by Device Manager.This function is required by drivers loaded by ActivateDeviceEx, ActivateDevice, or RegisterDevice.

XXX_Init (Device Manager)

This function initializes a device. It is called by Device Manager.This function is required by drivers loaded by ActivateDeviceEx, ActivateDevice, or RegisterDevice.

XXX_IOControl (Device Manager)

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.

XXX_Open (Device Manager)

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.

XXX_PowerDown (Device Manager)

Optional. This function ends power to the device. It is useful only with devices that can be shut off under software control.

XXX_PowerUp (Device Manager)

Optional. This function restores power to a device.

XXX_PreClose (Device Manager)

Optional. This function marks the closing handle as invalid and wakes any sleeping threads.

XXX_PreDeinit (Device Manager)

This function marks the device instance as invalid and wakes sleeping threads. This function is required if the XXX_PreClose function is implemented.

XXX_Read (Device Manager)

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.

XXX_Seek (Device Manager)

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.

XXX_Write (Device Manager)

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.

192

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

Table 9.4 CEDDK vs. Kernel Functions for DMA. Using CEDDK.dll functions Using kernel functions

CEDDK.dll provides these functions for obtaining a buffer for DMA transfers:

HalAllocateCommonBuffer

HalFreeCommonBuffer

HalTranslateSystemAddress

The kernel provides these functions for obtaining a buffer for DMA transfers:

AllocPhysMem

FreePhysMem

CEDDK.dll functions can handle bus and hardware platform-specific address translations.

You must handle hardware platform-specific address translations. You can call HalTranslateSystemAddress to translate the address.

CEDDK.dll functions are useful for common buffer DMA.

The kernel functions may be useful for scatter/gather DMA.

CEDDK.dll functions use a default memory alignment of 64 KB.

The kernel functions allow you to change the default memory alignment.

193

// 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; }

KOM Driver Example• Educational example of a simple stream

interface device driver – not a production quality driver!

• Used instead of standard COM port driver provided with CE

• Based on earlier serial port IO example• Uses CEDDK functions to communicate with

16550 UART compatible hardware on eBox serial port

• Must be setup as a DLL

194

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

UCHAR Read_Serial_Character (PUCHAR Data_Port_Address); PUCHAR Data_Port_Address; UCHAR Serial_Input_Data = 0; // ---------------------------------------------------- BOOL APIENTRY DllMain( HANDLE hModule, DWORD ul_reason_for_call, LPVOID lpReserved ) { switch(ul_reason_for_call) { case DLL_PROCESS_ATTACH: OutputDebugString(L"KOM_DRIVER - DLL_PROCESS_ATTACH\n"); break; case DLL_PROCESS_DETACH: OutputDebugString(L"KOM_DRIVER - DLL_PROCESS_DETACH\n"); break; case DLL_THREAD_ATTACH: OutputDebugString(L"KOM_DRIVER - DLL_THREAD_ATTACH\n"); break; case DLL_THREAD_DETACH: OutputDebugString(L"KOM_DRIVER - DLL_THREAD_DETACH\n"); break; default: break; } return TRUE; } // 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; }

195

// 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");

// 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 IOCTLBOOL 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 Functon 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"); }

196

} // 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]); } OutputDebugString(L"KOM_DRIVER - Exit KOM_Write\n"); return Count; }

197

// 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); } 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; }

198

Registry & Drivers

• On an CreateFile (Open) API call the Device Manager searches the registry for an entry for the device name (i.e. KOM)

• The registry entry tells the device manager which driver to use for the device

• So a new registry entry is needed for the KOM driver to function correctly

Registry Entry for KOM driver

[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

199

*.bib entry to add driver to kernel

MODULES KOM_Port.dll $(_FLATRELEASEDIR)\KOM_Port.dll NK SHK

*.def file for external defs

LIBRARY DemoDriver EXPORTS

KOM_Init KOM_Deinit KOM_Open KOM_Close KOM_IOControl KOM_PowerUp KOM_PowerDown KOM_Read KOM_Write KOM_Seek

200

KOM Tester Example

• Need test program for new KOM driver• Attach serial port to HyperTerminal on PC

Open KOM1: Device• Read & Write characters from serial port• Close Device when CTL C sent• Driver code outputs debug messages that

will show what is happening

// 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"); // 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; }

201

// 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; }

Running KOM Driver Test ProgramRun 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 -

202

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

KOM Driver Works!• Can see characters echoed on serial

port• Debug messages show that the driver

is being called correctly by the test program

• But, this is not a production quality driver and it would need a lot of improvements!

203

Chapter 10: Advanced OS Topics

Porting the OS to a new design

• Need to develop a Board Support Package (BSP)

• BSP includes the following:– Boot Loader– OEM Adaptation Layer (OAL)– Device Drivers for Board

• Will be easier if you have some of these items from a similar board

204

Windows CE Platform Development Process

Device Bring-Up PlatformDevelopment

Application Development

Hardware Design

Load ROM Monitor

Create Boot Loader

OAL Development

BSP Development

Develop CustomDrivers

Testing andIntegration

Boot Minimum Kernelon Hardware

Testing andIntegration

Develop and IntegrateCatalog Items

Testing andIntegration

Custom Windows CECatalog Items

Applications andMiddleware

Testing andIntegration

Figure 10.1 The Process of porting CE to a new target device.

Table 10.1 Elements of a Board Support Package (BSP). Element Description

Boot loader During development, downloads the OS images. OEM adaptation layer (OAL)

Links to the kernel image and supports hardware initialization and management.

Device drivers Supports peripherals on-board or are attached at run time. Run-time image configuration files

When created, a BSP can be reconfigured through environment variables and .bib and .reg file modifications.

205

Bootloader

• Need a boot loader to bring up the OS on a new device

• The boot loader places the run-time image into memory for execution and then jumps to the OS startup routine

• OS startup routine uses OAL routines• Several example boot loaders are

provided with the OS

Figure 10.2 The Initial Startup Sequence for CE

BootloaderBootloader//startupstartup

kernel.dllkernel.dll

oal.exeoal.exe Startup Startup librarylibrary

kitl.dllkitl.dll

OEMGLOBALOEMGLOBAL

NKGLOBALNKGLOBAL

KITL IOCTLKITL IOCTLOEMInitOEMInitGlobalsGlobals()()

206

Modifying the OAL

• OEM Adaptation Layer (OAL) is the lowest level of routines in the OS that communicate directly with hardware

• Includes the basic hardware units needed for the OS such as the real time clock, timers, interrupts, and the cache

• Needs to be modified for each new hardware design

Figure 10.3 Porting CE to a new target device requires changes to the OAL routines.

kernel.dllkernel.dll

oal.exeoal.exe

RTCRTC

Cache

Cache

librarylibrary

Interrupt Interrupt

librarylibrary

IOC

TL IO

CTL

librarylibrary

Startup Startup librarylibrary

RTC

RTC

librarylibrary

kitl.dllkitl.dllOS Tim

erO

S Timer

librarylibrary

TimersTimers CachesCaches SerialSerialportport

EthernetEthernetportport

USBUSBportportHardwareHardware

OEMGLOBALOEMGLOBAL

NKGLOBALNKGLOBAL

KITL IOCTLKITL IOCTL

207

Figure 10.4 BSP Structure

Hardware Debug Tools

• Use special debug/trace pins on processor• Can follow instruction execution and set

hardware breakpoints• Useful when initially testing a new board –

software debug tools will not work until OS is running

• May require a special connector or processor socket on the PCB

208

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

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

209

CETK for Testing

• The CE Test Kit (CETK) is a tool used to test device drivers for the new OS

• Development system works as server for CETK

• Application Verifier Tool used for runtime testing

• CE Stress Tool runs image for long periods of time (memory leaks or crashes)

Clientside.EXE

TUX.EXE

TUX Test DLLs

Kato.DLL

CETEST.EXE

Log

Development Workstation CE 6.0 Device

ActiveSync, KITL, Winsock

CETK TestDLLs

Figure 10.5 The CE Test Kit (CETK) Architecture

210

Figure 10.6 The CE Test Kit (CETK) UI running on the development PC.

Figure 10.7 The CE Application Verifier tool.

211

Figure 10.8 The CE Stress Testing tool.

Safety Critical Coding

• Applications that can endanger people or cause catastrophic failure are “safety critical”

• Extra precautions must be taken• Special safety-critical coding rules typically

used in such cases• Examples: Biomedical, Aircraft, Vehicles,

& Industrial Equipment

212

Rules for Safety Critical Coding1. 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 non-terminating 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.

213

Code Analysis Tool• CE includes the PREFast static code

analysis tool.• In subproject or project properties select

the C/C++ tab• Change default setting for code analysis to

“yes” to run• Log report will then be generated in build• Detects buffer overruns and memory use

problems and more

License and IP Issues• Any legal issues will take longer to resolve

than you expect• May need legal agreements approved on

OS, the development of custom device drivers, and applications developed by third parties

• Need to determine any such costs or license fees early on and include in product cost estimates

214

Figure 10.9 The CE Run-time License Assessment tool lists features present in an NK.BIN file.

A discussion of software engineering coding practices and project management can be found in: Code Complete, Second Editionby Steve McConnell and Software Estimation: Demystifying the Black Art by Steve McConnell.

Software Project Management