Prototying Methodology

Go To Last Post
28 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hey All,

Just wanted to know what the steps are in your design process. I typically do the following:

1. Take idea and determine required components such as MCU type, RTC, op-amps, etc.

2. Write software for said design.

3 Build prototype circuit on strip board and test hardware / software functionality.

4. Revise software

5. Design PCB

6. Stuff PCB and test performance against prototype circuit.

7. Make PCB / hardware / software revisions as necessary.

8. Test finalized design.

How about you guys? Do you always build up a prototype circuit on strip board or do you go directly to designing the PCB and then test from there? I feel like some of my designs are taking longer than they should because I build up a prototype circuit before laying out the PC (this may be due to my limited experience.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

We do as much as we can on old board revisions by cutting tracks and/or adding ic's just using wires. That's for small hardware additions though. For large changes we would just design and order the pcb straight up, because there are almost always errors on the pcb that need to be debugged anyway.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Would not step 2 be a circuit diagram?

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

js wrote:
Would not step 2 be a circuit diagram?

And step 3 is to get a colleague to review it.

And step 4 is to get a colleague to review it.

Make sure at least one is a software person, who can evaluate how hard the software will be to write/port. I've had hardware people try to save trivial amounts on some component that took me a week to write the driver for (for a board that we maybe would have produced 1000 of).

Not just a glance over, but a full-on serious review that might take a week or more (well, that was how long the last review I did took for a full ARM Cortex-A8 + Linux design).

It's cheaper to pick up mistakes before they ever hit the prototype stage (whether you use a breadboard or not).

- -Damien

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If it is a totally new design, then try to get eval boards for the critical devices. If you're feeling confident, then do a pcb first up. Nowadays, there's various simulation programs that can get you closer to the mark without actual hardware, there's breadboards to prototype an idea, you can use dot board or veroboard to solder something together. The exact method depends on the complexity and your gut feel.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Assuming this is for a client, and not just a hobby projects, I would be doing a close tick off against the client's statement of requirements and your response to his RFQ. Also have you allowed for the inevitable feature creep that might need just one extra byte over the limit of your chosen chip? Hell, you might want to add that feature to improve your production testing ...

And as Damien said get it reviewed, especially by someone who is NOT a "yes" man.

Cheers,

Ross

ps ... I should also add that I usually identify the part/activity/assumption that has the highest risk and do a sub-project to prove that hurdle can be overcome. No point in having 95% of the thing working but it fails because of the hardest bit that you decided to leave until last hoping for a miracle or new product to be delivered :lol:

Ross McKenzie ValuSoft Melbourne Australia

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

1a - write a specification

1b - design algorithm

perhaps?

(there is an iterative nature to this - once you start prototyping and implementing some of the modules you may find changes are required to the specification and the overall algorithm design - you may even decide after experiments that the chip is not suitable and wind back even further)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This is perhaps higher level, but might as well add it to this thread. From an Agilent Appnote.

oddbudman

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This is not for a client, just a hobby (for now at least). I would like to develop my own method so that I have a standard process and wanted to get some input on how others tackle the design process.

John: Yes, step 2 should definitely be circuit diagram....accidentally left that out!

Ross: This seems like a good approach (only prototyping the circuits you're unfamiliar with), and probably would be the approach I would take after having more experience.

clawson: I suppose during the "idea" phase is when I write a (not formal) specification. I determine how many inputs, timers/counters, etc that will be needed.

oddbudman: Thanks for the App Note, I think that is a good overview. Would you design the PCB at the "Lab Prototype" phase? I think I may be trying to move too fast as I want to get more experience in designing PCB's.

What I have been doing is reading a lot of the manufacturer App Notes and using their suggested circuits when designing the PCB. I should probably be testing these circuits on strip board first before incorporating these into the PCB design since I am not familiar with some of these circuits.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

clawson: I suppose during the "idea" phase is when I write a (not formal) specification. I determine how many inputs, timers/counters, etc that will be needed.

That's part of it but in a professional environment we used to start with a spec. that was very similar to the eventual user manual. So it'd tell you that if you press button 2 it would switch to the calculator or whatever. This then gave management the chance to say things like "but we thought button 2 would switch to the calendar" or "what happened to the alarm clock feature - we were expecting it to be accessed by a long press of button 4". Management weren't particularly interested in that timer2 was being used to implement the RTC or that timer1 was used to measure input pulses or whatever - though a technical part of the spec. would cover this kind of detail so that the engineers reviewing the spec. could also comment.
Quote:

Would you design the PCB at the "Lab Prototype" phase?

Do the PCB layout as late as you possibly can in the design - saves a lots of straps and cuts to correct the things you over-looked.

(we see far too many threads here from people looking for software solutions to problems because they committed to the PCB design too early and only later realised they needed to use INT0 rather than PCINT7 or whatever but that pin is now tied up with something else).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That makes a lot of sense clawson. I always thought of prototyping as designing both the PCB and the circuit and trying to troubleshoot it from there. If you finalize the circuit via strip board and then proceed with the PCB design, you are ruling out any circuit design related errors and troubleshooting only the PCB layout. Once again, it looks like the K.I.S.S. principle applies here!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

f you finalize the circuit via strip board and then proceed with the PCB design, you are ruling out any circuit design related errors and troubleshooting only the PCB layout.

Exactly - but you may not need to prototype everything in the design. If you have a MAX232 setup you always use for the RS232 connection then no need to restest that part of the design each time (though you might keep a potted "module" you can bolt in to get UART access working early anyway). Just prototype that new I2C EEPROM or that SPI ADC you haven't used before and make sure you know all it's "foibles" before you actually commit the final design to copper. You maybe don't have to write all the supporting software for it at this stage either - maybe just enough to prove you can read/write its control/status registers or whatever.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson: Great advice. Thanks for the input.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For hobby stuff I actually design up the PCB as soon as I have a circuit. Yeah, I may very well have to adjust it later, but I just hate wiring up prototypes. While I'm waiting for the first set of boards I'll work on the software and order any parts I need. Then the boards come and I put one together and see how much hw and sw I got right and fix the rest.

I used to hand-wire boards but now with so many SMT parts it seems both easier and no more expensive (no adaptor boards to buy) to start with a PCB.

Let me emphasize again that I'm talking here about hobby stuff, not work stuff.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

While I'm waiting ... I'll work on the software

Just out of interest - using what hardware? Or is it all just theoretical/simulator at this stage?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For hobby and learning projects I'll usually perform these following activities as the FIRST STEPS in the design & prototyping process. For professional product design projects, I take a much more elaborate approach, but will still utilize these steps as part of that more elaborate regimen.

The beginning assumption is that I am past the "mental stage" of the idea which is to be implemented. I've thought thru the idea, visualized the end product, developed a "kernel" idea how to accomplish the end product or goal and feel somewhat confident I can pull off the design to some level of success.

Step 1 - I use a B-size (11x17) quadrile pad to sketch a "blockmatic" diagram of the whole idea. A "blockmatic" is a cross between a schematic and a block diagram - more detailed than a block diagram, not as detailed as a schematic. I'll annotate the blockmatic with waveforms, calculations, commentary, alternate parts choices, anticipated power levels, preliminary calculations, draw a pictorial of the front panel, etc. Whatever might be appropriate for the specific technology utilized in the project. When I'm done with the blockmatic I've got a pretty good idea of what the hardware is going to look like, the type of processor to use, one or more specific candidates for each chip, alternate ideas for various subsections, etc. Overall, a clearer mental picture of how the whole thing is going to work.

It has happened more than once that I have run into some conceptual or design roadblock at this stage, that either caused me to abandon the project or make a radical change in the design approach.

In general, it takes me an hour or two to whip the blockmatic into more-or-less final shape.

Next, kind of a Step #1A, I'll usually take inventory of what components I have on hand, what I have to purchase, and make a quick scan of DigiKey, Mouser, etc to make sure I can get what I need FROM STOCK (else modify my parts selection to something I can get without a lot of hassle). I'll also go thru my past software projects to pull routines and snippets of code I think will pertain to the current product and pull these together into a dummy project folder.

I'll revisit the blockmatic a number of times to rethink premises, question asumptions and "take a fresh look". Often a better idea will emerge and I incorporate it into the blockmatic.

Step #2 - Once I'm committed to the blockmatic and feel the project has "a future", I'll sit down at the PC and type a narrative description of how the thing is supposed to work.(Some would call this a "theory of operation".) This could end up being a few paragraphs or a few pages. My main objective is to make sure I am thinking rationally about the project's functionality. That I am not trying to perform an impossible task, uncover logical inconsistencies or unacheavable levels of performance (noise, power, precision,etc).

In earlier days when I was learning the craft of electronic design, I would seek advice from someone I felt was more knowledgable than myself to discuss my idea. I will still do that today, but I have learned that I can "shake out" a lot of mistakes in the concept and design of the project simply by writing how it will work. When I find myself typing something stupid, I know I have to rethink that part of the design.

By the time I am done with the narrative description I will have identified if there is a "deal breaker" lurking in the project. Is there one component or aspect of performance which is the "big unknown"? Maybe its the speed of a specific software routine, or the ability to make ADC readings at a very fast rate, or to produce a certain brightness level from an LED, or sound level from a piezo, etc. The big question is: Do I have to perform an experiment or build a "pre-project" breadboard to make sure the "deal-breaker" is achievable before committing time, energy and money to the whole project? To be sure, it may be that the "deal breaker" merely appears to be a "deal breaker" because of my inexpereince with the specific technology. Still, the uncertainty has to be dispelled before a serious design can begin.

So, Step #3 - resolve deal breakers by performing an actual and honest experiment. Often the "deal breaker" turns out to be more of a design or performance constraint than an actual go-no-go decision. That is, the project will still work, it just won't work as loud, bright or fast as originally intended.

Step #4 - Draw a complete schematic. In the process of drawing the schematic, I'm assembling the required parts form my on-hand stock, making up order lists for Digikey, etc, or finding the parts thru "beg & borrow" sources. By the time the schematic is done, I know that I can get every part one way or another.

If the project is to be breadboarded on a PCB, as I am drawing the schematic, I'll make up a dummy project in my PC layout package and start laying in parts to see if the "fit" is realistic - no connections just the packages.

If the project is to be a proto-board, I take a full size piece of protoboard and lay the actual or equivalent parts on the protoboard to determine how big the board needs to be. I usually won't cut the board to size until I am forced to by some aspect of the bulding process. The worse thing to do is leave yourself short of board space and you'll be forced to add on outriggers and scabs to make up the space deficiency.

That's how I get things started, now the real work begins! As I stated at the beginning, these are only the FIRST STEPS I take in a hobby or learning project.

In a professional product design project, things are much more complicated for a number of reasons. And to get to the stage where you are ready to draw a schematic or layout a first-cut PCB takes many more steps, considerations and time. The main reason for this is inter-personnel communications. In the hobby project YOU know what the project is in your mind's eye. In a professional project, there are MANY mind's eyes, each seeing a different image of the end-product. These disparate images must be brought together into a coherent project defintion first before the real design can begin. That takes a whole different process than what I've described above.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Right now I work with mostly through-hole, although I am starting to get more into SMT due to the lack of availability when it comes to through-hole components. I can see your point about the adapter boards as they are not very cost efficient in a lot of cases.

kk6gm – How does the process work in the (assuming) corporate environment that you work in?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Quote:

While I'm waiting ... I'll work on the software

Just out of interest - using what hardware? Or is it all just theoretical/simulator at this stage?

All of the above. I may be able to use some existing hardware (one collects a lot of boards over the years :)) to develop this or that area of functionality, but a lot is just theoretical/simulator, as you say.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I like to build one before I do much of the programming so I can test the actual function of the program as I write it. This reduces the fright of having written a brazillion lines of code, loading it in the chip and seeing absolutely no response.

I usually start programming with things like, "Can I turn the output fets on and off?" "Can I read the buttons?"

Since I went with SMD, a prototype PC board is early in the process. I usually make these at home with the assumption that it likely bears little resemblance to the finished product.

Once I have a working sample, I either:
A. Use the 1 or 2 that I made and contentedly play with my new gizmo.
B. Make a few more for the purpose I had in mind.
3. Start designing the final product case, board and all that rot.

Almost all of my projects go to stage A or B, but start with the idea of going eventually to 3.

The largest known prime number: 282589933-1

It's easy to stop breaking the 10th commandment! Break the 8th instead. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

(one collects a lot of boards over the years

Indeed - one can often "butcher" a previous design to prototype something new - possibly even better than stripboard/breaboard - though they may be used to mount the "new thing".

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Indeed - one can often "butcher" a previous design to prototype something new - possibly even better than stripboard/breaboard - though they may be used to mount the "new thing".

I guess that would be a disadvantage to using the "reusable" breadboards.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Lots of good advice above.

The vast majority of my work is all hobby oriented, so I know where you are coming from. Don't get overly frustrated by how long it takes to develop a project. It takes time. There are few "weekend projects" that really take a weekend! When you don't work on a project full time, but only a few hours here and therer, it can take months, or even years, to get something done, especially if the project gets bumped down the priority list a time or two.

Like Chuck-Rowst I also have a block diagram as an early part of my projects. Blocks for sensors, displays, switches, memory (SD, FRAM, etc), USART, USB, Power Supply, RF (Xbee, Bluetooth, etc), programming interface, etc.

It helps to see all of the various components of the project and how they will interact. I start to lok at specific sensors and cmponents at this stage, also. Using a 3V GPS means using a 3V micro, 3V GLCD, 3 V Max232 type chip, etc. Some projects can fall apart half way through the design if the global view of the project hasn't been carefully reviewed.

I used to breadboard most of my projects in their entirity. It is getting tougher to do this as more and more parts are available in SMD packaging only.

These days I am more likely to breadboard a new sensor or a new display, but not the entire project. The main project spins off mini-projects: Write the sensor interface, write the GLCD driver, etc. The main project eventually becomes a process of integrating a bunch of known-good modules (hardware & firmware).

I also have many boards around, and can usually fine one to run these mini-projects on, or breadboard them. When Atmel can out with the Xplain board for the Xmegas I purchased one, but it has rather limited I/O ports available for the end user. I made up my own Xmega "development" board, it has 6 or seven ports available, bulit in LCD, LEDs, switches, piezo, power supply, RS-232, etc., so I can use it for most sensor and comm's device testing.A cable ties it to a breadboard with the device being worked on. Easy.

Two last thoughts for you.

I hope you are using a multi-monitor set-up. My efficiency in project development went way up when I started using multiple monitors. It is so much easier to have multiple windows in view. Schematic, data sheets, design notes, prior designs, google, etc.

Lastly, I try to write my thoughts and notes to myself about a project in a Word document for the project, rather than on a sheet of paper.

I end up with each project haveing several 3-Ring binders asociated with them. One for the overall project, concept, goals, block diagrams, schematics.
One for the electronic design and schematics.
One for the PCB layout.
One for the case, (if the project gets one...).
One for the software.
Larger projects can have several binders for each component, Analog, Digital, power supply, etc).

As I am only typically working on one sub-section at a time, this makes it easier to have what I need readily available, but not be swamped with project data sheets, test module software, etc., when that isn't pertinent to the task at hand.

Writing occassinal notes to myself in the Word file makes it easy to find a summary of my thoughts on the various component selections, interfaces, design trade offs, etc. I don't have to search for scribbles on the back of a schematic, or try to re-read my own writing, (is there a pharmacist in the house...).

Part of reducing design time is being organized. As you build more projects you will find what works well for you, and have more hardware available for reusing.

Good luck with your projects!

JC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Oh and use a code versioning system! Even if you work alone.

As an example I downloaded the FatFs example file the other day. I then made some changes but now I'd like to be able to document what I actually changed

If I'd committed the original files to SVN (say) then I could use [Check for Modifications] and get an instant view of what I'd edited.

Without code control I now have to dowload a fresh copy then diff the directories.

What's more if you start with a good working version then make a "tweak here" and a "tweak there" then suddenly discover the code is now broken you may have no idea which change you made caused the problem. With a code versioning system you could either just bite the bullet and "revert.." to go back to the known working version or you could "check for modifications" and see all the things you changed - then "#if 0" each one in turn until you find where the problem lies.

You can save days with this. But make sure to backup the repository regularly as it's the "family jewels" (as my ex-CEO was keen to point out regularly).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

DocJC wrote:
I hope you are using a multi-monitor set-up. My efficiency in project development went way up when I started using multiple monitors. It is so much easier to have multiple windows in view. Schematic, data sheets, design notes, prior designs, google, etc.

As many as your desk will fit! With 23" monitors well south of $200, there are few things that will make you more productive.

-- Damien

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Oh and use a code versioning system! Even if you work alone.

SVN is free and so easy, even our marketing people use it!

You can make it much more powerful too. FishEye ($10 for hobbyists) or Trac make it very east to see the history of how a file or a branch has evolved over time, or to see the difference between experimental branches etc.

This has been discussed a few time on these forums - a good search will yield wonders.

-- Damien

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the suggestions everyone, really appreciated! It seems like everyone has their own style, eventually discovering what works best for them over time. It is good to see the different strategies to borrow from when developing one's own methods.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

And in a professional environment, test for EMC as soon as possible; and of course, think about EMC at the earliest of earliest stages of design.

EMC problems in a late stage can be extremely costly, witnessed that myself recently :(

And that happened at a company that has a free-for-anyone-to-use, walk-in-at-any-time-you-like EMC test room :roll: A simple prescan only takes at most twenty minutes.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jayjay1974 wrote:
And that happened at a company that has a free-for-anyone-to-use, walk-in-at-any-time-you-like EMC test room
That has to be the saddest thing I have heard today ...

Ross McKenzie ValuSoft Melbourne Australia