fbpx
Software Programming Tips Blog

Get To Market Faster With These Software Programming Tips

Software design for medical devices naturally invokes a paradox. On one hand, you want to have the software completed early. Prototypes can’t be tested until the software is in place. On the other hand, you can’t fully develop and test the software without the hardware on board — which means software integration realistically happens toward the end of development. To add to the challenge, system integration issues need to be mitigated quickly. Software solutions are typically preferred due to the relatively faster turnaround time and the flexibility offered.

The end of the process, meanwhile, is usually crunch time. With the pressure on, programmers have to be ready to rapidly develop software that’s efficient and bug-free. So, how can you reduce the time and overhead spent on programming, making it possible to get a prototype running — and testable — quicker?

Start by creating a reusable software framework that you can use for the majority of your projects. Sure, every project has a unique set of demands and requires its own design elements, but with a basic structure in place you can spend more time customizing the final software package for your client. The ideal framework has enough structure for rapid integration, but at the same time is flexible enough to handle features unique to the project. The right approach can help you get to testing sooner.

Taken together, the strategies below outline a plan for building such a framework in-house.  Developing software is like building with bricks. You don’t want to have to make new bricks for each project; you want to be able to use existing bricks to create something unique. Likewise, a programmer’s time is better spent on the details than on the basics.

Now for the specifics:

Choose a Versatile Family of Microcontrollers (and Programmable Devices)

If you can, start your project with a family of processors you know. That allows you to avoid learning a new system — which will reduce your overhead. We have deep experience and familiarity with the Cortex, ARM9/11, and Spartan-6 FPGA processor families, each of which offers a wide variety of peripherals (and modules in the case of programmable devices) that can be combined for a particular project. These families have the same core architecture and the benefit of using the same interface. Once you have experience with just a couple of processors, you can move around within the family without spending time on a steep learning curve.

Keep in mind that at the same time, programmers need to be flexible. Sometimes our clients already have a preference for some microcontroller family — perhaps because they have a relationship with a specific vendor or because they have internal experience with a particular family. That’s not uncommon, so our programming team has gained an extensive knowledge of many other families, too.

Stick With a Unified Set of Tools

The programmer’s toolbox includes, among many other items, compilers, static analysis tools, integrated development environments, and programming style guides. Since we need these for almost every project, it’s important to stick with those that work across many different processor families (see the bullet point above). That way, you don’t have to change your tool set — a.k.a. spending valuable time getting up to speed — for every project.

Our goal is to maintain tool consistency among our programmers as a way to ensure that we have a standard for quality assurance. Of course, just as in the case for processor families, it’s critically important to make sure we share expectations with our client, and vice versa. If our client’s device requires specific microcontrollers that our tools don’t support, then we find and adapt to a new set of tools that will do the job.

Create a Library of Reusable Software Modules

Each device design is unique, but there are commonalities. Medical devices, for example, often need pumps and motors. They rely on touch screens, external connectivity, and analog sensors. Programmers work frequently with these components, so they have to be very familiar with the underlying communication methods, and with tweaking drivers to fit the project.

To save time and overhead, we maintain a library of reusable software modules. I think of modules as critical building blocks that can form a strong foundation for any new project. When you need a driver, you can tweak the existing module without starting from scratch. Over the years, we’ve standardized the common drivers for the microprocessor and programming device families discussed above.

We recently took on a large project involving multiple subsystems. It included heaters, pumps, and motors, and we used modules from our library to build the drivers. Because those modules were already prepped, we produced a first version of the software within a matter of weeks. If we’d had to start from scratch, the project would have taken us months.

The library is indispensable, but it comes with a caveat. Just because you have a driver in your library doesn’t mean it’s going to be appropriate in every case. When you add a driver to the library, be careful to articulate the assumptions that went into its design. That way, on a future project, you can quickly assess whether it’s going to give you the functionality you need.

Develop a Versatile Communication Interface

Programmers need to know the underlying language used in the physical interface, whether it’s a USB port, Ethernet, or something else. We have to know how the system sends commands, how the recipient responds, and how errors are communicated. Choose a flexible, standard communication specification so that you have a basic structure in place. Of course, every project will have a different set of commands and will require some fine-tuning, but it’s smart to have a spec that you can fall back on for a rapid integration effort. To go one step further, a standard communication specification allows the creation of a reusable diagnostic utility that can reduce the amount of time you spend on debugging.

With this strategy in place, it’s possible to be ready for almost any project. We often work very closely with our clients to develop software, and we’ve found that the process goes much smoother and faster when everyone involved knows what we’re doing and why. As programmers, we want to spend time working on parts of the software that bring value unique to the project — rather than having to reinvent the wheel.

Reach out to discuss of ways to save time on the software programming needed for your project.

Lei Zong


Every challenge is different – Tell us about yours.