WINDOWS EMBEDDED CORPORATION Introduction to Windows CE Versions Design Goals Windows CE Fundamentals Terminology Processors, CPUs, SoCs OS Components and projects Windows CE Architecture Kernel, Threads, Processes, Drivers Memory map for User & Kernel Space OS Layout and Component Interaction Understanding Windows CE OS Image Development Overall Goal Critical Steps along the way Development Iteration and Debugging System Generation (SYSGEN) Board Support Package Windows CE integrates advanced technologies to rapidly build a wide range of innovative, small-footprint devices 32-bit, real-time, multitasking OS Delivered as a granular set of components Use Platform Builder tools to configure image Runs on x86, ARM, XScale, MIPS and SH4 Reliable real time capabilities (256 Thread Priorities) Small Footprint ( Kernel =~300K) Targeted for Low power devices Shared Source Code and Success Model PND Point of Service

for Embedded systems

Consumer

Portable media Entertainment Thin Client Medical

Telematics

for Embedded systems Industrial Automation Industrial Automation Robotics Thin Client General Embedded General Embedded Thin Client RDP 6.0 (Vista compatible) VoIP Video telephony, 3-way audio Devices Profile for Web Services Full WSDAPI support Pluggable font engine framework Browser Updates (IE6 like) File caching, advanced editing (RTF) Player OCX 7 (ActiveX) File Systems SATA Driver, FAT32 boot loader/exFAT(64) Secure Digital Host Controller (SDHC 2.0) Drivers USB CCID Smart Card reader (Standardised) Win32 API Subset Portable to different architectures (ARM, MIPS, SH) Real-Time Modular Run from ROM Minimal RAM Design considerations: Not supposed to be the be-all end-all of Operating Systems applicable to all tasks. Suitability to task - The right tool for the right job. Start from zero – want the most functionality with the least cost. “What do we need” as opposed to “what do we leave out.” Windows Embedded Enterprise Windows Embedded Standard Windows Embedded POSReady These systems should be used instead of CE when: Power requirements for peripherals are much greater Specific facilities for services are not available in CE. Existing software is written for the desktop and uses some and facilities that would require significant effort to port. High processor and software performance requirements Cases where CE should be used instead of them. Cost per device needs to be low Flexibility in platform choice is needed Power requirements are stringent (battery) Physical portability Ingrained systems that need to be small (physical size, memory size, storage size) Investment focus in categories

Continued investment in core Compact platform Increased focus on Portable Navigation (PND) and Connected Media (CMD) devices Strong focus on Software + Services

PND CMD Portable Navigation Devices Connected Media Devices

ent General Embedded Handheld Terminals, Automation, Set Top Box, PMP, Thin Client, Feature Phones, Medical etc

MicrosoftMicrosoft ConfidentialConfidential – NDA Only Windows Embedded Windows Embedded Compact “Chelan” CE 6.0 R2 Windows Embedded “Cashmere” (CE 6 based)

Windows Embedded Windows Embedded NavReady 2009 NavReady 2010 Shipped Approved Under Consideration

Microsoft Confidential Connection UI Framework Manager And Dev Tool

IM Client Improved Browser

Flash Support Office Viewers Touch and WEBAP Gestures BSPs

Microsoft Confidential Goal: Deliver needed components to CE platform Timeline: RTM Aug 2009 Status: In business review

• Windows Embedded • Additional Components Components • WEBAP BSPs • Alchemy • Flash Lite 3.1 • Gestures • Live Messenger • Connection Mgr • Office Viewers • Improved Browser Experience • QQ Messenger

Microsoft Confidential Chelan is the next real time Windows Embedded OS that will enable next generation device scenarios

Tools to Technologies Rich user bring enable experience devices to immersive on devices market device faster scenarios

13 Microsoft Confidential Connectivity Multimedia NDIS 6.1, Cellcore, Media Library, WiFi, BT 2.1 DRM, DLNA, MTP Tools Browser VS 2008 Plug In, IE7 rendering Neon, VFP Flash support

