Having worked with embedded systems for a number of years, I have seen several undesirable practices a number of times. These make a design harder to complete as the development process moves on, rather than easier. Things I’ve seen include:
Issue 1: Create a proof of concept rapidly with little thought beyond it.
A small group of people have a great idea. They must turn that idea into something that works quickly to attract interest and funding, as well as proving to themselves the idea can work. A prototype is constructed that might use “quick and easy” techniques and non-optimal component selection to achieve this. The prototype is then successful, funding obtained and the whole business and idea can (and will) start to grow at pace.
The difficulty that can arise is that while the prototype may have done its job, there is rarely the opportunity to go back to the drawing board and start the “real” product design from scratch. The prototype becomes the product. The engineer is then challenged to complete the design and optimise aspects like power consumption, reliability, and user experience on a system that does not easily accommodate this. Also, a design that is cost effective for 100 or so units may not be for 100,000 units.
It is true that sometimes the speed at which a prototype must be built necessitates a certain strategy and solution which will never scale well, but it is best to at least bear in mind the manufactured product and try to keep it and the prototype aligned as much as possible.
Fairfield Technology can help create these proofs of concept, but will aim to think ahead and consider:
- What happens once the concept has been proven?
- How easily can this prototype be moved forward to a sellable product?
- How will this scale to make 1000’s or more?
- What will the cost be?
Issue 2: Design hardware first, firmware second.
I have seen instances where all hardware and component and component selection is done by the hardware team, because it is wrongly thought this is 100% a hardware matter. This includes the choice of microcontroller, as this is seen to be simply another hardware component.
A firmware engineer (or team) is then bought in and expected to use the given hardware. At this point many obstacles are found that could have been easily avoided if the firmware had been borne in mind when the circuit was designed, this could be anything from clock speeds and memory requirements to voltage reference tolerances, I/O capabilities, and power consumption. A significant portion of the design time becomes consumed with various firmware workarounds for the hardware issues, some of which may be more effective than others.
Fairfield Technology believes that the firmware and hardware are deeply related, and therefore will consider both aspects together from the very beginning. This can take into account things like the use and expected volumes of the design and the required time to market as well as the cost/performance/risk elements.
Issue 3: Over complicating the design and reinventing the wheel.
It is not easy to get an embedded system working perfectly, especially one that must communicate with another system through an interface such as Wi-Fi or GSM (which increasingly more have to do). There is little to gain from choosing components, subsystems or firmware design patterns that are not entirely suited simply because the designer wants to do so “for the technical challenge”. Having said that, there is certainly some justification in using elements the designer has some familiarity with.
Fairfield Technology will aim to keep the design as simple as is practical but without cutting corners, yet will use techniques and components from experience wherever possible.
Issue 4: Designing and coding everything in one go
I have seen design departments produce a populated PCB, loaded on the “finished” firmware and wondered where to start looking when it is powered up and doesn’t work as expected. Of course this could be due to a bad solder joint, an easily found bug, or something else quite minor. Yet sometimes it isn’t. Many peripheral IC devices such as ADCs, sensors and memories are now quite complex systems, each with their own instruction sets, timing requirements – and quirks. Having to debug a board featuring several of these devices all in one go can be daunting if the devices and driver code have not been tested in isolation first. This is made worse if there is a bad solder joint, incorrect PCB track as well… It can also create a very unrealistic picture of the project’s progress – “The board is finished, the code is all written. We’ve just got to get it working now”.
Fairfield Technology will, where appropriate, hand build sections of the circuit or use an evaluation board and write the code and test it as the project progresses. This way each IC or subsystem gets very specific attention and there are less nasty surprises during the integration stages. Sometimes the actual code is not complex in itself, simply writing some setup values to registers and then reading values periodically for a sensor, for example. It is determining from the data sheet and the requirements exactly what these settings are that can be challenging and time consuming.
Matthew Constance, owner, Fairfield Technology Ltd
January 2022, updated February 2024