- Imote2 .Builder Kit makes creating wireless sensor networks a snap
- kannuu Developer Network open for business
- DSM tool offers high developer productivity
- New Rhapsody version interesting for embedded software and systems
- Augmented reality
- iPhone Open Application Development
- BUGbase: A Small Change in Plans
- Toys for Techies: BUG
- Google Android: Initial Impressions and Criticism
- Android SDK: It's a Java API
April 25, 2008 | Comments: (0)
Imote2 .Builder Kit makes creating wireless sensor networks a snap
I spent several hours today exploring the Crossbow Imote2 .Builder Kit, a "complete development environment for high performance wireless sensor networking (WSN) applications leveraging the Microsoft .NET Framework," as the company describes it.
(I'd never say "leveraging" and "Microsoft" in the same sentence myself if I could avoid it, because of Microsoft's rather checkered legal history of "leveraging" its near-monopoly -- but oops, I did it again. Back to Crossbow.)
The Imote2 .Builder Kit sells for $990 in the U.S. in small quantities. It includes three Imote2 processor boards, two Imote2 sensor boards, two battery boards, batteries, a USB cable, and software on CD-ROM. Obviously, individual boards are cheaper, especially in quantity.
Why so many boards? The processor boards also have radios, and can talk to each other using the 802.15.4 protocol. The Imote2 has an XScale CPU @ [13–416] MHz and a DSP, 256kB SRAM, 32 MB of SDRAM and 32 MB of FLASH, and baker's dozen of I/O ports of various stripes in addition to the radio and antenna. It has two pairs of connectors for sensor boards, a set for a "basic sensor board" on one side and an "advanced sensor board" on the other side. The flash image includes the .NET Micro Framework.
The sensor boards that come with the kit are of the basic variety, but I guess that refers to the connector they use: they actually have a 3d Accelerometer, an advanced temp/humidity sensor, a light sensor and 4 channel A/D.
The Imote2 software is an add-on to Microsoft Visual Studio 2005 (yes, 2005, not 2008) and .NET Micro Framework 2.0 (yes, 2.0, not 2.5). A 90-day trial version of Visual Studio 2005 Professional is provided with the kit.
I found the programming model for the Imote2 easy to understand, as I was already fluent in C# and familiar with Visual Studio 2005 and the .NET Micro Framework. I think I could build wireless sensor network applications with this kit very quickly: in days to weeks, depending on the complexity of the application.
The processors seem plenty fast. Debugging is trivially easy. The only trouble I had with the kit was a minor but annoying deployment issue: sometimes a board would stop taking downloads, and code deployment from Visual Studio would fail. I was always able to recover from this by stopping all the software on the PC that talked to the board, disconnecting the board from the USB bus, reconnecting and resetting the board, and restarting the software.
According to the company, this is most likely a problem with the Microsoft USBSPOT driver. Once I had a board programmed, it would be fine.
The picture at the top of this article is the hardware configuration for the most advanced demo in the kit, a star network in which two battery-powered CPU/sensor stacks transmit accelerometer data, one CPU board receives the signals and sends them over the USB cable, and the PC plots the live output, as shown at left.
Overall, this is a very impressive kit. There's more information at the Crossbow site.
Posted by Martin Heller on April 25, 2008 12:10 PM
April 22, 2008 | Comments: (0)
kannuu Developer Network open for business
What's kannuu? Basically, it's a novel input method editor for selection, which can reduce the number of button clicks needed to pick an item from a large but finite list using nothing more than a four-way selector. It looks like it might be useful for picking items on cell phones, media players and set-top boxes, although I found it less than intuitive at first.
For a canned demo with explanations, try the "view demo" link at the bottom of this page.
For an interactive demo, try this. To understand how it works, go here.
I have to admit that I've found searching from my own cell phone, which doesn't have a QWERTY keyboard but does have a numeric keypad and decent word completion, to be a tedious process. Will picking with 5 keys instead of 12 improve things? The kannuu demos claim yes, but on first principles I wonder.
Nevertheless, the news to consider is that the kannuu Developer Network is open for business, allowing you to download SDKs, code samples, and documentation for free. The planned platform support is extensive.
Deployment will not be free, however, and kannuu won't say exactly what the license fees will be. "Product licensing will be based on the utilization and the scenario, on a case-by-case basis," Sean-Michael Daley, CEO, told this reporter. "On the other hand, we want people to adopt our technology, so we plan to be very aggressive about making it affordable to deploy."
Posted by Martin Heller on April 22, 2008 07:54 AM
April 17, 2008 | Comments: (0)
DSM tool offers high developer productivity
I should have known better than to write about a vendor demo, as I did on Monday for Telelogic Rhapsody. Now everybody wants to give me a demo. As the organ-grinder's song from The Threepenny Opera goes, "Oh, the line forms at the right, dears, now that Mackie's back in town."
This morning's demo was a Web meeting, since the vendor, MetaCase, is in Jyväskylä, Finland. My Plantronics DSP headset worked well, the voice quality was good, and the VoIP delay wasn't all that bad as long as I didn't interrupt Dr. Juha-Pekka Tolvanen, CEO of MetaCase.
Dr. Tolvanen's starting point is the proposition that Domain-Specific Modeling (DSM) offers something like a 7x productivity improvement over C++ and Java, even when those languages are enhanced by UML modeling like Telelogic's. He cited several customer quotes in support of that: Panasonic experienced a "5-fold productivity increase when compared to standard development methods"; Nokia reported module development decreasing from 2 weeks to 1 day, i.e. a 10x gain. Other customer quotes supported different perceived values: EADS cited the improved quality of generated code because of the design rules; DENSO claimed "MetaEdit+ has eliminated our need to outsource software development activities."
Dr. Tolvanen showed me a demo of a DSM for building Enterprise applications for Nokia smart phones running on Symbian (see figure at left). This particular application does conference registration. The underlying DSM knows about the capabilities and limitations of Symbian, and the code generator emits Python.
Where does the high productivity come in? Only one or two hard-core developers in the company work on the code generation; most developers (hundreds at Nokia, if I understood correctly) work on applications in a high-level design view like the diagram editor shown in the figure, or an alternative view like a matrix or table.
I've played around with Microsoft's DSL tools, and found them to require a lot of work -- weeks -- to build an effective model. I assumed that was the state of the art. Apparently not.
Here's the money quote, from Laurent Safa of Matsushita, speaking about MetaEdit+:
"I could define a domain-specific language in about six hours -- design, testing and one failed trial included."
MetaCase can be reached by email at info@metacase.com and on the Web at www.metacase.com.
Posted by Martin Heller on April 17, 2008 12:05 PM
April 14, 2008 | Comments: (0)
New Rhapsody version interesting for embedded software and systems
Last week I took advantage of the fact that Telelogic has a facility here in Andover to get an in-person preview demonstration of Rhapsody 7.2, the new version of their model-driven development product, which is being announced today. I should actually say "Telelogic, an IBM Company," given the recent acquisition: please take that as read. The signage at the facility still just said "Telelogic."
At the beginning of the demo, I sat there thinking "All this modeling junk gets in the way. Let me at the code." Then we got to the point of doing testing on animated UML diagrams synchronized with the compiled code that had been generated underneath, and I started to be impressed. When I realized that many common system-dependent constructs (a timer, a button, ...) had been abstracted and that the entire project could be switched to a different target operating system (there were over a dozen) with a menu pick, I was really impressed.
Some of what's new in version 7.2 extends the capabilities that Rhapsody already had for C++ to plain C. That makes sense for many embedded systems. Other new features are aimed at systems designers, and provide a SysML virtual prototyping facility.
Here's the full release:
Telelogic Announces Enhancements to Rhapsody Model Driven Development Solution including New Eclipse Plug-in
New capabilities facilitate mid-stream adoption of Model Driven Development, and help systems engineers validate technical, real-time or embedded systems designs earlier
MALMO, Sweden and Irvine, California Telelogic, An IBM Company (NYSE: IBM) today announced enhancements to its market leading Model Driven Development™ (MDD™) solution, Telelogic Rhapsody®. The new features decrease time-to-market through the support of MDD best practices that do not disrupt current project workflow, and provide system engineers a way to leverage advanced visualization and prototyping capabilities to easily validate design correctness and effectively communicate intended design behavior.
Today’s announcements include:
- The introduction of Rhapsody 7.2, a new version of the company’s flagship Model-Driven Development solution that provides breakthroughs in systems engineering, software asset re-use, and automated documentation and testing;
- The new Telelogic Rhapsody Eclipse Plug-in, a version of Rhapsody integrated within the Eclipse open source development environment, scheduled for release this summer; Rhapsody Eclipse Plug-in allows embedded device and real-time system software developers to continue working on existing projects at the code level while gradually adopting MDD within a single familiar development environment.
“Leveraging existing code from previous projects is a significant part of most embedded system development efforts and for teams implementing model driven development approaches the need to efficiently automate the transfer of design intent among system models and software code is of key importance,” said Matt Volckmann, Senior Analyst/Program Manager with Venture Development Corporation’s (VDC) Embedded Software practice. “By offering several new features within Rhapsody 7.2 that allow for more integrated methods of code design and model driven development, Telelogic continues its strong history of product innovation and clearly endeavors to maintain its leadership position within the embedded software and system modeling tools market,” said Volckmann. “VDC’s most recent analysis of the embedded standards-based software and system modeling tools ranked Telelogic as the market share leader on a revenue basis”.
New Features Increase Automation; Open MDD to C Developers and Integrated Eclipse Development
Building on Telelogic’s “Code Respect” initiative, Rhapsody now allows C developers to leverage the benefits of MDD while preserving the code structure, functionality and order. Rhapsody further offers the unique ability to reverse-engineer existing code and then forward-generate identical code. This allows software developers to use the right tools for the job and work at either the code or model level.
With Rhapsody’s Eclipse Plug-in, software developers can streamline their workflow and increase efficiencies by taking advantage of Eclipse’s powerful code editing capabilities and gain the benefits of working with an MDD solution all within the same development environment. Using Rhapsody’s strong reverse engineering and code synchronization capabilities, Rhapsody’s Eclipse Plug-in allows developers to work on the code or model within one complete development environment. Working in this manner, the code and model remain in synch and it is easy to navigate from one to the other. Developers can leverage debugging at the code or model level using the Eclipse debugger and Rhapsody’s animation with the ability to synchronize breakpoints between them.
IDT, a company that specializes in Automated Software Testing (www.idtus.com) recently conducted a one year Software Testing survey which concluded that among other statistics, some 50 - 75 percent of the software development lifecycle is spent on testing related efforts. With recent enhancements to Rhapsody TestConductor™, an integrated model-based testing solution, C developers can now detect and eliminate software defects earlier in the development cycle when they are less costly to fix. Rhapsody TestConductor facilitates unit and integration testing by automating many manual test procedures and decreasing the time needed for testing. It executes tests in single or batch mode, determines the success of the test, and creates a report, enabling developers to collaborate more easily and bring products to market more rapidly. Rhapsody TestConductor is based on the Unified Modeling Language™ (UML®) Testing Profile, enabling tests to be easily linked to design requirements captured in Rhapsody or in Requirements Management products such as market leading Telelogic DOORS®.
“Model Driven Development techniques help engineers become more efficient with the potentially time-consuming tasks of test creation and execution, as well as document creation,” said Greg Sikes, Executive Vice President, Modeling Solutions, Telelogic, An IBM Company. “With Rhapsody, engineers immediately gain a better understanding of their software and systems architecture and functionality, while operating in a more open and flexible environment with improved team communication.”
Systems Engineering Advancements
With the enhancements announced today, Rhapsody is the first Systems Modeling Language™ (SysML™) solution that will provide systems engineers with virtual prototyping capabilities using integrated graphical panels to rapidly visualize and validate a user mock-up early in the development cycle. Additionally, the graphical panels will allow engineers to easily modify, monitor and analyze data during simulation making it easier to ensure the design is correct. Rhapsody 7.2 also offers SysML Requirements Tables, Allocation Tables, and N-2 matrices, enabling large quantities of information to be easily organized, customized, and viewed. Improved model consistency and checking functionality further allows software developers to create their own and domain-specific checks, improving design quality and integrity.
Rhapsody 7.2 will be available in April, 2008. The Rhapsody Eclipse Plug-in and graphical panels will be available in Summer 2008.
For more information, visit http://www-306.ibm.com/software/rational/welcome/telelogic/
© 2008 Telelogic AB. Telelogic Rhapsody and Telelogic DOORS are registered trademarks of Telelogic. Rhapsody TestConductor is a trademark of Telelogic. Other trademarks are the properties of their respective holders.
###
Posted by Martin Heller on April 14, 2008 12:00 AM
April 01, 2008 | Comments: (0)
This weekend I read this book on augmented reality (AR):
Augmented Reality A Practical Guide
By Stephen Cawood, Dr. Mark Fiala
First Edition January 2008
Publisher: Pragmatic Bookshelf
Pages: 328
ISBN 10: 1-934356-03-4 | ISBN 13: 9781934356036
I learned a lot about the need for markers for synchronizing virtual reality with the real world. I learned how to set up some desktop AR demos using a computer, Fiala's ARTag system and a webcam. I learned the nitty-gritty of doing AR programming in C++ with Fiala's ARTag API, Intel's OpenCV computer vision library, and OpenGL graphics.
I didn't like the book much, however: it felt to me like an academic paper blown up to book length to no good purpose. I know that won't make the authors or editors happy, but that's my opinion.
What I really want to figure out is how to build a handheld AR system based on a cell phone or digital camera. What spurred me on was a slightly cheesy episode of Numb3rs called Primacy, in which AR is used to extend a MMPRPG into the real world.
I suppose that this would be possible to do with an iPhone using its SDK, although I'd worry about the iPhone's limited bandwidth outside of WiFi hotspots. It might also be possible to do with an Android phone, once one exists. It could probably be done with other existing smart phones and even ordinary phones using their C++, C# and Java SDKs. It would be fairly easy using the .NET Compact Framework. I think I could do it using the BREW SDK, which I've used before, or the Symbian SDK.
I'm not at all sure how much AR functionality I could shoehorn into the limited memory and CPU power of a garden variety cellphone, or how effective marker recognition would be with the limited resolution and slow response time of a standard cellphone camera.
I'd be happy to hear from anyone who has experience in this area.
Posted by Martin Heller on April 1, 2008 07:52 AM
February 01, 2008 | Comments: (0)
iPhone Open Application Development
This is yet another oxymoron of the day: Open iPhone. And yet, there's a whole book on the subject, or at least a Rough Cut.
You have to love a book that reads like the ethnic-joke recipe for Chicken Soup. You know the joke: "First, steal one chicken."
In the case of iPhone Open Application Development (O'Reilly, 2008), the joke is that the iPhone is locked, locked, locked. So Chapter 1 of the book is called Breaking into and Setting Up the iPhone. There are extended riffs on what to do when a new version of the OS or of iTunes locks the phone down again.
The authors of this book-in-progress claim that Apple would have to make impossibly huge changes to the iPhone OS to break the application model that they've pieced together by hacking the phone. I suppose they're right.
You know what? I'll wait for the SDK, should Apple ever deign to release it. My chicken-stealing skills aren't what they once were.
Posted by Martin Heller on February 1, 2008 11:36 AM
January 19, 2008 | Comments: (0)
BUGbase: A Small Change in Plans
The BUG system, which I discussed last Tuesday, will go on sale Monday at the BUG Labs store. It won't be exactly what was previously announced, however.
In an email, a company spokesman explained the change of plans:
This (the picture at the top left) is the BUGbase "Hiro P" model. It's what the first batch of BUGbase units will look like, and is much like the BUGbase we've been promoting, only with a minor aesthetic change to the front panel and no onboard 802.11 wi-fi.
Why no wi-fi? The issue extends from developing a set of open source wi-fi drivers, and we had to make a decision on our first production run - either ship early with no wi-fi, or delay the ship date until the driver issue was resolved.
However, to compensate the Hiro P customers, we will be offering them a BUGwifi module *at cost*, and we will also be giving them a *free* BUGvonhippel module. Additionally, we will be extending the early adopter program to the new batch of wireless-enabled BUGbases.
More about this can be read in the announcement we just issued on BUGblogger: http://www.bugblogger.com/2008/01/what-about-wifi.html
The wi-fi driver issue sounds similar to the one I encountered when I reviewed the Mandriva Flash 2008 in December. To get wi-fi working on that system, I had to download a small firmware file directly from Broadcom.
Posted by Martin Heller on January 19, 2008 08:11 AM
January 15, 2008 | Comments: (0)
From http://www.buglabs.net/products:
BUG is a collection of easy-to-use electronic modules that snap together to build any gadget you can imagine. Each BUGmodule represents a specific gadget function (ex: a camera, a keyboard, a video output, etc). You decide which functions to include and BUG takes care of the rest letting you try out different combinations quickly and easily. With BUG and the integrated programming environment/web community (BUGnet), anyone can build, program and share innovative devices and applications. We don't define the final products - you do.
The BUGbase (an ARM CPU and lots of interfaces) and four BUGmodules (GPS; Digital Camera/Videocam; Touch-sensitive, Color LCD Screen; and Accelerometer, Motion Sensor) will be available later this quarter. Four more BUGmodules are promised for Q2, but as one of them is a teleporter I would take that with grain of salt.
The software is Open Source and has a Java-based SDK:
BUG is built entirely with open source software. BMI, the BUG Module Interface, attaches devices to the BUG. Device-based services and applications are dynamically available based on which modules are connected to the BUG. Higher up the stack is Java, which hosts a service-oriented component runtime called OSGi. Java and OSGi make creating new BUG applications simple and intuitive, as BUG applications are essentially one or more bundles. In addition, each BUGmodule launches an OSGi bundle which in turn creates services for other components to consume. BUG applications are created using the BUG SDK (internally named Dragonfly), and are shared with other developers and users through BUGnet, our online community.
When I contacted BUG Labs about review units, they pointed me at "Dragonfly, the Eclipse-based BUG SDK, which includes a virtual BUG emulator."
The "getting started" guide is at http://bugcommunity.com/wiki.
Posted by Martin Heller on January 15, 2008 06:34 AM
November 13, 2007 | Comments: (0)
Google Android: Initial Impressions and Criticism
Over at Javalobby, Jilles van Gurp, a Java developer who works for Nokia, posted some detailed comments about Android based on his initial impressions of the SDK. Basically, he criticized Google for re-inventing too many wheels: the Java profile implemented in Android isn't compatible with any of the existing flavors of Java. On the other hand, he's happy that it's an open platform, and thinks that the planned use of the Apache 2.0 will offer some hope.
What do you think?
Posted by Martin Heller on November 13, 2007 03:01 PM
November 12, 2007 | Comments: (0)
I guess I shouldn't be surprised, since Google has been advertising heavily for Java developers with device experience: the much-hyped Google Android Open Handset SDK is basically a Java API. In addition, it supports XML-based layout files, and contains a variety of development tools.
What tools? An emulator, an Eclipse plug-in, a debug monitor, a debug bridge, an asset packaging tool, an interface description language, SQLite, a trace visualizer, a disk image generator, a bytecode translator, and an Ant script creator.
What does "Hello, World!" look like as Android code? Basically this:
public class HelloAndroid extends Activity {
/** Called when the activity is first created. */
@Override
public void onCreate(Bundle icicle) {
super.onCreate(icicle);
TextView tv = new TextView(this);
tv.setText("Hello, Android");
setContentView(tv);
}
}
There are four building blocks to an Android application:
- Activity
- Intent Receiver
- Service
- Content Provider
I'm oversimplifying, but an activity is a screen, and an intent moves from one activity to another. An intent receiver is an event handler. A service is long-lived non-UI code. A content provider is a class that implements a standard set of methods to let other applications store and retrieve the type of data that is handled by that content provider.
For more, read the Android documentation and download the SDK.
Posted by Martin Heller on November 12, 2007 11:33 AM
November 07, 2007 | Comments: (0)
- Update the rest of my Windows computers to the released version of Windows Live. (The upgrade went fine on this computer; I'm blogging with the released version of Windows Live Writer.)
- Look at the Infragistics Aikido CTP. This is a new Web User Interface Framework built using the Microsoft ASP.NET AJAX Framework and new controls, that makes the Web look a lot like the desktop, if the screen shots are to be believed.
- Compare the OpenSocial API with the Facebook API.
- Figure out whether there's a business model in OpenSocial and/or Facebook applications that makes sense for me or any of my clients.
- Try out the TI ez430-rf wireless embedded device SDK.
- Monday, November 12th: Look at the Android SDK release at http://www.openhandsetalliance.com/developers.html. How hard is it going to be to develop for the "Google Phone"?
- Early December: Build or buy a new desktop system for Visual Studio 2008 development.
Any suggestions from the peanut gallery?
Posted by Martin Heller on November 7, 2007 11:11 AM
October 26, 2007 | Comments: (0)
VIA Eden ULV 500 MHz: x86 compatible, 1 watt
I had a long talk on the phone last week with Johnny Wang, a Product Marketing Manager at VIA Technologies. (Yes, this was yet another delayed meeting that I was originally supposed to take at ESC.) The subject was mainly why VIA's line of low-power x86-architecture CPUs are interesting for embedded applications.
According to Wang, while RISC processors have owned the low-power embedded systems market for quite a while, VIA has developed x86-compatible processors that are competitive. We're talking about devices like set-top boxes, small kiosks, and thin clients; going beyond embedded systems, these are also good for silent desktops.
VIA has developed x86-compatible processors and chip sets and small form factor boards that have very low power consumption (e.g. 1 W peak TDP and 100mW idle for the 500 MHz Eden ULV). There are RISC processors with lower power consumption, but when you build them into systems and factor in the north bridge, south bridge, and memory, the Eden processor can be the basis of a lower-power device than you can build with today's RISC processors. VIA has combined the north and south bridge onto one chip; the Eden ULV line supports 1.8V DDR2 RAM, where most RISC processors need higher power DDR RAM.
From a software developer's point of view, there's a lot of benefit to developing for an x86-compatible processor, since you don't have to stretch much to find compilers and tools, and emulation basically becomes a non-issue. From a thermal packaging point of view, if you have a system that dissipates less than a few watts of heat, then you can get away with passive cooling and not worry about fans, which also gives you a quieter system. And of course from a "green" point of view it always makes sense to keep the power consumption and heat dissipation down.
There's more information at http://www.via.com.tw/en/products/processors/eden_ulv/.
Posted by Martin Heller on October 26, 2007 02:51 PM
October 18, 2007 | Comments: (0)
Department of Amplification: Ben Chelf on Boolean Satisfiability (SAT)
Coverity's PR counsel just forwarded me a message from Ben Chelf, clarifying his note posted Wednesday:
Thanks for posting Ben Chelf's comments so quickly.
Upon reading the posting, Ben realized that some of your readers may be confused by this statement:
Boolean Satisfiability is the same type of technology that Synopsys, Cadence, and other EDA tools providers leverage in verifying chip designs. This new technology, which is called SAT, allows the analysis, not only of all the paths through the code but also all of the potential values of the variables in any given path.
The technology actually isn't new, it's a new application of the technology Synopsys, Cadence, and other EDA tool providers have been using to find hardware defects. What is new is its application to software development.
Here's a statement that might clear this up:
Synopsys, Cadence, and other EDA tools providers leverage Boolean Satisfiability (SAT) in verifying chip designs through sophisticated SAT-solvers that can solve formulas on millions of variables. The application of SAT-solvers to software analysis allows the analysis to cover not only all the paths through the code but also all the potential values of the variables in any given path.
Thanks again!
Posted by Martin Heller on October 18, 2007 11:02 AM
October 17, 2007 | Comments: (0)
Ben Chelf on Reliability in Complex Software Systems
Last month when I was covering ESC I asked how we can guarantee the reliability of complex embedded software systems. Ben Chelf, CTO of Coverity just emailed me a response that I think you might find interesting:
Martin,
I noticed your recap on the ESC conference. I was in Boston presenting two topics, one at ESC on the application of next generation static analysis to embedded software and one at SD Best Practices on next generation software development tools. Quite a few of your comments resonated with me. You talk about the increasing complexity in automobiles in terms of number of control units. Another thing to think about is the software code that controls those units. In fact, there are more than 10 million lines of code on a premium automobile these days. The complexity of a system like that is mind-boggling, and certainly now it's impossible for any individual or even group of individuals to keep straight in their head all at once. That's why reliability is so hard right now and your question is dead on -- how do we guarantee reliability?
The good news is there is a reasonable model for the folks developing all this software. Conventional static and dynamic analysis have been attacking this problem with some success over the past few years, but the opportunity to innovate within this space is still there. For example, if we look to chip designers, we see there are tools for chip design that are based on rigorous verification and static analysis for detecting defects in the hardware designs. The price of failure in sending a bad design for physical fabrication is tremendous and therefore, the tools are necessarily very sophisticated. It's time for us to bring that sophisticated level of analysis into the software development world.
Static analysis for software is a concept that is not new. There have been companies that have provided static analysis solutions for a long time (most notably in a tool called Lint). But in the past, the biggest problem for all of these tools for software has been "false positives" -- where the tool reports something that just is not correct. Part of the reason for these false positives has to do with some fundamental limitations in the tools that followed Lint.
Eliminating false positives is no easy task because software systems are so much more complex than chips. Today, companies are using sophisticated new technology to perform Path Simulation statically through dataflow analysis to cover 100% of potential paths through the code, in addition to leveraging Boolean Satisfiability for analyzing code. Boolean Satisfiability is the same type of technology that Synopsys, Cadence, and other EDA tools providers leverage in verifying chip designs. This new technology, which is called SAT, allows the analysis, not only of all the paths through the code but also all of the potential values of the variables in any given path. This level of precision means the latest static analysis tools can find very sophisticated defects at a tremendously low false positive rate (under 15%). And they can do all this over millions of lines of code in a matter of hours so developers get to spend their time implementing new features instead of tracking down those nasty bugs.
To see how far we’ve come with this challenge, maybe I can add some historical context. A number of your readers are probably familiar with Stephen Johnson, the creator of Lint, here’s what he had to say about false positives and software defects:
“Lint tries to give information with a high degree of relevance. Messages of the form ‘xxx might be a bug’ are easy to generate, but are acceptable only in proportion to the fraction of real bugs they uncover. If this fraction of real bugs is too small, the messages lose their credibility and serve merely to clutter up the output, obscuring the more important messages.” Stephen Johnson, 7/26/1978.
So, as all your readers know, finding software defects is not a new problem – and clearly false positive results are not either. Of course, static analysis is not a silver bullet, and software development organizations still need to test their code and that will without a doubt uncover even more defects. But by leveraging static analysis the moment the code is written, thousands of developer hours will be saved by letting the computer start to do the debugging for them...
- Ben Chelf, Coverity CTO
Posted by Martin Heller on October 17, 2007 10:16 AM
October 11, 2007 | Comments: (0)
Entier DB Enables Advanced Search on Devices
One of the many vendor meetings I postponed from ESC and took later over the telephone was one with Collin Bruce of Hitachi Embedded Systems. His basic pitch is that the Entier embedded database can enable a new level of search capability on converged devices.
What's a converged device? The undistinguished cell phone sitting on my desk, for one: it's a phone, it's a camera, it's a video recorder, it's a sound recorder, it's a music player, it's a Web browser, it's a GPS, it's a rat poison, it's a toothpaste... OK, the last two were just to see if you were paying attention.
Now, the fact is that most current cell phones, smart phones, and connected PDAs don't do very well when it comes to searching. My cell phone organizes my music by genre, artist, album, and song, which is fine if I want to listen to Bohemian Rhapsody from A Night at the Opera by Queen, but not fine if all I can remember about what I want to hear is how it sounds and that it's one of the gorgeous arias I keep hearing in unexpected contexts.
(The aria I was hearing in my head is in fact Ombra mai fu from Xerxes by Handel, sometimes known as Handel's Largo, even though it isn't notated at largo; I have a fine performance on my phone's music player by the late, great mezzo-soprano Lorraine Hunt Lieberson, published on her album of Handel Arias. The other gorgeous aria I keep hearing in unexpected contexts, including commercials on TV, is O mio babbino caro from Gianni Schicchi by Puccini.)
My cell phone can find me a sushi restaurant in my zip code a number of ways, among which the most convenient (and least graphical) is probably to text "sushi 01810" to Google. It can't easily find me the name of the Italian restaurant that's a couple blocks off the highway on my way from here to Cambridge unless I remember the restaurant name, the street address, or at least the town it's in, and it certainly has no idea how to coordinate the route it gives me to a location to what else is on that route.
According to Bruce of Hitachi, Entier can do all that, and more. Entier started out as a project Hitachi did for Nissan to supply an embedded database for cars; it was released in the U.S. market just over a year ago. At this point, Entier can do a full-text search of a substantial database on a mobile handset in under a second, and has extensions to SQL that let it answer questions like "find me a song that sounds like late–era Beatles" or "find me a sushi restaurant within two blocks of the current GPS route".
What's new in the current release of Entier is a level-locking mechanism to support efficient database access from multiple processes; a database partitioning scheme; a binary update utility; and improved complex word search. These augment the existing spatial search, conceptual search, incremental text search, and alias search features of the database.
There's a moderately obnoxious but informative flash demo about Entier here.
Posted by Martin Heller on October 11, 2007 12:12 PM
October 02, 2007 | Comments: (0)
One of the many vendor briefings that I had to reschedule when I became ill during ESC was one with Lantronix. I finally had the briefing by telephone and WebEx the week after the show.
Back when I was building embedded systems twenty-odd years ago, and more recently when I worked on hotel management systems, I learned more than I ever wanted to know about serial communications and UART chips. That stood me in good stead when I talked to Lantronix, since what they typically do is interface with the UART chip on an embedded device and turn it into a Web 2.0 server so that you can easily connect and control your device over a network.
Their basic value proposition is that they provide the entire serial-to-LAN application royalty-free. Up until now, they did this at the module level, with external device servers, embedded device servers, and embedded device gateways.
What they announced at the show was a new product line, the DSTni XChip, which provides an "XPort on a chip." If you buy their chips, you get the entire networking stack, the serial-to-LAN application, the Web server, and the Web manager as a binary package that you can load into your flash memory. You also get production-ready Gerber and AVL files that you can merge with your own PCB design.
Additional information is here.
Posted by Martin Heller on October 2, 2007 08:48 AM
September 28, 2007 | Comments: (0)
Static Path Analysis and Embedded Systems
In my posting about embedded systems on the 19th, I asked how companies could guarantee the reliability of complicated embedded systems. One set of generic guidelines for this comes from Barry Boehm of USC: see, for example, the Software Reduction Top 10 List.
I know of three vendors addressing this in the embedded space: Coverity, Klocwork, and Parasoft. One technique that all three of these vendors use is static path analysis.
In response to my question about guaranteeing reliability, I got this email from Gwyn Fisher, CTO of Klocwork:
There are software assurance compliance standards that require mission critical systems (e.g. avionics) to provide validation that they've inspected every code path, normally through a combination of manual and automated techniques. This is about as close to a reliability guarantee that exists today, from a software assurance perspective. This is expensive but can be effective for small systems, however, for large, multi-million LOC embedded systems it becomes a more difficult problem to solve. It will always be hard to guarantee reliability for systems of this size and complexity but organizations are engaging in aggressive risk reduction strategies through the use of advanced code analysis techniques. These complement traditional testing techniques and code review methods and provide feasible and cost-effective means that allow an automated tool to at least investigate all code paths for a wide variety of potentially debilitating errors (including difficult to test areas of a system such as error handling routines). The tool makes decisions on which paths are feasible or not, hence worthy of further inspection, enabling the right balance between scalability and intelligent code and defect coverage. If a system can be made free of programming errors through this type of automation, then further along in the development process is subject to rigorous runtime testing, organizations can go a long way to dramatically reducing the risk of field failure and increasing the reliability of business and mission critical embedded systems.
Most developers spend the majority of their time on the true path. Most designers spend most of their time laying out what should happen on the true path. Peer code reviews focus on reviewing the main paths in a system. Most QA organizations spend most of their time testing that the true path does what it’s supposed to do. What about the rest of the system?
Static analysis brings the potential for agnostic coverage:
- Test the false path just as well as the true path
- Validate that the false path doesn’t lead to failure, even in the most “corner” of edge cases
- Ignore a developer’s / designer’s instinct to rigidly peer review only the most “core” of the available code paths – review all feasible paths at all timesThis should be a strong notion for embedded software, since field failure can be very expensive. With current testing techniques it's very difficult to test "edge cases", so static analysis enhances testing coverage for embedded software.
Posted by Martin Heller on September 28, 2007 07:54 AM
September 26, 2007 | Comments: (0)
When I first started paying attention to In-Circuit Emulators (ICEs), they were >$10K devices, and not a lot of organizations could justify having them. Over the years, they have evolved dramatically: last year, TI sold 50,000 eZ430-F2013 emulators at $20 each, which kind of changed things.
This year, TI introduced a complete wireless development kit for its MSP430-series low-power embedded microcontroller, the eZ430-RF2500, which will be available on October 1st for $49. The device itself breaks into two parts, one holding the computer interface and emulation logic, and the other the target board with the MSP430 and the wireless transceiver and antenna. In addition to the hardware, the kit includes an IDE, a C compiler, an assembler, and lots of examples.
Supposedly, you can also use the device as actual end equipment: it's not limited to run in the emulation environment. Obviously, you won't substitute a $20 target board for a $0.49 chip in a mass-market product, but for one-off applications that need wireless connectivity it makes a lot of sense.
This all sounds very exciting, and maybe a little too good to be true. I'll let you know what I find out when I get my hands on one.
Posted by Martin Heller on September 26, 2007 07:56 AM
September 19, 2007 | Comments: (0)
I spent the day in Boston yesterday at the the Embedded System Conference. I was supposed to go back today, but I'm a bit under the weather, so I'm staying in my office.
I worked on embedded systems years ago: those were the days when what you could expect for a processor in an embedded system was an 8051 or maybe a 6802. Back when I was an accelerator Physicist, the electrical engineers and I retrofitted an isotope-production cyclotron with 6802-based stepping motor controllers; the motors attached to the cyclotron's tuning dials, and the boards had serial interfaces to a PDP-11, which monitored the cyclotron and ran a program that attempted to keep the cyclotron tuned properly via the controller boards.
I knew then at the gut level that an embedded system did not imply a small system: those cyclotrons occupied 1000-square-foot concrete vaults, drew kilowatts of power, and put a concentrated beam of protons on a target. I also knew at a gut level that reliability can be critical in an embedded system, and that embedded systems often have hard real-time constraints.
The "embedded does not mean small" message came home to me again yesterday. So did the reliability message.
When you think of embedded systems, cell phone handsets may come to mind. From a software engineer's point of view, however, cars are embedded systems, and so are telephone PBX systems, and airplanes.
Cars are now becoming not only embedded systems but distributed systems. Ten years ago, they typically had two computers, referred to as control modules. Many weird problems were solved by swapping out or re-flashing the BCM, or Body Control Module.
These days, an automobile typically has many control units, all networked together over one or more busses. Automotive engineers use a bunch of standards -- they have as long as I can remember -- but now many of their standards seem to be related to their embedded computer software and the interfaces to the control units.
Think about telecom again: the software for a big telephone switch is massively parallel and can easily amount to 10's of millions of lines of code. If the switch handles, say, all the 911 traffic for the East Coast, perhaps its reliability matters just a teeny bit. How are you going to guarantee that reliability?
Posted by Martin Heller on September 19, 2007 07:35 AM
August 14, 2007 | Comments: (0)
Embedded Programming with the Microsoft .NET Micro Framework
In June and July, I discussed the .NET Micro Framework, the Tahoe Board, and the Tahoe SDK. Since then, the Tahoe SDK has been updated, and Microsoft Press has published Embedded Programming with the Microsoft .NET Micro Framework, by Donald Thompson and Rob S. Miles (288 pp., ISBN 9780735623651, $44.99).
If you downloaded the .NET Micro Framework and had trouble getting started, then Embedded Programming with the Microsoft .NET Micro Framework is exactly the book to get you going.
Don Thompson, a former professional Hollywood child actor, directed the Ubiquitous Computing team effort at Microsoft Research, later called the SPOT initiative, which led to the .NET Micro Framework. Rob Miles works in the Computer Science department of the University of Hull, in England. Together they lay out the .NET Micro Framework in an engaging way.
The book also contains some case studies by other people. One is by Steve Maillet, CTO of Embedded Fusion, and is all about the genesis of the Ball-in-Maze game and the Tahoe board. The other is by Rick Swaney, a developer in the Mobile PC group at Microsoft, and discusses Vista Sideshow gadgets.
Posted by Martin Heller on August 14, 2007 08:52 AM
July 12, 2007 | Comments: (0)
Embedded Fusion is in the process of making the accelerometer board I mentioned here available for purchase on their site. In the mean time, they can be purchased by contacting sales@embeddedfusion.com. There isn’t a specific name for it, so "accelerometer board for Tahoe" is what customers should request. They will be making the source to the Ball-in-Maze application available for free download with the upcoming SDK release next week.
Posted by Martin Heller on July 12, 2007 12:34 PM
June 28, 2007 | Comments: (0)
.NET Micro Framework: Tahoe Development Kit
Last week I told you about a conversation I had with Colin Miller, the manager of the Microsoft SPOT group, about the .NET Micro Framework. Since then, I have installed the .NET Micro Framework SDK, along with the EmbeddedFusion Tahoe Development Kit. That goes along with an EmbeddedFusion Tahoe board that Microsoft's PR firm sent me; they also sent an accelerometer daughter board, a "ball in maze" sample application, and a lab manual for the sample. The accelerometer and sample application are not part of the standard Tahoe kit.
The Tahoe board uses a Meridian CPU module, which combines a 32-bit Freescale i.MXS (ARM920T core) processor running at 100 MHz, RAM, FLASH, an LCD display, some buttons, and the Microsoft .NET Micro Framework. As you can see from the illustrations, the LCD display and the buttons are on top of the board, and the Meridian CPU module is on the bottom. The Meridian CPU supports many low power peripheral devices via the serial, i2 C, and SPI interfaces. It isn't obvious from the illustration, but for development the Tahoe board draws power from a miniUSB connection at the top left.
Compared to the 8-bit, 12 MHz, Intel 8051-based embedded controllers that I grew up on, the 32-bit, 100 MHz ARM 9 is a speed demon. By the time you factor in the overhead of the interpreted .NET Micro Framework runtime, however, the performance doesn't feel all that spectacular. Maybe I've been spoiled by 3,200 MHz desktop CPUs with multiple cores.
Anyway, I'm finding playing with the .NET Micro Framework SDK and the Tahoe SDK luxurious fun, in my geeky, retro way. I remember writing assembly code to flip I/O bits on wire-wrapped breadboards for embedded controllers 20-odd years ago, and here I am writing C# code to flip I/O bits on a packaged printed circuit breadboard. The more things change...
Posted by Martin Heller on June 28, 2007 02:33 PM
June 21, 2007 | Comments: (0)
.jpg)
Today I had a briefing from Colin Miller of Microsoft about the .NET Micro Framework, a very small footprint version of the .NET Framework targeted for the embedded development space. The official description goes like this:
The Microsoft .NET Micro Framework is an environment that extends the advantages of Microsoft .NET and the toolset in the Microsoft Visual Studio development system into a class of smaller, less expensive, and more resource-constrained devices than previously possible with other Microsoft embedded offerings.
According to Miller, the Micro Framework is not as compatible with the desktop as the .NET Compact Framework, because compatibility wasn't the primary goal. For example, they didn't implement the Forms namespace, because the Forms footprint is too big: interestingly enough, they used part of the Windows Presentation Framework object model instead.
The Micro Framework does support most of the .NET System namespace, but none of the Data namespace. Basically, they built the .NET Micro Framework up from scratch based on the needs of the embedded devices they and partners key customers were building.
Note that the .NET Micro Framework is not suitable for hard real-time. While they have a JIT compiler on the shelf, it requires too much of a memory footprint, so the Micro Framework runtime is still interpreted. It's also not as feature-rich as Windows CE or Windows XP Embedded.
According to Miller, embedded development hasn't changed much since 1970s, despite all the changes in desktop programming. There are fewer 8-bit devices being used: in the 1970s and early 1980s, when I did most of my embedded system development, a lot of embedded systems were built around 6502s and Z80s. There are still many 16-bit processors in use, but newer 32-bit processors are coming down in power and becoming appropriate for embedded systems, for example the ARM Cortex.
When Miller's group started talking about embedded programming with some version of the .NET Framework, they got a great response from embedded developers, and not the die-hard push-back you might have expected. They started cherry-picking things from desktop, and they are still doing it: one of the future releases will include web services for devices.
Colin had a lot more to say to me, but perhaps it would be better if you heard it directly from him. This video shows Colin, Mike Hall, Craig Mundie and others talking about the .NET Micro Framework, its applications, and the reasons for it. Basically, if you know how to write C# for the desktop, you should be able to write for embedded devices with the .NET Micro Framework.
Download the .NET Micro Framework SDK from here if you already have Visual Studio 2005. A white paper is here, and the official book site is here.
Posted by Martin Heller on June 21, 2007 02:12 PM
TOP STORIES
ADDITIONAL RESOURCES
- Remote Access: Maintain Security and Decrease the Burden on IT
- Beyond AntiVirus: Symantec Endpoint Protection
- What Every Enterprise Needs to Know About VDI
- Monitor the core and troubleshoot the access layer
- Disaster Recovery in Minutes
- Protecting Microsoft(R) Applications
