AVR Freaks

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

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

oddbudman

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.

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.

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

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