5 replies to this topic

[YvesGoeleven]

How do you guys go from prototype to a full product? What are the steps involved? Anyone been through this journey already?

[Chris Walker]

(raises hand)

A follow-up question: would you guys like us to show you how to take a product from prototype to production? Provide more tools to make this an easy process?

Chris

[YvesGoeleven]

Yes please!

[gismo]

(raises hand)

A follow-up question: would you guys like us to show you how to take a product from prototype to production? Provide more tools to make this an easy process?

Chris

 

Yes!

[NeonMika / Markus VV.]

(raises hand)

A follow-up question: would you guys like us to show you how to take a product from prototype to production? Provide more tools to make this an easy process?

Chris

 

That would be really cool. For myself I always used microcontrollers only for "hobby-purpose", but it would be really nice to see and learn more about the whole "prototype to production"-lifecycle.

[GeorgeHahn]

In my experience, it goes roughly like this:

 

Proof of concept ("just make it work, I don't care how it looks")

This can be anything, it just needs to prove beyond a (minimal) reasonable doubt that the microcontroller being chosen will be able to accomplish what is necessary for the application. I've seen everything from $2000 dev boards with traces cut to connect lines to existing products with new components dead bugged on top. The hardware doesn't need to be exact, or even terribly close. For example, if an LCD GUI is needed, whatever LCD came with the dev board is probably fine as long as it's close to the required resolution. The more you fudge and ignore here, the more often you'll get burned, but it can save a lot of time, especially if you have to reverse engineer anything down the line. (I come from the aftermarket auto electronics industry. We had to reverse engineer almost everything; there are plenty of times when nobody knows how to turn on the OEM car display you need to drive until the first or second prototype is on the way.)

 

There isn't always a proof of concept - many times you can jump right to a first prototype.

 

Prototype 1..n ("get the right hardware in the box and make it work")

Here's where you try to hit all of the goals for the final product. Depending on the complexity of the design, early prototypes may be laid out with a lot of room to work and with extra test points. Once the design has been somewhat proven, layout is switched to the final device layout. While the hardware people are doing their thing, the firmware people are scrambling to uncover any potential issues with the hardware, because the later they catch a problem, the harder it will be to solve. They need to bring up all essential systems - communication, UI, analog in/out, RAM/ROM in higher end systems. (If the proof of concept was shown on a devkit display, this is when the firmware needs to be adjusted to talk to the actual display.)

 

It's worth noting that many designs don't need a long series of prototypes to get to their final board shape. For simple or slightly tweaked designs, the first prototype can be laid out in the exact size it is expected to be manufactured as. Furthermore, there are plenty of times when the design is complete after one or two prototypes.

 

Write firmware

The firmware developers will continue working on their code until program and test begins. (Else program and test will wait until the firmware is ready.) This is the time for clever software tricks to cover up hardware mistakes that made it through the prototypes. Sometimes that means underclocking the micro and heavily optimizing its sleep behavior because someone put a leaky transistor in the design. Other times it means trying to fit 64K of functionality into a 48K part. This is the land of the dirty hack, because if it can't be fixed in code, it's going to be a very costly issue. (Anything from thousands of PCBs trashed to rework on hundreds or thousands of devices.)

 

Source components

Ranges from a collaboration between you and your assembly house and all you. Sometimes your assembler can supply all parts; if not, you need to purchase parts and have them delivered.

 

Build program/test fixture

Depending on the quantity of devices to be built, you may want a fixture to speed up program and test. (Can you imagine programming thousands of boards individually with a JTAG programmer?) I'm most familiar with pin of nails style fixtures, where a board is pressed down onto an arrangement of sprung pins (pogo pins). These pins connect points on the device under test to the fixture. Think JTAG, ISP/ICSP, analog in and out, UART, etc. The programmer may initially program the board with a special test firmware or test functionality may be built into the production FW (or it may not be necessary at all). Once programmed, the tester wiggles lines as necessary. For example, it may tell the device under test to bring a line high or send some CAN messages, which it waits for and verifies.

 

Assembly (If possible, verify first boards off the line)

If possible, first boards off the line are snagged and tested to make sure there aren't any simple mistakes across the next thousand. (Pick and place operator put 5v tantalums instead of high voltage diodes? Oops!)

 

Program and test boards

Assembled boards are programmed and tested with your fixture. Failures are removed for further analysis. Boards may be labeled with any of: serial number, firmware version, production date, or similar.

 

Troubleshoot failures (see if assembly or design can be improved to decrease failure ratio)

Failed boards are analyzed to see what went wrong. This is always (and sometimes extremely stressful) because there are a ton of things that can go wrong in a complex design. It could be something simple - the fixture is being 0.05v too strict on an analog measurement. In this case, you take a 'failed' board and put it through a functional test ("does the audio sound okay?") and adjust the tester as necessary. There are always some assembly issues - missing parts, bad alignment, solder shorts - but these should be minimal and can usually be fixed with some light rework. Bigger problems can also arise - maybe your micro isn't decoupled well enough and some tend to reset randomly. Maybe all of your micros are resetting randomly. Maybe an oscillator isn't starting up on some boards (this one's usually temperature dependent too). Worst of all is when your tester is flaky. (For this reason, it's not uncommon to have a standard bit of test hardware. It can be third party or in house, but as a rule, it should be very well tested and pretty solid. It helps if it can be repaired easily, as some failed devices can cause the tester to fail - for example, a device with a UART TX shorted to VCC.)