Engineers Guide to Embedded Linux and Android

www.eecatalog.com/embeddedlinuxEngineers Guideto Embedded Linux& AndroidAnnual Industry GuideSolutions for engineers and embedded developers using Embedded Linux and AndroidFeatured ProductsEnea Linux PlatformBuilderFrom TeamF1: SecureF1rst Network Attached Storage SolutionFrom EMAC: PPC-E7+Yocto Project Big in Embedded LinuxIs Device Security a Major Challenge for Open Source Software?Android Dives into Embedded Despite Fragmentation RisksEECatalogGold Sponsors Platinum SponsorScan thisQR code to subscribe2 Engineers Guide to Embedded Linux and Android 2012Welcome to the Engineers Guide to Embedded Linux and Android 2012Linux in its many iterations including Android continues to make headway in embedded designs. In fact, growth is expected to maintain double-digit increases through 2013, according to VDC Research. This issue is chock-full of information to help you keep up. In Yocto Project Big in Embedded Linux, The Linux Foundation explains the advantages of Linux and the Yocto open collaboration that provides tools and infrastructure to help create custom Linux-based systems for embedded products regardless of the hardware architecture.Throughout this issue, key vendors provide detailed insight into some of the most important considerations for embedded Linux designs, including multicore development, accessory design, and device security. See the Mentor Graphics article How Do You Eat a Multicore Elephant?; Microchips Utilizing Googles New Open Accessory Framework for Android Acces-sory Designs; and Wind Rivers Is Device Security a Major Challenge for Open Source Sof tware? We also look at some interesting trends in modeling open source design in a discus-sion with Embedded Market Forecasters Jerry Krasner. And our roundtable discussion covers development challenges and opportunities, security and the ups and downs of Android in embedded applications. Of course, youll also find lots more information in these pages on the products and services you need to succeed in your embedded Android and Linux applica-tions.We hope you enjoy this EE Catalog Resource Guide. As always, wed love to hear your feedback, thoughts and comments. Send them to [email protected] yl B er gl und CoupEditorP.S. To subscribe to our series of Engineers Guides for embedded developers and engineers, visit:www.eecatalog.com/subscribeEngineers Guide to Embedded Linux and Android 2012www.eecatalog.com/embeddedlinuxVP/Associate PublisherClair [email protected](415) 255-0390 ext. 15EditorialEditorial DirectorJohn [email protected](503) 614-1082EditorCheryl [email protected]/ProductionProduction Manager Spryte HeitheckerGraphic DesignersKeith Kelly - SeniorNicky JacobsonProduction AssistantJenn Burkhardt Senior Web DeveloperMariam MoattariAdvertising/Reprint SalesVP/Associate PublisherEmbedded Electronics Media GroupClair [email protected](415) 255-0390 ext. 15Sales ManagerMarcy [email protected](510) 919-4788Marketing/CirculationJenna Johnson To Subscribewww.extensionmedia.com/freeExtension Media, LLCCorporate OffcePresident and PublisherVince [email protected] President, Sales Embedded Electronics Media GroupClair [email protected] President, Marketing and Product DevelopmentKaren [email protected] President, Business DevelopmentMelissa [email protected] Thanks to Our SponsorsThe Engineers Guide to Embedded Linux and Android is published by Extension Media LLC. Extension Media makes no warranty for the use of its products and assumes no responsibility for any errors which may appear in this Catalog nor does it make a commitment to update the information contained herein. Engineers Guide to Embedded Linux and Android is Copyright 2011 Extension Media LLC. No information in this Catalog may be reproduced without expressed written permission from Extension Media @ 1786 18th Street, San Francisco, CA 94107-2343.All registered trademarks and trademarks included in this Catalog are held by their respective companies. Every attempt was made to include all trademarks and registered trademarks where indicated by their companies.Wind River1981 Wind River is founded.1991 Linux is born.2004 Wind River releases Wind River Linux 1.0.2009 Wind River is the No. 1 commercial embedded Linux. 2010 Wind River releases Wind River Linux 4.2010 Wind River joins the Yocto Project.2011 Wind River releases Wind River Linux Secure.2011 Linux turns 20.2011 Wind River announces Wind River Linux Graphics Release.r Salutes 20 Years of LinuxThursday, August 18 at 10:30 amUser Space Tracing in Small Footprint Devices (How Low Can You Go?) Jason Wessel, Principal Technologist, Wind RiverFriday, August 19 at 10:15 amWhere is the Money in Open Source? Business Models and the Marketing of Open Source TechnologiesNithya Ruff, Senior Director of Linux Product Marketing, Wind River6 Engineers Guide to Embedded Linux and Android 2012ContentsNo Free Lunch with Embedded Operating SystemsBy Cheryl Coup...................................................................................................................................................................... 8Android Dives into Embedded Despite Fragmentation RisksBy Cheryl Coup...................................................................................................................................................................... 9Yocto Project Big in Embedded LinuxBy Rudolf Streif, director of embedded solutions, The Linux Foundation.............................................................................. 13From Zero to Boot: Porting Android to your ARM platformBy Vassilis Laganakos, senior embedded software engineer, ARM Ltd. .............................................................................. 17How Do You Eat a Multicore Elephant?By Stephen Olsen, Mentor Graphics..................................................................................................................................... 20Utilizing Googles New Open Accessory Framework for Android Accessory DesignsBy David Flowers, principal applications engineer, Advanced Microcontroller Architecture Division, Microchip Technology Inc..........23Crunching the Numbers: Sensors as Co-Processors in Next-Gen Smartphones?By Ed Brachocki, Kionix & Stephen Maine, Opta3 IIc ........................................................................................................... 27Online & Offline Embedded Linux and Android Resources ...................................................................30Is Device Security a Major Challenge for Open Source Software?By Milind Kukanur, senior product manager, Wind River ..................................................................................................... 40Products and ServicesHardware / Hardware ToolsBoardsEMAC, IncPPC-E7+..........................................................................31Software ProductsSoftware Development ToolsMentor Embedded Linux SolutionsThe Mentor approach streamlines platform creationand application development allowing you to focuson value-add contributions............................................32Operating Systems / DistributionsEneaEnea Linux PlatformBuilder ...........................................33Networking / Communication LibrariesTeamF1, Inc. SecureF1rst CPE Gateway Solution ..............................35Networking / Communication PackagesTeamF1, Inc. SecureF1rst Network Attached Storage Solution.........36SecureF1rst Security Gateway Solution .......................37ServicesTrainingThe PTR GroupEmbedded Linux and Android Training Classes ............398 Engineers Guide to Embedded Linux and Android 2012EECatalogINDUSTRY FORECASTTe interview is by phone, but the rueful shake of the head is nearly audible as Jerry Krasner, founder and principal analyst for Embedded Market Forecasters says, I still get calls from CFOs saying, You know, we thought Linux was free. Were eight months out and weve run out of our budget what hap-pened? Krasners research approach is to look at the total costs relating to the embedded operating system choice, including number of developers per project, the percentage of projects that are cancelled, come in on time or on budget,and how close the nal design met design expectations. What he has found is that every commercial Linux distribution (including Android) out-performs free Linux in terms of development-cost return on investment (ROI).And while Linux in all its iterations is rmly entrenched in the embedded world, Android is just beginning to make a splash. Last year, Krasners research indicated that eight percent of responding developers were using Android, but that response jumped to 18 percent this year. After watching growth of other so-called cant miss operating systems such as Symbian, however, Krasner is waiting to see a pattern of year-over-year growth before declaring Android a winner. In the meantime, he is seeing positive trends with Android compared to a range of commercial Linux distributions. From a development-time and manpower standpoint, Android is competitive with an average of 15 months and 7.4 developers per project. Tat compares to an average development time of 13.8 months for Nucleus, 18 for Integrity, 16 for VxWorks and 13.7 for LynxOS, while the number of developers per project ranges from 8.1 for Nucleus to between 13 and 15 for Integrity, VxWorks and LynxOS. Android is also compelling in terms of design cost. Embedded Market Forecast sees an industry average for an embedded design of about $2.3 million, while the average cost of an Android design is $1.23 million per project. In comparison, average design costs for Nucleus came in at $1.21 million, Integrity $2.96 million, VxWorks $2.6 mil-lion and LynxOS $1.8 million per project. However, Krasner also found that development strategies are changing and the operating system is the least signicant element in terms of containing cost and getting to market. Krasner explains, Back in 2004 we asked, How close to your pre-design expectation was your nal design for performance, system functionality, features and schedule? A full 30 percent of respondents were saying they werent within 50 percent. Tats outrageous. It changed in 2005 and has been improving every year since then. When we worked back through our data what we came to nd out was that this was the emergence of OS-agnostic IDEs. Krasner notes that in 2005, only seven percent of developers were using Eclipse, compared to 40 per-cent today. As developers move towards environments that best suit their needs, he is also seeing a growth in the use of UML modeling simulation, and particularly Rhapsody and Simulink, which allow object-oriented and C developers to work on a project simultaneously. As an additional advantage, if the hardware changes the developer can use the modeling tool to port the APIs already developed to the new hardware conguration. According to Krasner, depending on the vertical, theres any-where from a 30 percent to 90 percent ROI advantage by using modeling. Embedded Market Forecasters also compared data on companies whose designs were behind schedule and found that companies using modeling were seven times more likely to be in the group that had 30 percent or less of all of their designs behind schedule.Te other trend that Krasner highlights is the move to selecting an operating system based on its appropriateness for the appli-cation. He believes that companies are becoming less likely to take on the overhead of a powerful or mission-critical (real-time) operating system if they dont need it. Large pending cut-backs in defense spending are expected to ripple down through suppliers, especially those focused on mission-critical operating systems. In contrast, small real-time operating systems such as TreadX and Micrium can be used in mission-critical and non-mission-critical applications; TreadX is now on a billion products, compared to MontaVista on 700 million and Nucleus on 500 million. According to Embedded Market Forecasters, the mission-critical market is only about eight percent of the total in terms of users. Tat may be large in terms of revenue, but as developers question whether a spe-cic application needs the overhead, there may be a transition to smaller, more manageable operating systems.Cheryl Berglund Coup is editor of EECatalog.com. Her articles have appeared in EE Times, Electronic Business, Microsoft Embedded Review and Win-dows Developers Journal and she has developed presentations for the Embedded Systems Conference and ICSPAT. She has held a variety of production, technical marketing and writing positions within technology com-panies and agencies in the Northwest.No Free Lunch with Embedded Operating SystemsTotal Development Costs Drive OS DecisionBy Cheryl Coupwww.eecatalog.com/embeddedlinux 9EECatalogSPECIAL FEATUREIn a July 2011 research note, VDC Research analyst Jared Weiner stated that the commercial market for Linux-related software and services passed $140 million in 2010 and is expected to maintain double-digit growth through 2013. Weiner also expects Android-related services and support will be among the largest drivers of growth in the broader Linux market as interest grows among embedded developers. In our roundtable discussion, participants see fragmentation risks running alongside the opportunities for Android in embedded applications. But theres no doubt that Linux in its many iterations is a hot topic. EE Catalog talked to Dan Noal, senior solutions architect, and Nithya Ruff, senior director of product marketing for Linux, both at Wind River, along with Brian Gildon, director of strategic alliances at Enea, and Rod Crawford, principal engineer and Philippe Robin, Linux program manager, for ARM to get their insight.EE Catalog: How are embedded Linux developers bal-ancing application requirements such as performance, battery life and extensibility for future needs?Brian Gildon, Enea: Requirements are often application-specific and as we all know subject to change. The key to bal-ancing requirements while developing a future-proof platform is to have an extremely flexible Linux build environment that allows you evaluate multiple configurations its really about smart OS configuration. With the emergence of multicore this is becoming even more important with the ability to further balance performance versus power through core management. The emerging platform-builder development model gives developers just such an environ-ment. The platform-builder paradigm permits the building of multiple custom distributions by the platform devel-opment team, permitting the configuration, build and test of custom Linux platforms derived from multiple sources and tailored to embedded silicon vendor optimizations. In the end, this methodology not only produces the best software for a given set of requirements but is also much more cost-effective and faster to develop.Dan Noal, Wind River: Each of these requirements is quite hardware dependent and different hardware platforms have dif-ferent strengths, with power management happening at both the silicon and software levels. A commercial embedded Linux solu-tion will be optimized for all these features, and provides developers with a choice of profiles to meet their require-ments.The popular Linux-based application platforms (e.g., Android, iOS) are focusing on providing platform fea-tures that permit the application developer to make some tradeoffs between performance and power consumption. The Android platform provides some basic heuristics to the user of the device to note which applications are con-suming the most power. As for extensibility, the appstore / marketplace concept is bringing the notion of extensibility to applications, while the relatively frequent platform revisions from platform owners (e.g., Google, Apple) are showing that a consumer can expect several revisions of the base platform during the life of their device. There is pressure on OEMs to accommodate the platform revisions for a reasonable period after a device is launched.Philippe Robin, ARM: This is a broad ques-tion. The answer really depends on the type of device and environment the developers are targeting. Linux developers use existing power-management features such as CPU-freq, CPUIdle and tools such as Powertop and PowerDebug to optimize how power is managed on given platforms and optimize policies accordingly. Linaro for instance now has a dedicated group working on opti-mizing this for ARM platforms (https://wiki.linaro.org/WorkingGroups/PowerManagement/) and contributing changes and optimizations to upstream projects. ARM and partners are constantly innovating new functionality to further optimize CPUs and platforms for power usage, pushing software developers to take advantage of these to enable products with longer battery life and improved experience.Android Dives into Embedded Despite Fragmentation RisksLinux Takes on Security and New Market OpportunitiesBy Cheryl Coup10 Engineers Guide to Embedded Linux and Android 2012EECatalogSPECIAL FEATUREEE Catalog: Android has lots of momentum behind it in the consumer arena. To succeed in the embedded space, are there specific challenges it must overcome or new opportunities on the horizon that will push it further?Gildon, Enea: Clearly fragmentation is a huge issue facing Android. Multi-sided software platforms, like Android, that bring together device makers, application developers, content suppliers and consumers require stable, reliable and interoperable software on which to build businesses and, of course enjoy a first-class user experience. The most successful software platforms are the ones that provide a seamless and reliable user experience no guessing about whether an application will work on not on a given device. As Android expands into devices beyond phones the user experience issue will become even more important.Dan Noal, Wind River: For each new segment, some spe-cific features are required for broad acceptance. Embedded is really a catch-all phrase that encompasses many segments. Android is a bit of a hybrid a Linux-based plat-form with some proprietary licenses involved that may create some resistance among open-source developers. For Android to gain momentum into traditional embedded areas, the embedded community will need to expand the Android platform to suit, which can lead to fragmenta-tion problems. Security is also an issue, as Android is an open platform potentially vulnerable to different types of exploits. We see Google being very active and responsive to reported issues. My feeling is that Android has a good chance in traditional embedded segments that share a lot of the same requirements as the consumer (smartphone, tablet) segments.Robin, ARM: Android is a very popular platform and is in a growing number of segments and devices. Its popu-larity and the number of applications available make it a very appealing solution. There are a large number of embedded devices, which are not necessarily as open as smartphones, for which Android may provide more than is actually needed. In such cases, custom-built Linux or RTOS-based solutions may still be more appropriate, due to either specific real-time constraints or the memory footprint available on the device. However, new hardware platforms being developed have ever-increasing capabili-ties and enable the use of Linux and Android solutions in some of these segments.Rod Crawford, ARM: I think one challenge relates to the purpose of Android and the primary driving force behind it: Android is a platform for consumer devices, driven by Google. Ultimately, what this means is the roadmap of the platform is driven primarily by Google for consumer devices. The platform is open source and developers are free to tailor it and re-purpose it for, say, embedded devices. However, it is unlikely that the work undertaken to change or supplement Android for embedded devices will make it in the main Android code-base. Therefore, when Google releases a new version of Android into the open-source world, the work done to tailor and repurpose Android for embedded devices will need to be repeated again on the new version of Android. This may be trivial or it may be significant there are no guarantees.EE Catalog: What are some of the key issues that are arising around security in embedded Linux?Gildon, Enea: As Linux grows in popularity (Android or otherwise), it increasingly becomes a target for hackers and malware. Kernel-level security is quite good as Linux is open source and smart distribution selection ensures that applications cannot take advantage of kernel space easily. User-space security is more difficult, and the pri-mary target of malware in Android. Security for user data and apps will improve as cryptography becomes more user-friendly and transparent. More policing of approved applications is needed by Google. There are a number of movements out there to increase security (taintdroid and guardianproject.info) are a couple.Nithya Ruff, Wind River: Interestingly, government agencies like the Department of Defense are beginning to understand that the Linux developer community itself is a security featurethe more eyes on the code, the more likely exploitable bugs are to be caught. And until Wind River created and certified an EAL 4+ embedded Linux platform, many people said it couldnt be done. One of the challenges has been the fact that SE Linux, which is a good solution for hardening Linux, was difficult to configure. If it wasnt applied right, it couldnt do the job. Some of the most significant security issues arise from the sheer number of connected devices in the market today, and the fact that until recently, device security had been a relatively ad hoc affair.Robin, ARM: Security needs to be approached with a holistic system view and not limited to a specific OS or individual technology. Much of this is governed by what the hardware platform can offer to enable security. In the case of ARM platforms, solutions like as ARM TrustZone can form part of the solution when closely integrated with software.EE Catalog: What are some of the most exciting trends or application areas youre watching in Android/Linux development?Gildon, Enea: Te rise of the multi-OS device that blends Linux, real-time operating systems and in many cases real-time executive environments is a trend that is taking o in high-performance market segments. Developers are seeing the www.eecatalog.com/embeddedlinux 11EECatalogSPECIAL FEATUREadvantages of combining the benets of the Linux software and tools ecosystem with the power and reliability of real-time environment. Te rise of multicore processors with 8, 16 and even more cores has made the multi-OS device a reality but developers continue to struggle with device debugging and optimization given the vast amount of congurability and complexity at their ngertips. At Enea, we think the next really important development is the tooling needed to maxi-mize performance in multicore, multi-OS development.Nithya Ru, Wind River: I see a kind of cross-breeding taking place for example, Android moving beyond mobile phones and tablets and embedded Linux showing increased real-time and virtualization capabilities. Both platforms are moving into new industries. Both are becoming more secure and capable of more sophisticated graphics and multimedia. One of the most exciting trends I see in the open-source community is col-laboration across the commercial and open-source embedded community around tools and infrastructure, as you nd in the Yocto project, an open-source project that provides templates, tools and methods to help create custom Linux-based systems for embedded products regardless of the hardware architec-ture. Tis will simplify and streamline the creation of Linux distributions for embedded devices.Robin, ARM: With the recent Android Open Accessory sup-port initiative, it will be interesting to see how this develops and enables interaction with a new range of devices and use cases. Android is increasingly being used as a software plat-form for new segments, so it will be interesting to see how this translates in terms of new applications and use cases.Crawford, ARM: I think one of the most interesting trends now is the Internet of things. We have been able to connect sensors and actuators to the Internet for some time, but really, there has been a lack of cohesive framework for this activity, as well as lack of thinking big. With Android@home, Google is making Android the central monitoring and control hub for the Internet of things within your home and beyond... your street, your city, your planet. Te Internet of things when seen at this scale, with Android as the enabler to connect the things to the cloud, means our devices will become far more intelli-gent and react not only to their own ambience but also to those around the world.Cheryl Berglund Coup is editor of EECatalog.com. Her articles have appeared in EE Times, Electronic Business, Microsoft Embedded Review and Windows Developers Journal and she has de-veloped presentations for the Embedded Systems Conference and ICSPAT. She has held a variety of production, technical marketing and writing positions within technology companies and agencies in the Northwest.Embedded Linux and Android ONLINEExplore... Directory of leading Embedded Linux and Android Solutions Top Stories and News White Papers Expert Opinions (Blogs) Exclusive Videos Valuable Articles Ask the ExpertsSign up for the quarterly Embedded Linux and Android E-Product Alertwww.eecatalog.com/embeddedlinuxThe Only Conference Focused on AdvancedTCA, AMC, and MicroTCA!AdvancedTCA Summit is the onlyevent with all the major vendors, industryassociations and key people working onAdvancedTCA, AMC and MicroTCA.These PICMG specs handle the latestprocessors, newest interfaces, and mostdemanding high-availability applications.This is the one-stop shop for evaluatingAdvancedTCA and MicroTCA productsand designs in telecom, storage server,embedded systems, medical equipment,instrumentation businesses andmilitary/defense/aerospace systems. Learn to develop next-generatIon networks andwIreless systems. dentIfy major market trends. Meet wIth potentIal partners,dIstrIbutors, consultants, and solutIon provIders. See the latest products!The Right Solution for High-Bandwidth SystemsREGISTER ONLINEwww.advancedTCAsummit.comNovember 1-2, 2011AdvancedTCA Summit & ExhibitionDoubleTree by Hilton Hotel San Jose2050 Gateway Place, San Jose, California USAwww.eecatalog.com/embeddedlinux 13EECatalogSPECIAL FEATUREYocto, the prefix in the metric system denoting a factor of 10-24, gives the name to an open-source collaboration project that greatly streamlines the creation of a custom Linux distribution for embedded devices. However, saying that the name is an understatement is an understatement itself.The Yocto Project (www.yoctoproject.org) is a complete embedded Linux system development environment with tools, recipes and documentation. The Yocto toolbox is self-contained and includes compilers, debuggers, pack-agers, an emulation environment, an application toolkit generator and many more, making it the ideal ready-to-go solution for embedded Linux developers. And yet, it is easy to use. The available resources, templates and documenta-tion cater to both novice and experienced embedded Linux developers.Community-tested images covering various build profiles across multiple architectures including ARM, MIPS, PPC, 32- and 64-bit x86 provide a solid starting point for new engineering efforts. Specific hardware platforms are sup-ported through board support package (BSP) layers for which the Yocto Project has developed a standard format.The icing on the cake is the Application Toolkit Generator that automatically creates a complete environment for engineers to develop applications on top of a platform created by the Yocto Project. This environment seamlessly integrates with a plug-in for the popular Eclipse IDE and can be shipped by device vendors together with their hard-ware platform to jump-start application developers.Why Linux? Why Yocto?A recent survey of embedded developers conducted by Embedded Market Forecasters (www.embeddedforecast.com) reported that two primary factors contributing to embedded developers choice of operating systems are cost (44.6%) and the availability of source code (33.1%). From this point of view, Linux seems to fit the bill quite nicely. However, Linux puts up some hurdles that not too long ago were hard for embedded systems and their developers to jump.Linux requires a file system. For Linux to run it must have a file system with read and write access. Until the ubiq-uitous availability of inexpensive and long-term reliable flash memory devices that typically meant a hard drive, which is not practical for most embedded use cases.Linux requires a memory management unit (MMU). Linux is a multi-tasking operating system; effective task-switching mandates that individual processes have their private space in physical memory that easily can be mapped into the CPUs address space. Typical microcon-trollers that are widely used for embedded applications do not provide an MMU. That did not pose too much of a problem in the past since embedded applications were mostly single-tasked and context switching was limited to interrupt service routines (ISRs). However, todays systems-on-chips (SOCs) provide multi-core CPUs with MMUs to meet customers demands for connected devices. No consumer would accept anymore that he or she cannot access the Internet or have a look at the calendar while conducting a phone call on a smartphone.Linux is non-monolithic and multi-sourced. While this is essentially a good thing because it lets developers easily customize the OS to fit their particular embedded devices, it poses the question of where to get a Linux distribution that fits the needs of embedded devices. For desktops and servers this problem has been solved by the many readily available distributions, but for embedded devices there is no such thing as a plug-and-play Linux distribution. And that is simply due to the fact that hardware for embedded devices is naturally much more diverse than standard desktop and server computers. That is where the Yocto Project provides a solution.What is Yocto?Contrary to popular belief, Yocto is not an embedded Linux distribution, but a kit of tools and recipes to create a custom Linux distribution from source. It relieves the embedded developer from identifying the proper pack-ages that make up a Linux distribution and download their sources as well as from setting up a system with the correct set of tools to build these packages and finally assemble them into an image that can be booted on the target device.The Yocto Project builds upon and extends a series of upstream open-source projects which form its toolkit. With each Yocto release, updated versions of these proj-ects with new features and bug fixes are included. Every Yocto Project Big in Embedded LinuxBy Rudolf Streif, director of embedded solutions, The Linux Foundation14 Engineers Guide to Embedded Linux and Android 2012EECatalogSPECIAL FEATUREnew release of Yocto also provides updated recipes and templates to track changes, features and bug fixes of the source packages that make up a Linux distribution such as the Linux kernel.At the center of Yocto is Poky (www.pokylinux.org), a platform-independent, cross-compiling layer that utilizes the OpenEmbedded core (www.openembedded.org). Poky provides the mechanism to download, patch, build and combine thousands of distributed open-source project to form a complete and coherent but fully customizable Linux software stack.Figure 1 depicts the Yocto workflow based on Open-Embedded. User Configuration, Metadata, Hardware Configuration, and Policy Management determine what Upstream Projects, Local Projects (stored on the develop-ers system) and what sources from optional Source Change Management systems to include, as well as control the individual process steps of the workflow. A Yocto Project release already contains configuration information and metadata that will produce a working Linux system image only requiring very minimal adaption to the developers local build environment.While Figure 1 shows a rather linear process consisting of the steps Source Fetching, Patch Application, Configure/Compile, Output Analysis for Packaging, Package Creation and QA Tests, these steps are in fact repeated for each source package and therefore potentially many thousand times before all PackageFeeds have been created and can be combined into an image. Therefore Yocto supports multi-processor and multi-core build systems by auto-matically calculating dependencies and executing process steps in parallel, hence greatly accelerating the entire build process. Of course, Yocto also manages changes and only rebuilds Package Feeds whose input, source, meta-data, dependencies, etc. have changed.To further simplify the process for novice as well as expe-rienced users, Yocto provides a series of different profiles that automatically create images for common applications:- poky-image-minimal A small image just capable of allowing a device to boot.- poky-image-base A console-only image that fully sup-ports the target device hardware.- poky-image-core An X11 image with simple applications such as terminal, editor and le manager.- poky-image-sato An X11 image with example GUI imple-mentation using Matchbox Window Manager, Sato theme and Pimlico applications. Te image also contains terminal, editor and le manager.- poky-image-sato-dev An X11 image similar to poky-image-sato but also includes a native toolchain and libraries needed to build applications on the device itself. Te image also includes testing and proling tools as well as debug symbols.Figure 1: OpenEmbedded Architecture Workfow (Source: www.yoctoproject.org)www.eecatalog.com/embeddedlinux 15EECatalogSPECIAL FEATURE- poky-image-lsb An image suitable for implementations that need to conform to Linux Standard Base (LSB).- meta-toolchain Tis prole creates an archive that con-tains a standalone toolchain that can be used externally to Yocto. Te archive also contains QEMU and the scripts necessary to run Yocto QEMU images.- meta-toolchain-sdk Tis prole create an archive that contains everything of the meta-toolchain prole but also includes headers and libraries to form a complete standalone SDK.The above list represents the most commonly used pro-files. Many more specialized profiles are available and the list continues to grow.Figure 2 shows the example GUI using Matchbox Window Manager with Sato theme desktop running from an image created with Yocto using the core-image-sato profile.Who Supports the Yocto Project?The Yocto Project is a Linux Foundation Workgroup. The project was incepted by Richard Purdie who has been appointed as a fellow of the Linux Foundation. In this capacity he is working full-time on the Yocto Project, OpenEmbedded and Poky.The Yocto Project software is designed and developed through a collaborative effort by an open community of professionals and volunteers and is supported by a series of participating organizations. It is open for collaboration to anyone who is positively contributing. Like many other open-source projects, the Yocto Project employs a gover-nance model consisting of various groups:- Contributors Professionals and volunteers contributing to the collaborative eort: code developers, documenters, users, etc.- Maintainers Te delegated authorities who review patches that are submitted by contributors and technical leaders, provide feedback to the developers and accept the ones that are appropriate.- Technical Leaders Along with maintainers, the technical leaders ensure excellence and functionality.- Interest Groups Tese groups dene and document the various requirements for the Yocto Project, which are formed around the strongest needs from the users.- Architect Te Projects architect provides overall tech-nical leadership and resolves conicts.- Advisory Board Te Projects advisory board inuences the interest groups to ensure that requirements are set for the Project. Its range of responsibilities also includes creating and resolving working groups to support the fulll-ment of the project objectives, appointing maintainers and technical leaders, and dening policies and procedures.Corporate supporters of the Yocto Project include semi-conductor companies, operating system vendors, OEMs and others. Through collaboration in the project they effectively are aligning their efforts to everybodys ben-efits. Semiconductor companies are lowering their R&D cost for providing software support for their SoCs; OSVs shorten their product development life cycles through reduced customization effort; and OEMs can focus on dif-ferentiating their products rather than developing basic and common functionality. Companies contributing to the project today include Cavium Networks, Dell, Freescale Semiconductor, Intel, LSI, Mentor Graphics, Mindspeed, MontaVista Software, NetLogic Microsystems, RidgeRun, Texas Instruments, Tilera, Timesys and Wind River, among others.Rudi Streif manages The Linux Foundationsinitiatives for embedded solutions, working with the community to provide environments and platforms for embedded Linux systems. Mr. Streif has an extensive background in embedded software development and bringing products based on Linux to market.Figure 2: Yocto image created with core-image-satoCan you afford to miss it? FREE admission, lunch, parking and prize drawing entries at each event. RTECC is your best opportunity to discover a new world of possibilities within the embedded market.Market-revealing keynote speakers Technically focused embedded seminars and workshopsVendors demonstrating newest technologiesNetwork with the brightest engineersENGINEERS INTO THE WORLD OF EMBEDDEDARE YOU BEING LEFT BEHIND?UPCOMING LOCATIONSDenver, CO 08/09/11Salt Lake City, UT 08/11/11Irvine, CA 08/23/11San Diego, CA 08/25/11www.RTECC.comREGISTER FOR FREE TODAY!Scan this QR code with your smartphone and REGISTER TO ANY UPCOMING RTECC EVENT INSTANTLY!Go to RTECC.com to download a QR readerwww.eecatalog.com/embeddedlinux 17EECatalogSPECIAL FEATUREIf you are in the embedded world, mobile phone industry or just a gadget-loving person, Android is a word you hear every day. Tis article gives an overview of the procedure for get-ting the popular OS, primarily designed for ARM, running on your favourite ARM-based system-on-chip (SoC) platform. In this article, we point out potential pitfalls, challenges and other issues that you may encounter.TerminologyTe following terms are used:- Mainlinc kcrncl - Lhc Iinux kcrncl LhaL you can gcL rom mainline http://www.kernel.org- Rccrcncc kcrncl- Lhc kcrncl you usc or your board, mosL likely a Mainline kernel, plus patches required to support your hardware.- Mcrgcd kcrncl - Lhc rcsulL o mcrging Lhc Android kcrncl with the Reference kernel.- Android kcrncl- Lhc kcrncl availablc rom Cooglc's Android Open Source Project. It contains Googles additions to the Mainline kernel. See http://android.git.kernel.orgZeroAndroids software stack has been developed and tested on many ARM platforms, so there are only a few things you need to change to get it to work on another ARM platform.Te procedure to port Android is composed of two parts: the kernel and the Android userspace lesystem. For the rst part, nd and merge the dierences between the Reference kernel and a matching version of the Android kernel, and congure it for Android. For the second part, things are simpler: just add your platform to the Android build system and build. It should just work. Google provides instructions on how to setup a build environ-ment (http://source.android.com/source/initializing.html). Conguring the Android lesystem to t your boot media and board set-up is important but not complicated.Te most common mistakes made are during the congura-tion step. Make sure to complete this step for both kernel and lesystem. Kernel SideTe general rule for the kernel is, if your Reference kernel does not work on your platform, then the merged Android kernel wont work either. It is therefore vital that your Refer-ence kernel is working correctly on your platform before you begin to merge the Android kernel.From Zero to Boot: Porting Android to your ARM platformBy Vassilis Laganakos, senior embedded software engineer, ARM Ltd.Diagram 1: Kernel Merging Procedure18 Engineers Guide to Embedded Linux and Android 2012EECatalogSPECIAL FEATURETe bulk of the work here is to produce a merged kernel source tree that contains both the changes to your reference kernel and the additions to the Android kernel.Working Linux Reference KernelTest to make sure you have a working Reference kernel and a Linux root lesystem functional on your board, i.e., boot to a Linux graphical environment. Te kernel should include all of the appropriate support required for a windowing system, such as graphics drivers for the framebuer or your graphics chip. You should also make sure that these drivers support the desired screen resolution. Te Linux root lesystem is only required to ensure the Reference kernel works and to test the Merged Kernel.It should be noted here that the Android releases after Cup-cake require double buering and page-ipping support from the graphics system, so you need to have support for this in your Reference kernel.Since the correct conguration of the kernel plays a major part, keep a copy of the .cong le of the functional Reference kernel, as you will be using it as a base conguration for the Merged kernel.Misconguring the kernel can cause the Android boot to fail on your device.Android KernelTe Android kernel should have the same revision as your Reference kernel. If that is not possible, use the closest kernel available. A usual trap for developers is use the latest Android kernel because it contains all the new features advertised. Revision mismatch between the two kernels will result in spending more time merging and debugging.Merge the Reference with the Android kernelTe recommended way to merge is to use git with the common ancestor of the two trees. Te git-merge command will produce a single tree that will keep the patching history and maintain all individual commits for you to search and inves-tigate. Tis is indispensable when it comes to merging and debugging.Configure and Build the Merged KernelUse the conguration le for your Reference kernel, saved earlier, to build the Merged kernel. During the conguration step, you may be asked about options that were not available in your Reference kernel due to the Android parts in the Merged kernel.Once built, conrm that the Merged Kernel boots and runs with your working Linux root lesystem.If it does not boot, take a step back and make sure merged code from the Android kernel source tree did not break anything in your Reference kernel. Start with the les in which you resolved merge conicts.Since this step is board-specic, there is no silver bullet to make things work. Te best practice is to use the same revision kernels.If it does boot, you can then add the options required for Android. Tis is the most important step of the port. You will at least need to have power management, wakelocks, ashmem, pmem, switch class support, android binder ipc, android logger, android adb and pda power supply enabled and working in the kernel. Be aware that conguration variable names tend to change between kernel versions.In multiprocessor systems, CPU hotplugging support is required. You should enable this if your ARM-based SoC has more than one core and you wish to boot a kernel with multi-processor support.When it comes to building the kernel, make sure that you use a toolchain version proven to work for that purpose.Userspace - The Android FilesystemTo test whether the Merged kernel works and to complete the port, the Android lesystem is required. Tis is straight-forward and in the worst case, you can just add and build a generic one for ARMv5 architecture, which will not give you the performance but will give you a starting point.Add and Configure your Device in the Android Source TreeEach build target denes the conguration for a platform and selects which sources should be built for Android. Google used to provide detailed instructions for adding support for a new device, but this information is no longer available. Neverthe-less, some basic guidelines are available on the Internet.Androids parts are mostly written in portable C code, apart from some ARM-assembly code mainly for the JIT engines, Dalvik and V8. Since the built binaries are ARM, the ARM ABI allows them to run in any compliant architecture version. For example, an ARMv5 binary will run on ARMv7 architecture platform. In Froyo, the support for two ABIsallows the distri-bution to run native ARM applications built for one specic architecture version (made with Android NDK).If you wish to add a non-supported ARM architecture version (e.g., ARMv6k), you need to provide to Dalvik the appropriate les that will allow it to generate code for that architecture version. Tis is required if you are targeting performance, but you should not do this in the initial port.Build Android for your SoCBuilding the generic Android lesystem is simple: use make. You will need to include additional arguments if you have dened your own platform and conguration. Using the tools www.eecatalog.com/embeddedlinux 19EECatalogSPECIAL FEATUREand scripts provided from the Android source tree will give you reliable result and better control over building specic parts. Note: you do not need to build Android as the root user.Configure the Android Root FilesystemOnce built, boot the Android root lesystem from USB sticks, MMC/SD cards or an NFS Server. Tere are a few things to check:- Makc surc Lhc kcrncl has supporL or Lhc mcdia you arc going to use.- Fnsurc you havc copicd Lhc conLcnLs o Lhc sysLcm" dircc-tory to the empty system directory inside root.- Bc ccrLain owncrship and pcrmissions o Lhc hlcs havc noL been modied after copying them from the build system.- In Lhc conhguraLion hlc (iniL.rc): - CommcnL ouL Lhc lincs, which rcmounL Lhc hlcsysLcm as read only. - I you nccd rooL privilcgcs in Lhc shcll, scL Lhc scrvicc console user to root. - Add your ncLwork's DNS scrvcr wiLh scLprop ncL.dnsl [DNS IP].BootYour Merged kernel should now be ready to run Android. Load the kernel on your board, set the appropriate boot arguments and Android should boot shortly.Te rst-time boot will take longer since Android is optimizing the .dex les (using dexopt), so be patient. Use the dex-preopt tool on .jar les before you install them to avoid this delay.Should any minor issues appear, experiment with the kernel options and the init.rc conguration, based on the informa-tion you get from Androids logcat and the systems dmesg tool.Logcat and dmesg are your Swiss-army knives. Use them to identify and investigate any possible issues.Post-BootYou should now have a working Android OS on your ARM-based SoC.Although Android is based on the Linux Kernel, it is not using the GNU/Linux lesystem. Terefore, it is not Linux. Expecting Android to work like or provide the same function-ality as traditional GNU/Linux systems is a mistake that most of us have made!For example, the C-library (Bionic) is dierent, and you will not get the standard dynamic linker. Terefore, if you want to run pre-built GNU/Linux binaries, they have to be statically linked.Te shell is a bit restrictive, with not as many tools usually available in GNU/Linux, but you could drop in a statically linked version of BusyBox that provides the ones you are missing.And dont forget that adb is your friend!SummaryPorting Android to new ARM-based SoC should be easy and straightforward, if you have a Linux kernel port for your SoC. From experience, merging a Reference kernel and the Android patches of the same revision requires about a day; however in the case of revision mismatch, more time may be required. Te Android lesystem part of the story may work without changes, and if Dalvik already supports the ARM architecture version that your platforms SoC is using (e.g., ARMv7-A), you will also see improvements in performance over a more generic build.For more technical information on the subject, please visit: http://blogs.arm.com/software-enablement/498-from-zero-to-boot-porting-android-to-your-arm-platform/Vassilis is an undercover physicist in the comput-ing industry. He got his MSc in advanced computer science in Manchester, UK, where he focused on high-performance computing, micro-kernel opera-tion and principles, and got addicted to embedded systems through the ARM architecture and the SpiNNaker project. He is very curious about almost every tech subject in the eld, old-timer in Linux and FreeBSD, and loves ++nding better ways to code that thing!20 Engineers Guide to Embedded Linux and Android 2012EECatalogSPECIAL FEATUREThe availability of multiple symmetric CPUs on system-on-chip (SoC) has increased the appetite of system architects to design with more cores for even greater processing. Its important to keep in mind however, not all software is ready for the main course. Just because you can run many processes and tasks on multicore hardware doesnt mean that it will be the most efficient at processing data.Remember that a multiple CPU design is not a new idea. A look into history reveals systems with multiple CPUs that share memory and have been in existence for at least 25 years. But many of these systems were loosely coupled and did not have cache. Modern SoCs have multiple symmetric CPUs that are tightly coupled and caching can actually make things worse.It comes down to the type of multicore elephant youre trying to serve up. For example, how much data will be shared in the processing necessary to run your system?A Typical ExampleLets take a look at one way to divide the shared data processing problem. Normally within a long-distance car-rier network, control and data planes are used to route phone conversations. A single control entity, the control plane,processes the thousands of calls responsible for routing and billing. The data plane is responsible for han-dling individual conversations that need to be processed in a minimum response time. In addition to handling individual phone conversations,the data plane must be processed with consistent minimal delays while the system processes thousands of simultaneous conversa-tions. The problem with this elephant,if you will,is that it has multiple data sets that are completely unrelated but they are all running on a single set of instructions.While the control plane needs to process many sets of data into a single or even multiple remote databases for billing purposes, it may also need to re-route as other network nodes become more or less saturated, or even unrespon-sive. An operating system such as Linux or Android can run on one set of cores responsible for the control of the How Do You Eat a Multicore Elephant?By Stephen Olsen, Mentor GraphicsFigure 1: There are a number of approaches to multicore processing.Just because you can run many processes and tasks on multicore hardware doesnt mean that it will be the most effcient at processing data.www.eecatalog.com/embeddedlinux 21EECatalogSPECIAL FEATUREnetwork node,while the remaining cores run on a series of real-time operating systems (RTOSes) to process the actual data through the network (Figure 1).How to Divvy Up the System ResourcesFor our carrier network example, lets say the system consists of a set of eight symmetric CPUs, 4GB of shared memory and four network connections.The control plane is issued two CPUs,2 GB of RAM and one network node. This allows the control plane to keep much of the control database structure in memory as it acts on it. Linux was chosen for the general-purpose oper-ating system because of its available set of middleware necessary for processing control database commands and the limited need for a user interface. We could have just as easily selected Android had there been a user interface requirement or third-party software integration require-ment.The data plane is then divided up into three sets of two CPUs and 512 megabytes of dedicated RAM each. An RTOS was selected for its deterministic behavior, low latency and a minimum of operating system overhead.The remaining 512 megabytes are available for inter-process communication (IPC) via shared memory between operating systems. The Multicore Communications API, or MCAPI,will be used for communicating between operating system domains.With the System Partitioned, How do We Know Its Right?While its easy to guess, we dont actually know if we made the right allocations until we see where the bottlenecks occur in the system.Debuggers and profilers are essential tools for multicore design. Whether all eight cores are being used together under a single operating system, or separate operating system domains are used on separate cores, message passing needs to be optimized. Understanding what parts of the system are overloaded and which ones are idle will tell us where to focus for optimizations. The assumption made in the previous example was that each data plane was best served by two cores, but that may result in either overkill or underkill. How many and how large are the messages between cores?Under Linux there is a tracing tool called LTTng (Linux Trace Toolkit next generation) which can be found at lttng.org. This gives visibility into the Linux side, including down into the IPC mechanism from the Linux operating system domain. For the RTOS, a similar method of tracing Figure 2: Multicore multi-OS debug scenario with two different connection methods.22 Engineers Guide to Embedded Linux and Android 2012EECatalogSPECIAL FEATUREmust be available to see whats going on in a running system. These solutions are intrusive and will take both processing and large buffers for trace data. Tracing can be turned off once the system is largely optimized. The real trick is to get all the traces synchronized and to visualize how data flows between operating system domains. This can be handled with a common timebase between all oper-ating system domains using a common viewer.MCAPI to the RescueHaving a standard IPC mechanism that can be shared between each node allows for the propagation of tasks in a system in order to balance the systems with minimal porting efforts. The Multicore Association (MCA) created a standard IPC mechanism called the Multicore Applica-tion Programming Interface, or MCAPI. With MCAPI, an application becomes portable across both the RTOS and the GPOS if they have similar APIs as well as similar threading mechanisms, like POSIX. Incidentally, Mentor Graphics has released open MCAPI, which is an open source implementation of the MCAPI specification, comprising a Linux library and kernel driver that enable applications to communicate across cores. The open MCAPI offering was designed to help optimize multicore and multi-OS applica-tions on a single chip.Between operating system domains we can trace how the MCAPI IPC mechanism is functioning to determine the frequency in which the OSesare interrupted by IPC traffic and how fast they are responding to the request. If one node is overloaded, it can pass some traffic to another node that is mostly idle, thereby balancing across the set of nodes and minimizing the total delay for all conversa-tions. But how quickly can the system balance itself? Can we optimize the point at which a voice conversation is migrated?One possibility isto allocate all six CPUs to a single RTOS domain. However, all the data sets could migrate between CPUs,causing cache coherency issues. This can cause undue delay in processing a message because the data can be in one CPU cache and then acted upon in a separate CPU. Limiting the number of CPUs that can act on a data set can improve performance. But you ll only know for sure once you put your system through a real-world condi-tion and monitor its behavior (Figure 2).In addition, the next generation product may have 16 or 32 CPUs and this method does not scale.Tools to ConsiderWith limited tools available, there are two areas that require special attention: disabling system interrupts and task priority. If there is a common API for disabling system interrupts, its easy to see where the code is doing this. Each instance can be inspected for what data structures are being protected by the disable interrupt command. A system object called a semaphore can be used to block multiple entities from accessing the resource at the same time. The operating system must maintain the semaphore structure across all threads that may be simultaneously active. If the operating system is multicore safe, it will take care of the semaphore being accessed with the use of a spinlock that guarantees that system resources like a semaphore are accessed only by one thread at a time. But this does cause a minimal delay on all semaphore accesses.The assumption that a higher priority thread would be active, thereby eliminating any contention in the system, will need to be inspected. If there are any structure refer-ences from different threads, then this contention needs to be eliminated by using a semaphore to guard access. This is a slow process, but tools that profile a running system may be helpful. There may be a race condition in the code that is not easily detected. Code inspection for threads that access the same structures is a necessary step to make sure your code is multicore safe.In ConclusionAnalysis tools that allow a system architect to see whats going on in the system are key to balancing the system load and optimizing the use of all the system resources. Utilizing the benefits of both a GPOS (Linux or Android) as well as an RTOS can be an advantage by breaking down the problem between control and data planes. Using mul-tiple operating system domains along with a standard IPC mechanism,such as MCAPI, is an advantage that allows threads to be migrated to other operating system domains minimizing any system bottlenecks.So how do you eat the multicore elephant? One byte at a time. Or with multicore, that would be many bytes at a time depending on how many CPUs you can dedicate to each operating system domain and how easily it is to break the elephant into several largely independent chunks. Bon Appetite!Stephen Olsen has over 20 years of embedded software experience with his past 14 years spent at Mentor Graphics. Stephen is currently technical marketing engineer for the Mentor Embedded Soft-ware Division. During his tenure at Mentor, he has co-chaired VSIAs Hardware dependent Software (HdS) design working group and authored several papers on system design and power management. Stephen has worked in consulting, system architecture, embedded software, and IP. He holds a BS in physics from Humboldt State University in California.www.eecatalog.com/embeddedlinux 23EECatalogSPECIAL FEATUREAt the annual Google I/O conference in May 2011, Google announced that they were adding a framework into the Android operating system for USB-based accessories. This accessory framework was added to the Android 2.3.4 (API level 10) and Android 3.1 (API level 12)operating-system releases. Google enabled several different options for accessory development. Accessory developers need to understand the options that are available, the design implications of each of these options and how these selec-tions will affect their target market in order to determine what is best for their application.USB Peripherals and HostsBefore discussing the features of the accessory framework, it is important to understand a few related concepts about USB. USB is logically a point-to-point communication system between an attached peripheral and the host con-troller. Peripherals can never talk to each other through USB; there is always exactly one host on the bus. Typically in a USB system the USB host is the more powerful machine (more memory, more CPU power and better connectivity, and it is going to typically be the focal point for the user), while the peripheral is often a simpler device with basic functionality on the bus as a service to the host.The host also has certain responsibilities on the bus. The first main responsibility is to supply power to attached peripherals. The second main responsibility is to manage the devices on the bus. Because of these differences, the USB host-enabled device and USB peripheral devices often have very different designs.Android Accessory as a USB PeripheralAs an accessory designer, the choice between these two USB options might seem clear, initially. An accessory to a smartphone/tablet makes the most sense as a USB peripheral. The phone or tablet is likely to be the central focus point for the user, and the accessory is likely going to be providing a service for the phone/tablet. Having the phone/tablet supply power to the accessory is also an attractive option. The option to use the Android phone or tablet as a USB host was enabled in the Android 3.1+ devices. However, this option is not available in other operating system versions.Android Accessory as a USB HostWhen Google released their accessory frameworkcalled the OpenAccessory frameworkthey recognized that many Android devices already in the marketplace were designed only for USB peripheral capability. These phones and tablets dont have the hardware required to operate as a USB host. In order to enable these products to attach to an accessory, Google had to create an accessory framework option based on the accessory being the USB host and the Android phone/tablet being the USB device. This OpenAc-cessory framework option is enabled in both the Android 2.3.4 and Android 3.1+ operating-system versions.Android Accessory for Standard USBAccessoriesThe third option that is available is native OS support. With the addition of USB host capabilities to the oper-ating system, support for some standard accessories was also added, such as mice, keyboards, thumb drives, etc. Utilizing Googles New Open Accessory Framework for Android Accessory DesignsBy David Flowers, principal applications engineer, Advanced Microcontroller Architecture Division, Microchip Technology Inc.Figure 1a Creating an Android accessory, where the accessory is a USB peripheral but isnt using a standard USB class.Figure 1b When creating an accessory that needs to support Android devices that dont already have USB host capability or are running an OS version that doesnt support the USB host mode, then the accessory must be the USB host and use the OpenAccessory framework to talk to the Android device.24 Engineers Guide to Embedded Linux and Android 2012EECatalogSPECIAL FEATUREFor USB peripheral manufacturers who make these types of standard accessories, they dont need to worry about creating new devices or software to work with Android phones/tablets. Their accessories will work on any oper-ating system that supports that specific standard class driver. All three of these support options are highlighted in Figures 1a, 1b and 1c. Which One Should I Choose?Selecting one of the three available options for creating an accessory requires a little information about the impli-cations involved with each. The first major question that needs to be answered is the target set of Android devices for the accessory. In order to create an accessory that is a USB device, it requires that the target Android phone/tablet have the built-in hardware capability of being a USB host. Even if the hardware is capable of running the USB host, unless the Android device is running Android 3.1+, it will not be able to use either of the USB host options. As of June 1, 2011, Android 3.1+ was installed on 0.3% of Android phones/tablets. While the percentage is low right now for Android 3.1, an accessory designer needs to weigh the options of cost/features against what the Android 3.1+ adoption rate will be when the accessory is released. As new Android devices are released to the market, most are including the latest versions of Android that are available at the time. Figure 2 breaks down the adoption rates for the various versions of the Android operating system.USB Host Must Provide Power The decision to select accessory mode, where the accessory is the USB host, isnt as clear cut as just looking at the version adoption-rate information. In a USB system, the USB host must provide power to an attached peripheral. Peripherals can request up to 500mA of current from the host. Most USB peripherals expect that a host can supply at least 100mA. While this might be a suitable require-ment for a refrigerator doing diagnostics or firmware updates, it might be too large a limitation for a device like a pulse oximeter, where the consumer is expecting the device to be mobile, small and have a long battery life. Having to provide a minimum of 100mA is a very large power requirement for many mobile applications. Figures 1a, 1b and 1c show how the power is provided in the three possible accessory configurations.Standard or Custom ApplicationIn addition to the power-supply requirements, a designer must also consider how the accessory is going to be used and whether a custom application is acceptable. Any designer using the accessory mode, with the accessory as the USB host, will likely need to create a custom pro-tocol for the application. Using the same two examples as before, the refrigerator and the pulse oximeter, it would be reasonable, or even expected, for the refrigerator to have a custom protocol,wherein the customer must use a vendor-specific application to talk to that device. The pulse oximeter, however, would likely want to use the built-in Personal Healthcare Device Class (PHDC) available in the USB protocol. Using this protocol allows the device to be used on any USB host machine, and allows the hardware to interface to a wide range of software. However, limiting this hardware to a vendor-specific application might be too constraining for consumers to accept.If an accessory really wants to target Android devices that dont have USB host functionality, either due to hardware limitations or because they havent received an OS update to 3.1+ or later, then the accessory must use a custom protocol, as seen in Figure 1b. For accessories that can be limited to use with USB-host-enabled Android devices, the choice between a standard USB class or a custom class is entirely up to the designer. Though the OS may not have native support for a device, a custom application should still be able to access the device. This also allows the Android phone/tablet to work on other USB hosts that may support that device natively.USB Physical ConnectorsWhile they may not be a major determining factor, the physical connectors might also play a role in deciding which mode is used. For an accessory that is acting as Figure 1c - An Android accessory using a standard USB device class.Figure 2: The Android version adoption percentages, as of June 1, 2011. The two versions that support the USB functionality are pulled out slightly from the chart.(Source:http://developer.android.com/resources/dashboard/platform-versions.html)www.eecatalog.com/embeddedlinux 25EECatalogSPECIAL FEATUREthe USB host, the USB specification indicates that that accessory should have a full-sized, A-style female con-nector, like the connector found on a computer. Figure 3 shows how an accessory supporting a USB-peripheral-only Android device would connect to that device.For accessories going down the route of being the USB peripheral, designers have the option of using the full-size-B, mini-B, or micro-B female connectors. The other side of the cable must also be considered, however. For accessories that are going to be running as a USB periph-eral, this means that the Android device will be the USB host. Most Android devices dont have a full-size-A female connector,in which to plug a USB cable. Many of the Android devices on the market today that enable USB host mode require an adapter of some sort in order to use this functionality. In an ideal situation, the Android device would have a micro-A/B female connector,and the user would be able to use a micro-A to micro-B USB On-The-Go (OTG) cable to connect the accessory to the Android device and then use a micro-B to full-size-A cable to connect the Android device to a USB host, such as a standard PC. Figure 4 shows how a USB OTG-capable Android device could connect to various targets.USB On-The Go (OTG) for Both Peripheral & HostIf the decision between USB host-mode accessory and USB peripheral accessory is not clear, or both are desiredUSB host in order to support devices without USB host capabilities,and USB peripheral for those that do, in order to use standard softwarethen there is another option available. Android accessories can be designed as a USB OTG device. The USB OTG specification allows an acces-sory to be either USB host or USB device, based on the cable that is plugged into it.Using USB OTG, an accessory can be a USB host for Android phones/tablets without host capability, and a USB peripheral for those Android phones/tablets with USB host functionality.There are some complications associated with using USB OTG. An accessory user will not be able to use the same cable that came with their Android device to connect to the accessory. That cable is likely going to have a full-size-A plug, which will not fit into the micro-A/B receptacle of the OTG accessory,so an additional micro-A cable would be required. Due to the various hardware connectors found on Android devices, this cabling issue might actually be difficult to resolve, since you can only use a micro-A to micro-B cable as a standard USB cable, but many Android devices have either mini-B receptacles or custom female connectors. To further complicate the issue, there are some tablets and phones on the market that have OTG Figure 3: An accessory that needs to support Android devices that have only USB-peripheral capability can use the OpenAccessory framework to interface to the device, similarly to how the device connects to a PC.Figure 4: An Android device that has both host- and peripheral-mode capability, through a standard micro-A/B USB OTG connector, can con-nect to both a host-mode target(either PCs or accessories) or to USB peripherals (such asstandard mouse and keyboard peripherals).Figure 5: An OTG-capable accessory would be able to connect to both types of Android devices.It would use the OpenAccessory interface for the Android devices that only support USB peripheral, and it would use standard USB peripheral drivers when connected to the USB host/OTG-capable Android devices.26 Engineers Guide to Embedded Linux and Android 2012EECatalogSPECIAL FEATUREcapability but are not using the micro-A/B receptacle. Instead, they use a micro-B receptacle with a custom, non-USB-compliant cable to enable the host-mode operation. Figure 5 shows how an OTG-capable accessory is able to interface to these types of Android devices; those with USB peripheral capability only, as well as those with USB host or OTG functionality.If the accessory mode is selected, with the accessory acting as the USB host, there is still one more decision that needs to be madewhich API set to use. When the accessory framework was added to Android 2.3.4, it was added as a Google API add-on library. The library module used in Android 2.3.4 (com.android.future.usb) is slightly different than the library used in Android 3.1 (android.hardware.usb).The interface between these two libraries is also slightly different, but the functionality is basically the same. The main consideration here is that the android.hardware.usb library is only available in Android 3.1+, whereas the com.android.future.usb library is available in both Android 2.3.4 and Android 3.1+ devices. It is also important to note that the com.android.future.usb library is not a required library in Android 2.3.4, so there might be devices that are running Android 2.3.4 but do not have support for these features. It is up to the device manufac-ture to determine whether they will include this feature in their OS build.Using Android Debugger Interface (IOIO)There is one final option that should be covered on the topic of Android accessories. There is a solution named IOIO that enables the development of Android-based accessories, through the Android ADB debugger interface. This solution provides a method for enabling accesso-ries for Android phones/tablets running Android 1.5 or greater, eliminating the issue of having to wait for the hardware manufacturers to push out Android 2.3.4 or Android 3.1+ to their devices before the accessory will work with them. There are also downsides to this solution. One such example was presented in the accessory develop-ment class at Google I/O 2011. While the ADB interface has not changed much in recent history, the presenters indicated that Google reserves the right to change this interface as it needs to on future devices,in order to enable development and debugger features for hardware and soft-ware developers. Additional information about comparing the accessory framework and the IOIO solution is available at the IOIO developers blog (http://ytai-mer.blogspot.com/2011/06/ioio-over-openaccessory-adk-available.html).For designers considering developing Android-based accessories, this article has covered some of the design considerations for determining which of the possible routes to take. Each application is different and these criteria may or may not change a designers mind, but knowing the options is the key to ending up with the best possible outcome.Developers looking for additional information about Android-based accessories can refer to http://developer.android.com/guide/topics/usb/index.html or www.micro-chip.com/android. Questions can also be sent to android [email protected] Flowers is a principal applications en-gineer with Microchips applications team, where he develops and supports larger software solutions involving Microchips products for An-droid accessories, USB and encryption. David joined Microchip in 2004, working as an ap-plication engineer on Microchips 8-bit PIC18 microcontroller products. Prior to that, David earned a bachelors degree in computer engineering and a masters degree in electrical engi-neering from the Georgia Institute of Technology. His masters degree focus was systems and controls and DSP, with a minor in computer science. While pursuing this degree, David in-terned with Motorolas Energy Systems Group.Figure 6: Microchips PIC24F Accessory Development Starter Kit for Android (Part Number DM240415) interfacing to a Nexus S phone, using the Open Accessory Framework.www.eecatalog.com/embeddedlinux 27EECatalogSPECIAL FEATUREMicro electro-mechanical systems (MEMS) sensors, that enable machines to hear, see, touch, feel and smell, are creating opportunities for new consumer products and services that profoundly affect the way we live. MEMS accelerometers, magnetometers and gyroscopes, for example, already enable smartphones to respond to our hand gestures, rotate displays when we tilt the hand-sets, tell us which way is north, pinpoint our longitudes and latitudes, count our steps and lead the way to our destinations. Such competence is the result of seamless integration among the sensor hardware, middleware and smartphone application software. Achieving such seamless integration requires that at least one of these three layershardware, middleware or softwarehas the computational intel-ligence to interpret data from our surroundings and feed it to the other two layers for a desired result. The million-dollar question is: In which of these layers should the intelligence reside?Unfortunately for smartphone manufacturers, there is currently no firm answer to that question. Taking a look at a mobile operating system (OS) such as Googles Android, the most popular smartphone platform, may tell us why. In the tradition of Linux on which it is based, Androids mobile operating system is the result of collaboration among approximately 80 hardware, software and telecom member vendors in an open-source handset alliance.Open Source Doesnt Mean Available When participating vendors develop a new application, they often are forced to add the computational intelli-gence to make it work because the technology they need is not available. Case in point: Android has no sensor fusion application solution for magnetometers or accel-erometers. Yes, there are placeholders in the Android sensor API for sensor fusion (quaternion, rotation matrix, linear acceleration, gravity), but it is up to sensor vendors such as Kionix to provide the actual algorithm solutions that populate the placeholders. Therefore, if system and application designers want to combine sensory data from disparate sources to make an application more accurate, more complete or more dependable, they need to add that capability themselves. As these efforts are multiplied over and overand Android is said to have more than 200,000 available apps alreadythe intended open-source effort ultimately becomes closed to all but a few companies that have the financial resources to create breakthrough tech-nologies on their own.The sheer complexity and quantity of information that sensors can create requires new and different ways to handle the raw data for it to be incorporated in a compu-tational platform and analternate way of managing and storing it. Crunching the Numbers: Sensors as Co-Processors in Next-Gen Smartphones?By Ed Brachocki, Kionix & Stephen Maine, Opta3 IIc28 Engineers Guide to Embedded Linux and Android 2012EECatalogSPECIAL FEATUREIt Wasnt Always SoPreviously, accelerometers simply would detect when a specific acceleration threshold was reached, such as when a laptop computer was dropped. The information flow to the host processor was practically zero. The yes indication, confirming that the laptop was dropped, was received by the system controller, which would then notify the hard drive to shut down and park the read-write head. The data-processing needs of the host were minimal and the sensors local hardware minimally processed its own data flow. Later, when accelerometers were employed to notify host applications about the orientation of handheld devices, there were computational requirements for multi-axis motion detection and acceleration forces, as well as tracking of past, current and present positioning. Now there was a need for more dialogue between the host oper-ating system and the sensor, plus communication to the application at the presentation layer.This is the point at which the complexities of sensors, the operating system and mobile applications became challenging and data-rate intensive, while also requiring the interchange of data between several appli-cations and severalmaybe disparatesensors. Many of todays smartphone computational platforms rely on available operating systems such as Android that do not necessarily accommo-date the high information-rate streams of sensors. Android Not Up to the TaskThe Android OS architecture consists of a Linux kernel, including specific hardware drivers, that allows the pro-cessor to operate. Sitting on the Linux OS are abstraction and adaptation layers that allow Java applets and pro-grams to run. The adaptation layer operates like a browser running real-time applications. Each app runs at the top layer totally independent and isolated from all other apps available or running. The architecture permits some apps to run concurrently.In this example, the resource demands on new and future sensors on the underlying host processor could become so significant that it would force all other running apps and processes to freeze (assuming the OS allowed it to hog the bandwidth requested). While the sensors are being ser-viced, all the other communications and resident running apps also require system resources and servicing. Using the resident host processor and operating systemto support sensor motion algorithms, for examplemay simply overload todays embedded-processing platforms. Some flavors of Android do not have a Direct X equivalent that allows applications to tunnel through to the base layers and manage the lower layers of the processing stack. Any sensor requesting high demands on processor band-width would not be accommodated. So until Android can build in the appropriate processing algorithms and allocate the necessary resources and device management, any new sensor that has relatively high bandwidth demands requires additional processing power that can only be delivered by additional hardware.Platform Upgrades UnlikelyWhile we are peering into the future, let us suppose that next-generation processors will have the ability to inte-grate many high-level functions that easily accommodate the requirements of the high data transactions of new sensors. This approach has significant appeal and few apparent down sides.Is this the answer? Maybe. But smartphone developers who have made significant investments in legacy pro-cessors will likely prefer to add sensors to an existing design, along with software and new apps, without rein-vesting in a new processing platform. They would use the existing infrastructure and have the sensors serviced by adding hardware and soft-ware, and deploy existing protocols and device handlers provided by the operating system.Insight into how the smartphone industry will solve this problem may be found in the recent history of personal computers. As the PC industry developed during the 1980s, hardware design was simplified to accommodate the intensive processing requirements of printers and modems. Ultimately, an embedded microcontroller or microprocessor was engaged to process data locally to lower the overhead of the host processor. Designers achieved system integration through a set of software drivers that communicated with the hardware abstraction layer of the operating system. Short Term: Smarter, More Powerful SensorsEngineers at Kionix believe that this traditional approach is inevitable as processing demands of sensor-information streams increase. In other words, it will be up to sensor Many of todays smartphone computational platforms rely on available operating systems such as Android that do not necessarily accommodate the high information-rate streams of sensors. www.eecatalog.com/embeddedlinux 29EECatalogSPECIAL FEATUREdevices to process the data and provide information to the middleware and the application software in a smartphone.To see how this might work, take the example of smart-phone location-based services. The outdoor typical solution is based on the global positioning system (GPS) using satellites that tell time and find your location on the earth as long as it can calculate the distance from an already-known location. Besides helping you find your way, GPS also provides such perks as geotagging your smartphone photos with the exact place and time of day they were taken. It is the smartphone sensors, however, that provide data to the GPS system so it can give you the local time and tell you where in the world you are.Since the GPS provides location information only where there is an unobstructed line of sight, it, of course, does not work within a building. Indoors, smartphones must be smart enough to switch to a local-range communications technology such as