A next step is to build a prototype that will work like the final product, but not have the same form factor or appearance. That is, the prototype will attempt to use components that would be used in a final product. This “works-like” prototype is often a collection of evaluation boards, breadboards, and proto-boards with components soldered together.
This article will describe some of the benefits to starting software development on an early “works-like” prototype. While the software team works with the prototype, the hardware team can start the design of custom hardware.
Early Completion of Software
One big advantage of starting software development on an early hardware prototype is that the software is ready soon after the custom hardware boards are complete. There are many times when I have received a new custom designed board and had the software running on it after a matter of just a few hours. Starting the software development early can save weeks from the project schedule. The software work can be started before the hardware team even starts the main work of designing the custom hardware.
Even if the custom hardware ends up being quite different from what was envisioned when the software work was initiated, there can still be large time savings. This is especially true for any part of the software that is not specific to a particular processor or peripheral part.
Identification of Hardware or Software Issues
Another benefit to early software development is that it may lead to the discovery of issues that will affect the design of the hardware or software. Identifying issues early on saves time and avoids difficult work-arounds or re-design work.
As an example, I was recently working with a touch sensor that is controlled by an I2C connection. An MCU with built-inI2C peripherals was used to configure and read the status of the touch sensor. The touch sensor had a long response time, often waiting for more than 7 ms before providing an acknowledgement. The I2C driver code I was using had a timeout that was only 5 ms, and communication failed most of the time. An easy solution was to use a different I2C peripheral on the MCU, one that did not use a timeout. Because I started coding the software on an early hardware prototype, I was able to request the hardware team to use particular I2C pins for connection to the touch sensor. Pins that would allow communication without the timeout problems.
Proving Difficult or Risky Solutions
Using a hardware prototype can be helpful in proving the viability of a particular solution to a problem. Sometimes it can be difficult to know if something is possible until one tries it out. This is especially true when a software component may require large amounts of memory or processor cycles.
Recently I was writing code for an MCU that needed audio input from a digital mic. The processor planned for the project had an audio peripheral on it, but not one designed to handle the output from a digital microphone. It is possible to process the output of the digital microphone in software, but it requires implementing a digital filter. It was unknown whether a solution could be designed that would be adequate in terms of audio quality and required processor cycles. A “works-like” prototype was constructed using processor and microphone evaluation boards. And it was proved that a solution could be implemented before the hardware was designed.
User Experience Experimentation
Having a working prototype is useful for making decisions about the implementation of the user interface for a new product. It is a way to experience the usage of the product in real-time and evaluate different options. Implementing a “works-like” prototype also helps one to think about what status indicators and controls should be available to the user. For example, I was recently working on a prototype for a Bluetooth speaker. There were several different states that could be communicated to the user, including disconnected, connected, and pairing mode. There were also several user inputs to consider (and these were just the ones performed on the speaker itself): changing the volume up or down, putting the speaker device into or out of pairing mode, initiating a connection (connect to last connected mobile device, for example), disconnect Bluetooth connection, and finally a “factory reset” command that would remove all information about previously paired devices. Once all of these possible features were known, the team could discuss methods of implementation and experiment with them on the prototype.
In conclusion, early software development using a hardware prototype has the potential for reducing the overall time to develop a new product. By having software and hardware teams working in parallel, problems can be identified early and software can be written and proven early on in the project.