Core OS UX SMP, ARM v6 C++ XAML API, Touch Input

Active Sync., UI development POOM Expression Blend

Microsoft Confidential OS BUILD OVERVIEW • Integrated into Visual Studio 2005 • Documentation integrated with Visual Studio 2005 • Updated catalog functionality • Device Emulator integrated into Platform Builder • .NET Compact Framework v2.0 • New debugger transports supported sources

Loading generation Launching

Debug, etc…

RS232, Ethernet, USB, ...Target

Development PC sources Platform SDK MyPlatform.msi Visual Studio

CE binaries NK.bin Development PC Target

What you need to build an OS image:-

Microsoft Source Code (Core OS & components) Build tools (Platform Builder in VS2005) Third-party BSP/apps A set of build environment variables

Output: = an image file that can run on a device CE OS images (NK.bin) Loading

Launching

Debug, etc…

Emulator

Development PC Virtual target CEPC PocketPC SmartPhone Etc…

No-target development Machine code emulation (ARM) Behaves like a target Provided with its SDK

Advantages Reduces delays No hardware cost Dev. Station Platform Builder

Dev. Board Serial RS233 Null-Modem Cable HyperTerminal on Dev Station

Network Cross Over Cable Recommended : some kind of DHCP service on the Dev Station

Module EXE or DLL – Code that will run or is part of CE 6.0 Component The smallest unit of functionality that you can add to an OS design. OEM Adaptation Layer (OAL) Low level hardware platform specific library - abstracts the hardware architecture from the kernel Board Support Package (BSP) OAL + drivers + bootloader + configuration files for a particular hardware platform “Board” OS Run-Time Image Everything in the OS Design is built into a file containing ROM data & code (usually NK.BIN) For Windows CE, Microsoft creates an OS kernel for each architecture. Then that Microsoft Board kernel can be used on Windows CE Support platforms that have Kernel Package that same flavor of chip.

The Board support X86 (ARCH)ARM SoCSH MIPS package that is tied (Ti,QC,Marvell,,etc.) together with a Kernel allows for new features SD 4.0 and enhancement that Microsoft could never be able to plan for. ARCH CPU CORE CPU / SoC Board

80486 X86 phyCore270

Pentium MIPS MARVELL EM-X270 PXA27x

ARM ARMv5TE QUALCOMM Mainstone III 7X00

SH ARM11EJ-S TI OMAP 3430 Board OS Components

DEVICE MANAGER phyCore270

DISPLAY USB CORE SYSTEM EM-X270

WINDOW Mainstone III USB HOST MANAGER

DEBUG SHELL ARCH Board Window CE OS Components “Project” (VS Solution) COLLECTION X86 INDUSTRIAL OF OS phyCore270 APPLIANCE COMPONENTS

MIPS DISPLAY ENTERPRISE SYSTEM EM-X270 WEB PAD

ARM WINDOW Mainstone III MY COOL MANAGER WINDOWS CE PROJECT SH

DEBUG SHELL ARCH Board Window CE OS Components “Project” (VS Solution) DEVICE X86 MANAGER X86 KERNEL INDUSTRIAL phyCore270 APPLICANCE

MIPS MIPS DISPLAY KERNEL ENTERPRISE SYSTEM EM-X270 WEB PAD ARM ARM KERNEL WINDOW Mainstone III MY COOL MANAGER WINDOWS CE PROJECT SH SH KERNEL DEBUG SHELL Board Window CE OS Components “Project” (VS Solution) DEVICE MANAGER INDUSTRIAL phyCore270 APPLICANCE

DISPLAY ARM ENTERPRISE EM-X270 SYSTEM KERNEL WEB PAD

WINDOW Mainstone III MY COOL MANAGER WINDOWS CE PROJECT

DEBUG SHELL Board OS Components Support Package

DEVICE MANAGER

phyCore270

DISPLAY ARM HardwareEM-X270 SYSTEM KERNEL

