标签: embedded system

In some aspects, cell phones and computing devices are to embedded systems what suburban utility vehicles (SUVs) are to trucks and other dedicated, specialized vehicles. SUVs were originally built with truck components, in truck factories and according to truck design rules, presenting enormous opportunities for automotive engineers and companies in a new market. And as the SUV market has evolved and matured, features added to satisfy particular needs in that market have inspired auto companies and engineers to turn around and incorporate those features into trucks and other dedicated vehicles. The same dynamic is at work between the embedded and mobile device markets, especially as it relates to the open source Android platform. Mobile devices originally drew on development tools, operating systems, building blocks and embedded programming expertise used in similarly resource constrained embedded designs. Now those have been complemented or superseded by mobile-optimised methods which developers are now looking at to enhance their embedded designs. Some online resources for Android developers include the Google+ Android Community and Android Developers; the LinkedIn Android Developer Group and Google Android ; and the Facebook Android Developers group. Two helpful Web communities are: Android Open Source Project and AOpenSource.com .  

Bruce Powel Douglass, a well-known UML guru, has published a book titled "Design Patterns for Embedded Systems in C." The title itself hits all of the right notes. Patterns are a hot topic in CS today, but so far have been largely neglected in the embedded space. And the patterns that are published are more likely to be C++, while C still dominates the firmware. Patterns do lend themselves to an OO approach, and some works spend time showing how to adapt C code to the C++ world. In a nice reversal Bruce shows how to use OO ideas with C. His ideas and examples are clear and innovative with useful example code. That chapter alone is thought-provoking enough to justify the book. Another chapter discusses Harmony, his agile approach. Harmony resembles Scrum, but, to me, offers an appealing level of discipline and detail. There are a number of steps one must follow, even in architecture and design. Sometimes I find those are shortchanged with other agile methods, or, at the least, there's little direction given on how to approach these tasks. Harmony has very specific guidelines. Patterns are given for a number of important embedded tasks, like the creation of state machines and working with multitasking. There were two I found particularly appealing. The first is the observer pattern. This is another name for publish/subscribe, an approach that is increasingly found in complex systems. When many activities need information it's often inefficient to have them stuck in waiting loops. Instead, the consumers of the info (the "subscribers") tell the "publisher" to let them know when the data is available. The subscribe to the publishers channel, in effect. When the information is available the publisher notifies all of the subscribers. This decouples the system tremendously. The second pattern that I particularly liked is really a collection called the channel patterns. One of the most vexing problems in firmware is how to respond to errors. Sure, malloc() may let the caller know that there's no memory available... but what then? The channel patterns are designed to allow processing to continue, perhaps in a degraded mode, when things go awry. It's quite complex but very thought-provoking. UML diagrams are used throughout, and an appendix provides all of the background even a UML neophyte needs to understand the book. Read that first. This is not a recipe book, as some of the other works on patterns are. Each pattern is coupled to an example that is useful in furthering your understanding but that won't make it into your code. View the patterns as the general design that you'll adapt to your project. Unlike Betty Crocker's works much of the code will make little sense unless you read the first couple of chapters for background. But those chapters are worthwhile even taken alone. I think many readers won't like the book. It pushes one away from the comfort zone of implementing just barely enough to sort of make a system work. Some will complain about the code being overly complex. For instance, the CRC pattern is about 11 pages of code. But that's because it is generalized ( a hallmark of code slated for reuse ) and a lot of the listing is an example use of the pattern. So far patterns have found little traction in the embedded world as few are available in C, and there just aren't that many that address the unique needs of firmware. Bruce's book addresses both of those problems. I found it refreshing and very thought-provoking.  

