Mobile Makeover: Hijack a Smart Phone Interface for embedded-systems control
( 01 Jan 2007 )
Warren Webb, Technical Editor EDN
As smart-phone sales soar, designers have their eyes on the built-in programmable graphics, growing processing power, and communications options to replace or augment one of the most challenging and expensive embedded-systems components: the user interface. With the right setup, a few clicks on a portable smart phone can connect you with and put you in charge of any embedded device. If you add special software, a smart phone can copy the look and feel of proprietary products and present a user experience similar to that of a custom embedded hardware interface at a fraction of the development cost and schedule.
There are plenty of applications in which a smart phone could act as a controller for embedded devices, such as industrial controllers, accesscontrol products, medical instruments, security systems, environmental controls, and even home-automation devices. For example, MP4 Solutions offers the Airstrip OB smart-phone application, which allows obstetricians to remotely access real-time fetal-heart tracings and maternal-contraction patterns from General Electric's Centricity Perinatal information system (Figure 1). The smart phone's real-time display eliminates possible mistakes in interpretation by the nursing staff and allows the doctor to more frequently check on patients. The Airstrip OB supports multiple physicians accessing multiple patients and maintaining the privacy protections that the Health Insurance Portability and Accountability Act requires. Doctors pay $300 per year or $30 per month for an Airstrip OB license.
Smart-phone or convergedmobile- device technology combines PDA features, multimedia recorders and players, digital communications, and Internet access into a pocket-sized form factor. And, by the way, these devices also make phone calls. Smart phones have virtually killed the portable-PDA market and, as they grow in processing power, are assuming many of the tasks formerly requiring a laptop computer. IDC reports that worldwide shipments of converged-mobile devices reached a record of 19.3 million units for the second quarter of 2006, marking a 1.9% sequential increase and a 42.1% year-over-year increase. IDC defines a converged mobile device as a mobile phone having a high-level operating system, such as BlackBerry, Linux, Palm, Symbian, or Windows Mobile.
FLEXIBLE PHONES Smart phones offer embeddedsystem designers a number of benefits over custom hardware. In addition to the obvious cost and size advantages, smart phones offer design flexibility. A single smart phone can control multiple embedded devices, and, conversely, multiple authorized users can control a single embedded device. Depending on the capabilities of the embedded system and the phone, users can exchange wireless data over short-range technologies, such as infrared or Bluetooth; medium-range 802.11 networks; or long-range cellular systems. Yet, smart-phone adoption brings plenty of problems with it. For example, security and privacy concerns may significantly complicate the software. Also, each user requires a smart phone with application software and data service. Smart phones are available with a variety of form factors, screen sizes, processor speeds, and operating systems. This range of choices allows users to select the exact performance they need but creates integration and interoperability problems for embedded-system designers. Finally, in most large enterprises, the informationtechnology department dictates cellphone policy and carrier selection.
Most smart phones operate on CDMA (code-division-multipleaccess) or GSM (global system for mobile communications) cellular networks. With CDMA, the frequency of the transmitted signal hops according to a defined code, and only a receiver following the same set of frequencies can detect it. CDMA permits many radios to share the same frequency channel. GSM is the most popular cellular standard: More than 2 billion people in more than 200 countries use it. Most cellular technologies have a third-generation evolution path to extend data rates for highbandwidth- system applications. Examples are EDGE (enhanced data rates for GSM evolution) and EV-DO (evolution-data optimized).
Several ways exist for interfacing a smart phone with an embedded device over an available communications link. The basic design challenge is to integrate communications hardware and software into the embedded device and possibly develop a custom application for the handset. A popular approach is to add Webserver features to the embedded device to incorporate Internet connectivity. If the embedded product has surplus processing power and a communications port, designers can add Web-server software directly into the firmware. For example, the open-source, small-footprint AppWeb Web server aims at embedded devices and applications. The software is licensed under the GNU opensource license, and a community of developers supports it. It provides a standards-based, dynamic Webpage- creation environment. You can download the free App-Web software with full source code at www.appWebserver.org.
WEB SERVER To retrofit products with limited expansion capability, you can opt for a drop-in Web-server module that includes a serial interface to your embedded product on one end and an Ethernet interface on the other. The Web server includes networking software, leaving the designer free to concentrate on the embeddedsystem application. The $30 SitePlayer module from NetMedia and the $50 Xport embedded- Ethernet-device server from Lantronix are examples of add-on Web servers. Each device allows you to create smart-phonecompatible Web pages using standard HTML (Hypertext Markup Language) -authoring tools and download them directly to built-in Flash memory. You can then communicate with and control the device from any standard or smartphone browser.
Short-range wireless links, such as infrared, Bluetooth, and Wi-Fi, can also provide the connectivity necessary to control or monitor an embedded device. Many smart phones offer built-in Bluetooth transceivers to wirelessly link to nearby devices, such as headsets, GPS (global positioning system) modules, other smart phones, and PCs, for synchronization. With an embedded device that integrates a Bluetooth transceiver for a custom smart-phone application, you can establish a user interface for short-range, interactive applications. You can establish a similar communications link over the infrared channel, but alignment is sometimes tricky, depending on sensor placement. Although Wi-Fi transceivers would provide a longer range connection, smart-phone carriers hesitate to include the capability because a VOIP (voiceover- Internet Protocol) connection could bypass their per-minute charges.
Although you can launch an embedded user interface by simply selecting the Web server's address through the smart phone's browser, a few software modifications create a more customized look and feel and simplify the process. Most smart-phone vendors provide development tools to encourage third parties to develop software add-ons, increasing handset sales or extending per-minute charges. Although embedded devices in general use a wide array of software vendors plus in-house custom software, smart-phone software comes from very few sources. Operating systems, such as embedded Linux, and systems from Symbian, Windows Mobile, Palm, and Research in Motion account for most smart-phone platforms.
OPERATING SYSTEMS A large group of cellphone manufacturers, including Nokia, Ericsson, Sony, and Samsung, own and support Symbian, which has the largest smart-phone market share. The Symbian OS includes a real-time, multithreaded, preemptive kernel and supports most telephony, messaging, and multimedia protocols. The developers of Symbian designed it for handheld devices, and it had limited resources and a strong emphasis on conserving memory and power. Symbian offers a complete set of development tools, including both paid and free versions, on its Web site.
The Palm-operating-systemdevelopment tools are more mature than those from any other smartphone- software supplier, but the company has split, creating some confusion among developers. PalmOne is the hardware spin-off of Palm, and PalmSource, which Access recently acquired, maintains the Palm operating systems and works with third-party developers. Application developers can choose from C, C+ +, Visual Basic, or Java programming languages plus the Freescale CodeWarrior or Eclipse integrated development environments. You can find development tools, documentation, and tutorials at the PalmSource Web site.
Linux, the fastest growing operating system for smart phones, provides developers with opensource code, freedom from licensing restrictions, free development tools, and a huge support community. Supporting this rapid growth, a spokesman recently announced that Linux will power more than half of the mobile phones that Motorola ships within two years. Evans Data Corp. (www.evansdata.com) reports that almost one-quarter of all smart phones sold in 2005 used the Linux operating system. However, Linux has some problems. Critics claim that Linux smart-phone platforms suffer from fragmentation and interoperability issues due to the ease with which developer groups can modify their code. The LIPS (Linux Phone Standards) Forum and the OSDL (Open Source Development Labs) have recently teamed up to define standards that promise to turn Linux into a plugand- play mobile-phone platform.
WINDOWS TO GO To support its latest operating software for Pocket PC and smartphone devices, Windows Mobile 5, Microsoft revamped its tool structure and designated Visual Studio 2005 as the main integrated development environment for building all Windows mobile applications. Developers have a language choice of C++, C#, and Visual Basic, plus an expanded set of application-programming interfaces for mobile devices. Visual Studio 2005 also provides device emulators to simulate applicationsoftware operation directly on the PC workstation. You can find a detailed overview of Microsoft's tools, tutorials, and sample applications at the Windows Mobile Developer's (www.microsoft.com) center.
Since I have access to a fairly new Motorola Q smart phone based on the Windows Mobile 5 platform, I decided to use it to create a basic user interface to monitor and control a simple embedded device. The Motorola Q includes a 320240-pixel display, a full QWERTY keyboard, EV-DO support, integrated Bluetooth, a speakerphone, a 1.3 million-pixel camera, and extensive multimedia features. With a built-in Web browser and e-mail capability, the Q has all the communications functions necessary to serve as an embedded user interface.
My first task was to locate the development tools necessary to create custom applications for the Q. I started at the Microsoftdeveloper Web site to download the smart-phone SDK (software developer's kit) and a 90-day trial copy of Visual Studio 2005. As soon as I discovered that the combined download was nearly 3Gbytes, I coughed up the $13 to have Microsoft deliver the DVDs by mail and prepared for a long wait. I was surprised to find the package from Microsoft in my mailbox in just two days. Installation was straightforward, and I was able to test some sample applications within a few hours. I then ventured to the Motorola developer Web site, where I found the Q developer guide with instructions for installing the company's custom emulator image into Visual Studio 2005.
WEB VIEW Now, with a complete development environment for Motorola Q, I needed an embedded system to control. Luckily, I had on hand a developer kit for the SitePlayer Web server that could simulate a rudimentary embedded device. The $100 kit includes a host board with LEDs and switches, a temperature sensor, and a SitePlayer module (Figure 2). The kit also includes sample software and a library of graphical knobs, switches, LEDs, and other user-interface tools to aid in Web-page development. With a serial connection to my laptop and an Ethernet link into my home network, I could interact with the sample Web pages preloaded into the SitePlayer. I could control two LEDs and read the state of two switches from the development kit with my standard browser pointing to the SitePlayer's factory-set IP address.
To create custom Web pages to download to the SitePlayer, I needed an HTML-authoring tool that could modify the sample code that NetMedia provides. With a quick Google search, I found and downloaded the free Nvu (new view) Web-authoring system. Nvu allows WYSIWYG editing of pages without dealing with the HTML structure and has features similar to those of Microsoft's FrontPage and Adobe's Dreamweaver. After a short learning process, I was able to load the sample pages, retain the hardware hooks, and create all new pages tailored to the small smartphone graphical display. The opensource Nvu system is available under the Mozilla public license.
The final step in the process was to create a special smart-phone application for the Motorola Q that would bypass the normal Webaddress- navigation details and directly display the user-interface page from the SitePlayer when I invoked it. At first, I was expecting a huge learning curve, given the tools and features built into Visual Studio and the Compact Framework details for Windows Mobile 5. However, after watching a few of the online tutorials from the Microsoft developer's site, I found that my application was simple and required only a single line of code to identify the URL of the SitePlayer. With the smart-phone SDK installed, I could drag and drop my control, the WebBrowser, onto the simulated display, add my line of code, build the object code, and deploy the result onto the Motorola Q emulator directly from the Visual Studio programming environment (Figure 3). OK, maybe it wasn't as simple as it sounds. I had problems deciphering the device controls, connecting the emulator to my network, and formatting the Web pages for the 320x240-pixel display.
Although the application turned out to be simpler than I had first envisioned, I was able to turn the LEDs on and off from the application by selecting the appropriate link and clicking the center of the five-way switch on the smart-phone emulator (Figure 4). The system could also display switch settings, although not in real time. The way that I wrote the application required a page refresh to read the current switch statesprobably not acceptable to the marketing folks. Notwithstanding the tiny shortcomings in my application software, the smartphone user-interface concept has enormous potential to reduce the cost and schedule for embeddedsystem projects.
AUTHOR INFORMATION You can reach Technical Editor Warren Webb at 1-858-513-3713 and wwebb@edn.com