To Reuse Firmware or Not to Reuse

Sometimes on new embedded development projects I am presented the option of repurposing firmware that has already been developed for the intended platform.

At first glance, repurposing seems a no-brainer because of its potential for saving time and effort, but a closer look at the risks involved paints a different picture.

Risks of repurposing firmware include unknown bugs, uncorrected known bugs, poor programming practices, and "fragile" software that becomes unstable after change. And sometimes even though the software is well-written it just doesn't achieve its intended purpose.

Here are some criteria I find helpful when evaluating if I can reuse a firmware code base:

• Documentation: Does it exist and is it current? (Specifically, I ask for design documentation and test procedures.)


• Understandability: Simply read through the source code. Does the style and format conform to your standards?


• Testability: Has the code been unit tested? Can you duplicate the results?


• Availability of original developer: Can you contact the programmer(s) should you run into problems?


• Version and source control: Is the software under active management and control?

Unfortunately I have not found a failproof system to make this decision. However if more than half of the above points are answered in the negative I choose to start from scratch.

 

Designing a Robust Communication Protocol

In today's world of designing distributed embedded systems, it is imperative to design, document and test the communication protocol early on.

I recommend building upon the layers of protocol provided by the underlying architecture you have chosen, for example, TCP/IP, Bluetooth, USB, etc. If the underlying communication layer provides data integrity and delivery then it should not be duplicated in the application portion of the communication protocol. At a minimum, you are looking to have a low-level handshake between subsystems with assured delivery. Consider the following questions:

• Does the packet need to be routed?


• Does the sender need to know that the recipient received the communication packet?


• Is the data intact?

Now you can move to the business logic portion of the packet--the data payload definition--and begin to address these questions:

• Is there a command/response requirement?


• What is the general packet definition?


• Are there different types of packets?


• Is the packet size variable- or fixed-length?


• What are the physical units of the data transmitted?


• Was the packet understood by the receiving subsystem?

In addition to these questions, it's imperative that you list all of the possible error conditions. Ask yourself how you will be able to make them happen so you can test for robustness, which sometimes requires writing test applications to intentionally insert error conditions. Sometimes an external communication test device is the best choice.

There are many factors to consider, and this brief writeup is simply a starting point. What issues do you think are most important in building a robust communication mechanism?

-Gary

Curiosity Rover -- A Technology Powerhouse

I would be remiss if I failed to mention the biggest technology achievement of this year, the perfect landing and immediate operation of NASA's Mars rover Curiosity. In this stunning achievement of application of modern technologies, I want to point out this fine example of an embedded system.

Spaceflight Now has an excellent article on how the computer system was selected and built to work in the harsh Martian environment. Engineers at BAE Systems chose redundant and radiation-hardened PowerPC electronics to survive the thin Martian atmosphere. With 20% the CPU power of a modern smartphone, this device needs to be able to autonomously roam the surface for extended periods and be capable of sophisticated scientific experimentation.

It is interesting to note that there was not enough memory to store the landing software and the navigation software in the computer's memory. For the trip from Earth to Mars it had one mission, a perfect landing. Once the rover successfully landed and performed basic diagnostics the program memory was wiped and is currently being updated with navigation-oriented software. The new software needs to work flawlessly for a 2-year mission. There will undoubtedly be more updates but not a complete change of function.

For those interested in following its journey, visit NASA's official Curiosity website.

-Gary

Are Your Error Messages Understandable?

Even though we like to picture ourselves as flawless developers, it’s important to address how our systems will behave when users encounter an error.

I usually break the possible system responses into 3 categories:

1. Bad: The system throws the user out, and potentially deletes the user’s unsaved work.

2. Slightly Better: The system doesn’t throw the user out or lose their work, but brings up a cryptic message in programmer-ese that just confuses the user.

3. Best: The system brings up an error message that’s understandable and informative, and also provides advice on how to avoid or fix the error.

If you hadn’t already guessed, I recommend the third option. However, this is also the most difficult to properly configure, because each system error must be linked to a plain-English explanation.

Emily Wilksa, a former technical writer for Microsoft, has written a helpful article on writing effective error messages. Click here to read it: http://www.writersua.com/articles/message/index.html

-Judi

 

Embrace Change

I’m amazed how many developers and companies are reluctant to adopt modern technologies in their projects, especially when it could cut significant costs from the development process.

I even recently met a team who is still designing serial communication ports for their external interface. Ouch.

Thus, I'll focus my next few emails on development technology areas that have significantly benefited from recent innovations:
• Display technologies: highly integrated graphic chips and capacitive screens
• Wireless communications: near field communication, Bluetooth, WiFi
• Location-based systems: low-cost integrated GPS chips

-Gary

Is Android Viable for Medical Devices?

I recently attended the RTECC Boston Conference and was not disappointed.

Of particular interest was the keynote address by Alan Cohen of LogicPD about the viability of using the Android operating system for medical devices.

I approached the conference with 3 key questions, which I've since answered below.

1. Why Android?

Android is a complete framework built on embedded Linux with a fully implemented GUI right out of the box. It can begin developing an application very quickly, is a terrific development environment to rapidly develop a proof of concept, and is highly customizable.

2. Is the Android operating system suitable for medical electronics?

Android is only suitable as an adjunct to time-critical or life-critical processing. It is not a Real-Time Kernel (RTOS) and therefore not suitable for hard real-time applications.

3. Will Android be relegated to display-only functionality?

Mostly, but relegated is too strong a word. It is ideal for user-interactive applications since, according to Alan Cohen, there is a convergence in the medical device world and the consumer world.

Some key Android points:

• Built on Linux

• Built-in power management module is non-trivial since it is geared to phone/data devices

• Application licensing can be tricky (the kernel is GPL license). Even though Android is free, some Android Device manufacturers nonetheless pay royalty fees to Microsoft?

• Android allows very easy creation of embedded Linux applications with GUIs

 

-Gary

User Interfaces for Embedded Systems

I've always been interested in the user's interaction with embedded systems.

My primary embedded design goal is to make the man-machine interaction simple and intuitive. And today, more than ever, technologies are available that enable the creation of rich yet user-friendly experiences.

I recorded this video to introduce some topics I keep in mind when embarking on a new embedded design:

• Important factors to consider

• Technology alternatives

• User involvement

Let me know what you think. Thanks.

-Gary