In this time of increased cost-cutting and bean-counting, documentation is usually the last thing that companies think about, despite the fact that is a critical element in any complex software or hardware design. The pervasive nature of embedded systems designs in our lives means much greater attention must be paid to rigorous and—at least short-term—expensive methodologies such as Agile systems development, which very much depend on an Agile-friendly documentation development process. In a recent article, James Grenning, one of the founding members of the Agile Alliance , pointed out that while in agile development working software is a more meaningful gauge of software development progress, that does not mean that there is no need for documentation. "Documents are often invaluable," he writes. "Those that are, must be produced. However, documentation is expensive to create and maintain so it is important to create only those documents you truly need." During the development process documentation provides individual engineers a reminder of what's been done and what is left to be accomplished. For a design team it provides a global view of the state of the system at any particular time and allows each member to see the place their particular piece plays within the whole of the design. At the later stages during testing, it provides the means to compare the operation of the completed system to the original design goals. For the end users, it is a guide to operating the system correctly and most efficiently. But despite the need for documentation in any development process focused on high quality and reliability, there are serious issues facing embedded developers as noted in several recent columns, including: " Incorrect documentation or none at all? " by Bill Schweber, and " Embedded design getting dumbed down ," by Jack Gannsle. In an article, "DITA and the death of technical documentation as we know it," Andrew J. Thomas suggests that the shift to a new documentation paradigm developed by IBM—called the Darwin Information Typing Architecture (DITA)—may resolve many of the problems faced by embedded developers. Because of the importance of documentation in almost any hardware or software design, I would like to hear from you about the techniques and tools you have developed to assure complete and accurate documentation at all stages of development.What do you think about such things as DITA, as a solution to the problem? What alternatives are you considering?  

Ron Wilson, a columnist for ESD Magazine, reports in the July/August issue of the magazine that there's a feeling that virtually all embedded applications will go to Android or Linux. He quotes one well-known wag "We are coming to the point where only a handful of mission-critical applications will use an RTOS and code developed in C/C++. Everything else is going to the Linux/Android market." Later Ron says that chip companies are providing complete Linux/Android ports, so "embedded design" is more about writing a bunch of Java code to run on top of these operating systems. Hogwash. I'm increasingly talking to semiconductor people who have teams writing vast amounts of code for their customers. The semi folks tell me their customers are demanding more than just silicon; they want complete solutions. The customers, though, tell me the problem is the chips are so complex, and so poorly documented, that it's impossible to generate a lot of the low-level application. When an 8 bit six pin PIC10 part requires a 200+ page datasheet, when an OMAP's datasheet is incomplete even at 4000 pages, it's clear that these parts have reach a staggering level of complexity. So many vendors have teams that supply complete Android/Linux ports. The idea is to get the customers up to speed quickly. But the semiconductor people who are furiously writing so much customer code are mostly in the very high-end space. We're talking cell phones and products where chip sales are so huge the vendors' natural response to any request is "you betcha." While many vendors of smaller CPUs do provide software IP, the range of applications is so vast that they can do little more than create some drivers and the like. Consider an oscilloscope: yep, there's a fabulous GUI, probably networking, maybe even a file system. A natural Linux/Android/Windows app, right? Well, yes, and indeed a lot do use these. But under the hood that instrument has an enormous amount of code devoted to sampling analogue inputs, triggering, measurements and more, much of which has to run at insane speeds. Sure, some big-honking OS is there, but the soul of the application is in the data acquisition and the "scopy" features. The embedded part, the non-Linux code, is what makes the application an oscilloscope, and what differentiates it from a mobile phone or other product that uses Linux. Billions of microcontrollers are shipped every year. Dozens of companies sell nothing but microcontrollers, be they little 8 bitters or 32bit Cortex-M series. There are literally thousands of different part numbers available. None of these will ever run Android or Linux due to memory limitations and the like. Are those markets going to disappear? Of course not. In 2004 Jerry Fiddler of Wind River read the embedded market's obituary at the ESC. We're hearing it again now. Yet Microchip, whose parts don't run Android or Linux, has more than doubled processor shipments since then despite the worst recession in nearly a century. ARM licensees have created an entirely new market in small microcontrollers since then. The range of applications enabled by embedded systems is so huge and the technologies employed are so diverse that blanket statements like "all apps will migrate to Linux/Android" are wrong. The only generalisation about embedded systems that's accurate is that one cannot generalise about embedded systems.