360 likes | 557 Vues
Implementing CLR For Smart Personal Objects. Donald Thompson Architect Smart Personal Objects Microsoft Corporation. SPOT Goal.
E N D
Implementing CLR For Smart Personal Objects Donald Thompson Architect Smart Personal Objects Microsoft Corporation
SPOT Goal • Increase the usefulness of everydayobjects that we can wear, carry, or that might be scattered throughout the environment, ultimately making some activity easier and/or more enjoyable.
Initial Embodiment • The first product developed according to this vision is the Smart Watch • Everyday personal object serving some useful purpose • Core function has been improved by increasing its accuracy • Awareness (the key to smartness) • Your context, conditions, and interests • Effortless access to timely, personally-relevant information
SPOT v1 Overview Services Network Smart Objects • Watches • Accessories • Peripherals • Display surfaces • Appliances • Everyday objects • Personals • Mobiles • Sensors/Actuators • Toys Approx. 177 million people~80% of the North American population News Messages Alerts Location Personal Finance Entertainment Sports Appearance
SPOT Components • Custom silicon • MPU and wireless connectivity • New hardware platform • Small and energy-efficient enoughfor watch • New Microsoft software stack • Reliable, secure, energy efficient, safe, small, fast, extensible, portable, patchable, easy to develop for, ... • “Glanceable” user interface model • Accommodate a constrainedviewing surface
SPOT Components (cont.) • Persisted wireless connection, protocols, and service infrastructure • Delivering rich, personalized and dynamic content anywhere in North America, and eventually other geographies world-wide • User-friendly website • Configuration, user assistance, marketing, … • Back-end service integration • MSN billing, Passport, and dozens of other teams and services, internal and external to Microsoft • 24x7 datacenter and network operations • High-reliability, fault-tolerance, monitoring, alerting, reporting, …
Focus Of Talk • SPOT v1 embedded solution • Hardware • Custom silicon • Module • Software • System • Managed runtime • Externalization efforts • “Stamp” • Demo • Endpoint devices
Hardware PlatformCustom Silicon • “Stan” FM radio • Mixed analog / digital .18 um CMOS • Frequency agile (100 KHz) burst receiver • Low-power: 90 mW (on) / 30 uW (standby) • Small: 2.8 mm x 2.8 mm x 860 um • “Ollie” MPU • .18 um, 6 Metal Layer CMOS • ARM7 TDMI-S, 32-bit @ 27.6 MHz • ARCTAN, MAC, Viterbi FEC decoder • 512K ROM, 384K SRAM (single cycle) • Low-power: 1.8 mW / MHz • Small: 6.8 mm x 6.8 mm x 860 um Stan Ollie
Processor support 27.6 MHz ARM7TDMI Clock may be divided down or run from RTC 1.8V Core, 3.3V I/O 32768 Hz RTC Full interrupt controller Supports clock stop and wakeup modes from any interrupt source Timers (x4) Usable in PWM and/or capture modes May be individually split into dual 16-bit timers Clock sources may be system clock, system clock divided or external Dual Serial Ports 3.3V Levels Useable in synchronous or asynchronous modes Hardware flow control supported USB 1.1 Full speed (12 Mbps) support SPI Operation up to 13.8 MHz Dual automatic chip selects 8-bit or 16-bit word widths ADC 8-bit samples at up to 100Ksps 4 Channel Multiplexed Flash ROM: 1/2/4MB EEPROM (optional) Various peripherals LCD, battery (charge circuit, thermistor), radio, buttons, piezo, vibrator, backlight, sensors, etc. Hardware PlatformCustom Modules
Software Requirements • Soft real-time Microsoft platform • Suitable for custom, highly constrained ROM and Flash devices • Low duty-cycles (~3%) and energy-efficiency (3-5 days) • While continuously receiving and displaying wireless data • Extremely reliable • Watches shouldn’t crash! • Extremely memory-conscious • Low memory conditions mustn’t degrade user experience • Allow room for additional functionality over lifetime • Extensible and flexible architecture • Enable class of device, not just single product • Provide mechanism for OTA updates • Enable rapid development (internal and external) • Using Visual Studio.NET
SPOT Client Architecture Apps/Channels Apps/Channels Apps/Channels Application Support (Libraries, Shell, Crypto, Graphics, …) Bootstrap CLR HAL and Drivers Processor and Peripherals
System Software TinyHAL • Designed specifically to service runtime • Bootstrap • Hardware abstraction layer • Asynchronous driver execution • Queued, prioritized, incremental • Simple • No scheduler or heaps • Minimal locking • Small • ~40K (including extensive core drivers) • Efficient • Optimal method for given situation (time/energy) • Driver extensibility and dynamic load/unload
Managed Runtime TinyCLR • Derived from ECMA standard • CLR / CLS / CLI • Extensions appropriate to device class • Small • runtime and trimmed framework library: ~132 KB • Suitable for microcontroller/embedded solutions • < 1MB footprint • Fast • ~.5 MIPS @ 27 MHz (interpreted) • Programmable and debug-able with Visual Studio.NET (C#)
Dude, Where’s My OS? • TinyCLR provides functionality typical of kernel • Multi-threading/tasking • Memory management (garbage collection) • I/O • Needs TinyHAL for access to peripherals • Benefits from native code efficiency • TinyHAL doesn’t contain a kernel • Handles ISRs and provides “services” for asynchronous driver processing • More like “.NET on a chip”
Energy Efficiency • Treat idle CPU as resource to consume • Expecting low utilization == simpler code • Designing for low energy != design for max utilization • Cheap sleep • 4.7uSec to sleep CPU • DSR vs. “do it now” vs. sleep in place • Reducing clock speed while doing short spins
Energy Efficiency (cont.) • No polling • All hardware is event-driven • Hardware accelerators for radio processing • Parallel execution • Order of magnitude energy savings compared to native code on Ollie
Execution Model • Single application thread • No multi-tasking scheduler • Could make scheduler more sophisticated • No clear benefit for extra energy used to do so • Interrupt Service Routines • Re-entrant • Mask-able • Prioritized • Never propagates into app • Worst case ISR latency ~200uSec • Hardware raise code execution
Execution Model (cont.) • Deferred Service Routines (DSR) • Continuations • Invoked when TinyCLR is idle (sleep) • Round-robin scheduled with managed code execution • Drivers • Cooperative multi-tasking • Work is explicitly broken into <10ms chunks • State preserved for resumed execution • Callbacks • Use the continuation mechanism • Asynchronous notification • Registered when I/O requested • Completions • Timer ISR initiated (40uSec granularity) • Execute code at specific point in time • E.g., power regulator warm-up for burst radio capture
Execution Model (cont.) • Managed code execution • Time sliced thread management • 20ms slices (preemptive) • Non-preemptive for unmanaged • Interpreted • Smaller footprint • Fine-grain control over execution • Unmanaged code execution • Native methods interspersed with managed code • Single implicit app domain • Support loading/unloading of assemblies
Type System • Only managed types and safe instructions • Support of CLS and traditional .NET types • Numeric, class, value, arrays, delegates, events, references, weak references, date / time, … • No support for: • Multi-dimensional (sparse, jagged) arrays • Machine-dependent types (element type I, U) • Allows unsafe conversions • Strings are represented in UTF-8 • Exposed as Unicode • Runtime treatment • Value types emulated by runtime (not 1st class) • Allows for GC optimization • Saves RAM
Type System (cont.) • Global, shared string table • Well-known values • Types, methods, fields • Reduces xrefs between assemblies • Patching • Method and resource substitutions • New types, but no type substitution • Tools • Diffs assemblies • Generates patch assembly
Garbage Collection • Balance between speed and size (RAM) • Mark and sweep • Generational too heavy-weight • Non-incremental • Doesn’t require metadata • All data is self-describing • Support for non-volatile storage
Framework Support • Essential subset • Synchronization, Threads, Timers • Reflection • extremely important, it's the basis for the extensibility of the system • Serialization • Exception handling • very important for fault tolerance • No current need for HTTP, XML, Interop, WinForms, …
CLR Extensions • “Not so weak” references • Prioritized • Time stamped • Persisted • RAM • Survives crash/reboots • CRC’d to protect against corruption • EEPROM or Flash • Survives power failures • Provides “automatic” data management • Old application “content” is GC’d like everything else • Priority is used by apps to help control order of disposal
CLR Extensions (cont.) • “Weak” delegates • Runtime manages dangling refs • Execution constraints (sub-threads) • Serialization engine • Heavy reliance on attributes to guide data encoding • New attributes • Bit packed, scaled, array size, not null, fixed type, …
What Is Embeddable Now? • Honestly – nothing available at this point but… • We are developing several platforms and licensing options • What we do, in what order, and to what extent may depend on you • What are the opportunities out there? • Where are the real businesses? • What you see here are potential opportunities
Stamp Kit Goals • Enable hobbyists, educators, and researchers in embedded • Rapid prototyping of embedded solutions • Drive .NET platform adoption • Drive SPOT platform adoption • Provide an extensible platform for future products
Stamp Development Environment • Stamp chip • Packaged Ollie+ • Stamp Development Board • Hardware development environment • Visual Studio.NET integration • Wizards, programming, debugging, deployment • Runtime libraries and support files • Optimized for Stamp applications • Development Board accessories • Power adapter, USB cable • MSDN • Online documentation, sample code
Stamp Chip • SPOT MPU (“Ollie”) • Same as in production Smart Watches • DIP • 4MB Flash (32-bit) • 8 LEDs • Green, yellow, red and super-red • ADC • 4 channel (multiplexed)
Stamp socket Breadboard Power connectivity Power supply LCD USB connector Reset circuitry Audio amplifier for external speaker I/O headers Serial ports D/A converter Buffer Momentary contact buttons Stamp Development Board
Demo Rich DaviesProgram Manager SPOT Stamp
MSND Endpoint Module • Provides existing MSND channels on other devices • SPOT module + OAK • Includes Stan, Ollie, power components, radio components, antenna on PCB, built and tested • Supports serial, USB, and SPI interfaces • No firm pricing yet – approx $50/250K • Proprietary content/bandwidth • Really great deals will be considered • Can be done regionally or nationally • No pricing model at this point
PC Channels • Client 1.1 (with USB support) • PC applications can communicate directly with SPOT enabled devices • Custom channels/applications can be broadcast to devices via MSN Direct • Client 2.0 projected for 1H/05 • Assemblies can be loaded onto the device locally • “Secret Sauce”
Contacts • {DonThom, RichD, STansley} @microsoft.com
© 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.