WINDOW Mainstone III MANAGER

DEBUG SHELL Board OS Components Support Package

Driver DEVICE MANAGER

OAL DISPLAY ARM SYSTEM KERNEL DEBUGKITL

WINDOW MANAGER

ARM Core Hardware DEBUG SHELL An Architecture-Specific Kernel A Board-Specific OEM Adaptation Layer (OAL) Some sort of data transport for KITL

OAL ARM KERNEL KITL

The kernel already knows how to talk to the CPU core, which is the same for every CPU of a particular architecture. The OAL must abstract everything else.

What do we want to get out of this at the end? We want: To create an OS image that contains a set of Windows CE system components .

To have the image contain: - The Microsoft Kernel for the CPU we’re using - Our OAL that adapts the kernel to the board we’re using. - Any other things we need to communicate with the running operating system.

To be able to execute the image on the board, either by: 1) Burning the image file into ROM. or 2) Downloading the image file into RAM to execute it from there. Specify the BSP we intend to use The BSP must have the drivers/functionality we need in our end product. Specify the OS components we need The Windows CE Catalog allows us to select OS components and automatically have their dependencies included. We can optionally add our own components and specify our own dependencies for those components. Configure features to suit our development needs. Build an image Download the image. Execute and Debug the image. Development is an iterative process. Build Download Observe and Tweak Debug and step through code. Make changes Repeat as needed. Decreasing iteration time increases productivity. The Windows CE OS Design and build process is friendly to iterative development on a specific set of static components. This can allow for platform or feature specific tweaks and changes to enable maximum functionality and performance. Windows CE “SubProjects” provide a mechanism to enhance and extend a Windows CE Image and iterate on developing those components to the state they are effective in your product. Windows CE 6 comes with a very wide array of components. If functionality for all components was always included in a kernel the resulting system would be very large in size and slower than was necessary. It is ideal to configure the kernel, the device drivers, and the systems+services so that something that is not used is not included in the image. Examples: A web browser and everything it depends on Image compression and rendering for a system with no display. Power management for a system that is AC powered. This is the componentization model. Executing a “SYSGEN” for an OS Design is the process of filtering the full system headers and libraries and extracting the pieces that you are using. The result is a set of system headers and libraries that are unique to your configuration of OS components. You get a “Custom OS and Application” system with minimal overhead. As we saw previously, the Board Support Package (BSP) we choose to use determines the functionality available. The BSP is where the OAL and drivers come from. The BSP is the abstraction layer that lets many different Windows applications execute on potentially very different hardware. The OAL for a BSP is customized and optimized to fit the particular platform. If you are going to extend a platform from the default supported by its BSP you typically need to have access to the BSP sources. MEMORY MODEL OVERVIEW CE 6.0 CE 5.0 Processes 32K 32 Virtual Memory per process 2 GB 32 MB

Hard Real Time (ISR & IST) Yes Yes

Source Code Access (Shared & Premium) Greater Access Access Protected memory model Yes (Mutex, Semaphore, critical sections ...) Number of Threads Unlimited up to Memory limit of device Thread priority levels 256 (configurable per thread) Maximum Partition size >32GB <32GB (ExFAT(64) ) (FAT32) Maximum Addressable RAM 512MB 2 GB Kernel kernel space

Shared memory

Slot 34 Slot 33 Single Slot 32 Slot 31 2 GB VM 32 : for all processes : processes Slot 6 Slot 5 – Services.exe Slot 4 – GWES.exe Slot 3 – Device.exe Slot 2 – Filesys.exe Slot 1 – ROM DLLs Slot 0 – Execution Execution slot and CE 5.0 shared DLL slot 2 GB Kernel Filesystem Kernel kernel GWES space Drivers

