Prototyping electronic development projects

Prototyping an Electronic Design

Prototype circuit boards are generally assembled by an electronics engineer rather than an assembly line worker or technician. During the design of the circuit, some portions of circuitry may have been tested by "bread-boarding" (making up the circuit in a makeshift form) or simulation (using SPICE, a circuit simulator). During prototyping the remaining areas of circuitry are usually tested in isolation, before debug begins on circuitry as a whole - this is sometimes done by assembling the PCB in stages, and used to be done by assembling the PCB with Integrated Circuit (IC) sockets. The testing itself is according to a plan developed for the design - the debug test procedure.

It is best to build up the circuitry in stages because There's no debugging harder than fixing a symptom that has more than one cause, - it's a lot easier to find faults one at a time.

What... don't these things work first time? Usually they do... by the time the customer sees them. And many of our debugging tests are passed first time. But there's a law out there that says If you don't test something thoroughly, it'll probably fail later.

To prototype and debug, a good stock of electronics parts and materials is needed. It will really disrupt the task to have to stop and buy 10k 0603 resistors to pull up a signal line, or to have no hot air tool to help remove a part, or no desolder wick then propan-2-ol to clean up the pads afterwards. A lab/workshop area is needed to prototype. As the prototyping proceeds, areas of the circuitry will be tested and this often involves building up small test jigs, for instance to mock-up an input device. As and when problems are found, the solutions are often tried on the prototype circuitry directly, by adding components or rewiring.

Prototype testing usually involves some verification of design parameters such as timing, temperature susceptibility and supply voltage variation.

It is best to debug microprocessor circuitry on the target, in the operating environment, using specifically written Diagnostic Programs. This can be preceded by using emulators or simulation in the design environment. Emulation and simulation will clear a majority of faults - in reality, the straight forward faults - but you must debug on the target. If there is no hands on period, you are essentially shipping a product that has not been stressed or examined. There is no substitute for this, it is about being thorough.

Always make more than one identical prototype before starting to test a design. You can then compare tests using two boards (ie using one as a control). You can quickly resolve if any problems are a design issue or a random component failure. If there is a major problem, such as the main CPU getting fried, it does not mean delaying the project. As you exit the prototyping stage and go to handover, having more than one prototype will give confidence to the client. I have seen clients given just one prototype act as if they are holding a gold bar - it represents all the R & D costs they have invested - and that is the wrong thing to do to a prototype. Prototypes should be hammered - if there are problems, you want to find out then, if they break, you want to fix them. If a client is given more than one prototype, they are more likely to do this. Having multiple prototypes also leaves a spare board available as a production sample.

You can also produce mockups at some point in the design process - mockups are non-functional PCBs used for physical sizing. Usually a mockup will just have a few parts on it - the connectors, any tall part (e.g. An inductor, Electrolytic capacitor) and any mechanically critical parts - LCD, LEDs, switches, battery, mounting holes. A mockup allows other teams in your project to get on with their job - the mechanical design of the enclosure, the documentation, and sometimes even the sales guys. The more the mockup matches the real thing, the better, - it just does not have to work. For the designer a mockup tends to freeze your mechanics. After producing a mockup you need communicate any change in component position to every other person who could be using that information. That will slow down the rest of your project slightly, but everyone elses work will speed up.

Some companies go through several iterations of prototype - some may have up to 7 revisions before going to pilot run. Obviously, the more prototypes and iterations the larger the cost of the project - but it also gives the design team more opportunity to smooth out any wrinkles in the design. It is a case of balancing costs against return.

Time is a great teacher, but unfortunately it kills all its pupils -- Hector Berlioz

Handover

The finished prototypes are given to the customer at Handover. Handover is best accomplished face to face, and it will be a substantial meeting. Handover gives the two parties an opportunity to talk frankly about the project. Every R & D project runs over time and budget, it is the nature of things, and every design involves workarounds and compromises - but communicating these is central to allowing both parties to continue. As a design engineer don't expect "a pat on the back."

Expectations should also be honestly set at handover. The reason prototypes are built is to find problems. It is expected that the majority of problems will be found by the designer, but there will normally be one or more waiting to be discovered by the client. By handover the designer has completed all but warranty work, they would expect the completion payment for the project. It helps to cover both these points.

If a client is given a project with a workaround, it really should be honestly explained, so they can make a success of the product. An example: It is desirable that reverse battery polarity should be protected against, and not damage circuitry, but there are a few designs out there which do not have this feature - usually for good economic or efficiency reasons. If this shortcoming was just conveniently omitted from handover discussions, you would be seriously disadvantaging the client. You really should have told them as the design compromise was being made.

OPINION: This is why it is so difficult for honest subcontract design companies to work for government departments. Government's attempt to set up level playing fields, avoid collusion, have short term tenders, and to make suppliers accountable. But suppliers that can express genuine surpise when their design compromises are discovered are at a positive advantage! Working closely with the client in that environment puts you at a disadvantage, honesty is discouraged, and the only person the client speaks to is a sales person.

Computer Folklore A novice was trying to fix a broken Lisp machine by turning the power off and on.
Knight, seeing what the student was doing, spoke sternly:
"You cannot fix a machine by just power-cycling it with no understanding of what is going wrong."
Knight turned the machine off and on.
The machine worked. -- MIT AI Lab "AI Koans"
[Tom Knight was one of the Lisp machine's principal designers]