Design Process ( don’t be afraid!)

Design is an art form and it takes many years to become good at it. I have summarized some of my thoughts on what works for me. These are tips that may even help you so don’t be afraid of process.

I have managed large and small project developments and the design process is always the same. The biggest difference with a home project is that you are not constrained by deadlines which brings creative freedom. The second major difference is that home projects are usually cost constrained to less than $100 whereas my working projects would cost many 100’s of thousands of dollars just to build the first prototype. This type of expense leads to a design rigour that aims to avoid re-spinning a board. For my hobby projects 10 PCBs typically cost me $18 including shipping so I don’t worry much if I get the design wrong and have to re-spin the board. In fact I plan on re-work.

The design process I follow is graphically illustrated here. I will describe some of the more interesting aspects of the process in the following sections. I hope that you find it as useful as I do.




Design: No amount of planning will ever replace the knowledge you gain from actually building a board; only by building and using a project will you learn what you could have done better. For me this realization plays out in the form of using Eagle to capture a sketch of an idea. I use schematics to capture developing thought but I don’t worry if I’ve forgotten some feature when I send the board off to be built. The other consequence of this style of design is that I always auto-route the layout of these early designs. Now that’s heretical thinking for an Electrical Engineer. My rationale is the same as writing a set of rough notes; they don’t warrant tidying and formatting, they are good enough. I have yet to have an issue with auto-routed boards running sub-20 MHz. I usually beef up the power rails to 10 or 15 mils by setting the net class, and I always apply a pour filled ground plane.

I use the Eagle schematic capture tool which offers free usage for two layer 100x80mm PCBs. Over the years I have developed a custom component library that I use. This library has proven component symbols and I keep an inventory of the components on hand so that I can rapidly prototype a new design. The Eagle auto-router is quite capable and speeds my prototype development .

Review: Along with Eagle I use an excellent user language program called Eagle3D which allows me to render my PCB designs. When I add a component to the Eagle library I make sure I code a 3D object in POVRay so that the board renders completely. This becomes a very effective way to double check my work. Effectively I code each component twice, first in Eagle and then in POVRay and I know I have a problem if the resulting board rendering is visually wrong.

The only other PCB detail I worry about is making sure that I can read the silk screen. It’s quite important that silkscreen text doesn’t lie on top of via’s or pads otherwise they become unreadable and could interfere with soldering. This is a bit difficult to visualize in Eagle so I always run Eagle3D to create a photo realistic rendering of the board including the silk screen placement. More often than not I discover silk errors or components to close to each other. I fix these prior to sending the board off to SeeedStudio to be built.

Purchasing: Remember I said home projects are not on a deadline so I don’t pay for expedited fast shipping which would cost more than the boards themselves. To keep the cost of shipping down to $8 I have to wait three weeks while the boards are mailed to me. That said, how many of you could actually use the board if it were delivered in 3 days? I would venture a guess the answer would be none. I use the 3 week shipping delay to order components for the build and to start writing test code. I tend to focus on diagnostic drivers so that I can test the prototypes have been assembled properly and are working.

I manage the purchasing of components by running the bom.ulp script in Eagle which generates a text file that I import into an Excel spreadsheet. The spreadsheet is in turn linked to a database of all of the components that I use so that I can quickly cost out a board. Managing to keep the database current is a bit of a nuisance but I only update it when I order new parts and the price or part numbers have changed. While Digi-key is not the cheapest supplier I find there service to be excellent and they have a broad selection of components. I also like the fact that when I order components by 6PM they arrive at 11am the next day; all for $8 shipping. Other vendors may look cheaper but the hidden duty and shipping charges can be a very rude surprise.

Also when I print the BOM file I check to see if the component numbers are sequential and if not I correct them. I do this because it is a lot faster assembling the boards if you can place groups of components all at once. I also look for component optimizations where I can standardize on a single component value when the values are close.

Build: In a previous post I explained how I solder SMT components using a toaster oven so I won’t repeat that here. I do however create assembly notes to help me assemble the boards correctly. I take the Eagle file and use it to generate a 3D rendering that includes the component values rather than just the U numbers. When I get boards made I only include the U,C, R, J numbers on the silk screen otherwise things get to cluttered. When I create the 3D rendering I only display the components values so that it is really easy to place the actual components. I print the top and bottom assembly drawings and use these as a reference when I actually assemble the board. On very dense boards I will colour code the components by manually tweaking the 3D PovRay file. For example I might colour code all of the 0.1uF decoupling capacitors red so that I can quickly place the board components.

