Ubiquitous computing may not have arrived yet, but ubiquitous computers certainly have. The sustained improvements wrought by the fulfillment of Moore’s law have led to the use of microprocessors in a vast array of consumer products. A typical car contains 50 to 100 processors. Your microwave has one or maybe more. They’re in your TV, your phone, your refrigerator, your kids’ toys, and in some cases, your toothbrush.
One of the greatest challenges of designing a computer system is in making sure the system itself is “invisible” to the user. The system should simply be a conduit to the desired result. There are many examples of such purpose-built systems, ranging from modern automobiles to mobile phones.
Few technology sectors evolve as fast as the wireless industry. As the market and devices mature, the need (and potential) for mobile applications grows. More and more mobile devices are delivered with the Java platform installed, enabling a large base of Java programmers to try their hand at embedded programming. Unfortunately, not all Java mobile devices are created equal, presenting many challenges to the new J2ME (Java 2 Platform, Micro Edition) programmer. Using a sample game application, this article illustrates some of the challenges associated with J2ME and Bluetooth programming.
When thinking about purpose-built systems, it’s easy to focus on the high-visibility consumer products—the iPods, the TiVos. Lying in the shadows of the corporate data center, however, are a number of less-glamorous devices built primarily to do one specific thing—and do it well and reliably.
We work in an industry that prides itself on “changing the world,” one that chants a constant mantra of innovation and where new products could aptly be described as “this year’s breakthrough of the century.” While there are some genuine revolutions in the technology industry, including cellphones, GPS (global positioning system), quantum computing, encryption, and global access to content, the vast majority of new product introductions are evolutionary, not revolutionary. Real technical breakthroughs are few and far between. Most new products are just a recycling of an earlier idea.
Dear KV, I'm on a small team that is building a custom, embedded, consumer device that is due out by Christmas. Of course the schedule is tight and there are make-or-break dates that if we miss basically mean the product will never make it to market. Not the most fun environment in which to have problems. The software was carefully specified and laid out and then simulated while the hardware was being manufactured. Now we have real hardware, and real problems as well. Aside from the timing issues we found when we were no longer running the software in a simulator, several bugs remain that show up only under very special circumstances and that disappear when I use the debugger or turn on the logging code built into the system. When tools fail you like this, what do you do next?