Shared Memory memory mapped files Slot 34 Slot 33 Single 2 GB Slot 32 User DLLs Slot 31 2 GB VM VM 32 : for all per processes : processes Slot 6 process Slot 5 – Services.exe Process Slot 4 – GWES.exe Slot 3 – Device.exe code Slot 2 – Filesys.exe 32 K Slot 1 – ROM DLLs Slot 0 – Execution processes Execution slot and CE 5.0 shared DLL slot CE 6.0 Moved the critical drivers, , and graphical window Kernel 2 GB manager into the kernel kernel Filesystem GWES space Kernel version of Coredll.dll Drivers Benefit Greatly reduces the Memory overhead of system calls mapped between these components files 2 GB Reduces overhead of all User DLLs VM calls from user space to per kernel space process Process Increase code sharing code 32 K between base OS services processes

• OS Kernel is the heart of the system. • You cannot have a system without it. • Some systems can be kernel-only! • Specific features distinguish CE 6.0+ from CE5.x and before • 2 GB of Virtual Memory per process • 32K processes • 64K Global Handle Table • Unified Kernel • Critical OS components moved into kernel space • Improved system performance • Increased security and robustness • High degree of application compatibility All these things are similar to other Operating Systems Thread A piece of code that can be scheduled to run by the kernel A “unit” of execution May be launched by a process or a driver

Process Launched from an executable file A collection of threads (at least one) with a common execution environment Can create threads to handle interrupts

Driver A DLL, (dynamically loaded library) loaded into the kernel or into a user- mode driver host process. Can create threads to handle interrupts Services UM Driver Manager Manager ApplicationsApplications Shell ApplicationsApplications User User Mode Services Mode Drivers

OS DLLs (Coredll, Winsock, CommCtrl, …)

KCoredll.DLL Kernel.DLL Device.DLL FileSys.DLL GWES.DLL Kernel OAL.EXE Mode Bootloader Kernel Drivers Hardware kernel.dll

NKGLOBAL

OEMGLOBAL NKStub.lib KITL IOCTL oal.exe

(nk.exe)

OS Timer library library Cache library Startup library Interrupt library IOCTL library RTC kitl.dll

USB Ethernet Serial RTC Timers Caches Hardware port port port Thank you Further Information in Appendix

© 2006 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary. APPENDIX FURTHER INFORMATION CE System Power States (one of the methods to lower power usage)

OEMs can define system power states. SystemIdle, OnBattery, InCradle, OutOfCradle, and so on. These names are not predefined, The sample Power Manager implementation defines four system power states. ON UserIdle - Device in Use but no user interaction SystemIdle - User not directly using the system but processes are still active Suspend

Using Power States to manage power also enables separation of device power state from overall OS power state. Thus, some devices can be turned off while the OS is running, and others can be left on while most of the OS is suspended. Real time Applications where specific timings are requested

Hard real time Applications where system fails if timings are not met

Soft real time Applications where system tolerates large latencies

Actual timing requirements are system-specific OMAC represents Industrial Automation Community

100 ms

20 ms

10 ms WindowsSoft RealWindows-Time •Hard Real-Time 5 ms Hard CE 2.X NT/XP 90% Real Apps 1 ms Windows

Cycle Time Cycle CETime 3 + 500 us

0 100 µs 1,000 µs 5,000 µs 10,000 µs Cycle Variation or Jitter (µs) So what were some actual requirements for a real project? 200Mhz ARM Windows CE with Full UI Running WMV Video playback Interrupt as frequent as every 4.6 ms Allowable jitter < 0.5ms

Actual Application Requirements 0.5 ms Jitter

Interrupt every 4.6 ms Windows CE Real-Time Test Results 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 Time in microseconds (µs)

In terms of the 0.5 ms jitter alone CE’s longest ISR response time was 13.3 µs (2.6% of max allowed) CE’s longest IST response time was 103 µs (20.6% of max allowed) Conclusion CE’s response time was well within the requirements Project in case study went ahead and did well MAXIMUM ISR LATENCY INTERRUPT!

Normal Int Off Normal Thread Thread

IST

ISR OAL

Scheduler Scheduler

ISH ISH KERNEL