Code: I do most of my coding in C and use the GCC compiler to build the code. This choice of GCC means I only need to learn one tool to support a wide variety of processors. I’m not a big fan of writing host code but even that becomes easier when I use MSYS and CYGWIN which provides a GCC compiler for Windows development. I can now use the same tool chain for my embedded and host code which is great. I must say the makefile build environment is a bit difficult to learn but once mastered it gives you tremendous control over your projects.

The GNU compiler collection is perhaps the best feature of my tool chain. GCC supports a variety of processor families including ARM, AVR, x86 and many more. This broad range of support allows me to use a common compiler no matter which part I choose. Of course this keeps me from using PICs and Cypress parts but the advantage of a common compiler far out ways the disadvantage. I have also heard arguments about the GCC compilers efficiency at generating small and fast code. In my experience this not really an issue particularly as core speeds increase along with the Flash memory. Furthermore the continuous improvements of the GCC compiler have made this even less relevant. I have yet to be disappointed with GCC as a compiler.

As I have discussed in my blog there are huge complexities when starting out with embedded coding on a bare metal interface; resource are limited and the 1000+ page chip documents are daunting. For my purposes I want a USB interface and CDC library as a minimum development interface because it speeds up my project development. When I select a new processor my first coding task is getting the USB interface to work. Some of the advantages USB provides include providing power to my target processor, providing a CDC debug class allows me to easily send messages to a host computer. The CDC device class is an extension of the serial port as far as the host is concerned so writing host applications becomes easier. Serial host drivers are well documented and available on virtually all host computers. The final advantage of the USB interface is that it allows for device upgrades over USB without requiring any additional programming hardware. USB boot loaders are typically 10 times faster than their serial counterparts.

Code development for me is like building a pyramid. I start by laying down the foundation which I then build on to complete a particular project. I find that there are a bewildering number of partial solutions out there just waiting to be developed a bit further. Most code on the internet is not portable an is instead purpose build. The second issue is there is a huge lack of documentation and examples of how to use the code. Add licensing into that and you are left with a wild west of code fragments.

In my Utopian view of embedded programming there would be a wealth of well documented ‘C’ code libraries that are available as open source. Code that could easily be ported to any processor and was licensed as GPL code. I find it very frustrating that the large chip vendors release base level examples that are half baked and have closed licenses. It’s obscene since most of these vendors rely heavily on GPL code to support their parts. The reality is that there is little proprietary material in in any of the base building blocks like GPIO, I2C, UARTS, USB, LCD, FAT32, SPI, CapSense, Ethernet etc. Why not build on an open interface standard that is based on the best of what exists today. I’m thinking open source, documented and portable to as many architectures as possible. Oh, and don’t get me started about the craziness of standards companies that only allow the rich to be a member. Open standards means open to all without paying exorbitant royalties. The value add that can be had from supporting feature development based on a great set of libraries would seriously bootstrap developers just starting out. I am intrigued by the MicroBuilder project yet I think that there is an even larger community that would benefit by a true openness.

Testing: Testing consists of a loose test plan that follows the bootstrap approach. After visually inspecting a newly built board I apply power (the smoke test) and expect that the green power LED will come on; anything less is a serious problem which is typically attributed to a short circuit. If the power is OK I should be greeted by the chime sound of the host computer enumerating the newly installed USB device. This could fail for a number of reasons and is usually a problem with the microprocessor not coming out of reset, not having a functioning clock or having the wrong termination resistors installed. Once I get to this point I can start Flashing test code onto the device which allows me to use a terminal interface to display messages. In short the debug process is one of divide and conquer. Each layer of working circuitry lets me move on to the next. Don’t make the mistake of testing features when the underpinnings are flaky because it just causes grief.

Documentation: My errata list is derived from the entire process. I am careful to record any difficulties with the assembly process. Silk screen readability and solderability issues are note along with any pin-out problems. Next I record the errors found during testing as these will definitely need to be fixed if I ever re-work a board. Finally there are usability issues that only become clear once you’ve build a project. I find that after building and using a project there may be better solutions that I might want to explore. This is not so much an error as it is a learning experience. The whole experience of building a new board is about learning so; without closing the loop and documenting my findings I don’t feel the process is complete.

Finally there is the boring process of documenting what I have done and learned. I don’t actually find it boring. For me the blog is my lab book written for public consumption. In fact I write all of my notes with pen and paper at a coffee shop. This allows me to formulate a moderately readable blog entry. After writing these notes, when I’m bored I type up the notes in Word and review them until I’m happy with the message. Finally I copy the Word text to WordPress and publish the results. You may wonder why I make the process so complex. I don’t see it that way; I see it as my work process where I develop thoughts on paper as they evolve. These ideas start out unformed and wouldn’t be very readable without some time for the ideas to gel and the ink to dry.


Leave a Reply

Your email address will not be published. Required fields are marked *