ISR Latency IST Latency Interrupts Disabled Preemption Disabled MAXIMUM IST LATENCY INTERRUPT!

Normal Normal Thread Thread

IST

ISR OAL

KCall KCall Scheduler Scheduler

ISH ISH KERNEL

ISR Latency IST Latency Interrupts Disabled Preemption Disabled DEBUGGER OVERVIEW Debug builds Debugger support enabled by default Optimizations disabled by default resulting in more accurate debugging experience Considerations: Ability to add asserts Not the code that ships since some code maybe included only in debug (/check) builds Some bugs may only happen in retail builds. For example, timing sensitive code. Results in larger images Implemented as standard Visual Studio tool windows: Supports drag and drop Allows tabbed document, docking and floating views Most windows support logging content to output window List of debugger windows: Breakpoints Watch Variables Callstack Threads Modules Processes Memory Disassembly Registers List Nearest Symbol Launch – Download & Start Target menu is your friend!

Remote Tools Verification & Performances Kernel Tracker  chronograms Call Profiler  execution times  system activity

Debug tools SPY++  Windows messages Heap Walker  malloc zone analysis Process Viewer  processus and threads

Utilities ZoomIn  screen copies File Viewer  target file system Registry Viewer  target registry System Infos  system parameters

Processes -> Threads -> Callstacks SHARED SOURCE OVERVIEW Shared Source Program Document. Debug. Adapt. Improve. Modify. Share. Kernel Library, , Device Drivers, and more! Access to millions of lines of source code Available to everyone Academic edition for courseware creation Built into Platform Builder, Click-through EULA Premium Source Program Document. Debug. Adapt. Improve. Modify. Networking Stack, GWES Available to eligible customers and partners Access secure remote repository Mostly Not ISV, OEM Available Available Provided

Applications

Embedded Shell Remote Windows CE Shell Services Connectivity

WIN32 APIs COREDLL, WINSOCK, OLE, COMMCTRL, COMMDLG, WININET, TAPI

Kernel Device File GWES Library Manager Manager TCP/IP IrDA IPv6 OAL Device Drivers File Drivers Bootloader Drivers

OEM Hardware Mostly Not ISV, OEM Available Available Provided

Applications

Embedded Shell Remote Connectivity Windows CE Shell Services

WIN32 APIs COREDLL, WINSOCK, OLE, COMMCTRL, COMMDLG, WININET, TAPI

Kernel Device File GWES Library Manager Manager TCP/IP IrDA IPv6 OAL Device Drivers File Drivers Bootloader Drivers

OEM Hardware MAJOR FEATURES OVERVIEW Next-generation file system Compatible with desktop Supports large files/disks (exFAT) SATA Driver, FAT32/exFAT boot loader Secure Digital Host Controller (SDHC 2.0) Data encryption Re-architected file system stack ** Cache Manager **UDFS v2.5 w/ Read support Wireless LAN enhancements Multiple radio support and faster AP-AP roaming Reduced power usage Added 802.11i support for WPA2 compliance Added 802.11e support for QoS Support for hardware offload for encryption (for example, AES Bluetooth) BT protocol stack performance optimizations Enhanced BT profiles: A2DP, AVRCP Windows Media DRM 10 PD and ND OCX 7 (ActiveX) NMD client UI-compliant with Windows Media Connect PlaysForSure compliant client DVR (MPEG-2 only) TIFF imaging support Video/audio capture pipeline HTTP 1.1 streamer Better interlace support Added VC-1 video support Virtual surround sound and multi-channel audio MP3 WMA WMV MP4 software codecs VoIP Video telephony, 3-way audio Applications Well-behaved applications (Win32-compatible) work with little to no changes Apps using CE-specific memory “tricks” may be problematic Use the “App Compat” tool to assess Backward Compatibility issues Windows Mobile 6.0 on Windows CE 5

World-readiness 14 languages supported in OS components Deeper functional testing across languages and locales to improve world-wide support in our OS features