Embedded design flow

Question

Sometimes I get unmotivated to finish my personal projects because of a lack of plan on what to do next--should I design a board first, hook up a test circuit, write test code or write design requirements? Are there any formal design flows maybe specific to embedded hardware that I could follow to make sure I don't miss anything and waste time re-doing things.

Answer 1

I don't know of a definite design flow, but I'll tell you what works for me:

First you obviously have to do general system design. Write out something that says what you want your widget to do in general and make a block diagram. This lets you get on to the next step of selecting a processor and choosing parts. After that it's time to play around with the parts and see how they work (if you've never used them before). For analog parts I'll stick them on a breadboard and see how they look on a scope - how much bounce is in the switches, how fast do things change, what voltages will be produced, etc. Then it's a good idea to hook everything up to your microcontroller in some way. This will tell you 1) whether hooking it up to the microcontroller changes the characteristics of the part. Then I'll write up some dummy code on the microcontroller to see how it interacts with the part and what kind of data I can expect.

For digital parts I prefer to use a logic analyzer/pattern generator or a bus pirate and get the hang of the device first before attempting to interface it to the microcontroller. This lets you figure out important things like what buad rate to use as well as what sequence of commands are necessary to make it behave the way you want.

For any complicated algorithms or library functions I always create a unit test and test it on my desktop computer before attempting to put it into the microcontroller. I've created circular buffers, packet finders, DIO functions etc this way and it's a dream. Write a function's test a little, write the function a little. Think up new functions and tests as you go. Add tests from real-world scenarios you've found (ie, junk at the beginning of a bytestream trying to find a packet, misplaced END, etc). When you're sure that it works well enough compile it into a library and copy the header and library file to the appropriate places for your microcontroller compiler. I have a makefile that compiles all of my code to libraries for PSOC and AVR and then copies them to the correct folders so I can use them.

Before you start to bring it all together I find it helpful to write out a test plan. Start with the most optimistic scenario ("I hook everything up and it works immediately.") and then go into 'what-ifs'. What if there's no serial communication? Have test points to probe, use bus pirate to drive the port to see if it's working, place breakpoints in the UART interrupt handlers, etc. Always keep asking - What if that doesn't work? How do I test it?

Then you start to bring it all together. You know what analog support hardware you'll need to interface everything and you have all of the background code you want to use. At this point I'll probably make a board for the project (I hate doing detailed work on a breadboard - one wire goes and you've lost a half hour trying to put it back). Now you can start on your application code. When doing this I find it helpful to have a fallback mode. Sometimes you'll make three changes and everything stops working. It's useful to have an entirely separate main() function that only drives low-level things - ie, is my UART still working? Does this button work? Are all my lights hooked up? So when you change things and everything stops, you can add one #define in your code and change it to hardware test mode to make sure you didn't destroy everything.

Just keep developing and eventually you'll be done. This is the part I've never actually gotten to, so good luck if you do :)

Answer 2

I like to plan out (achievable) milestones from the beginning. Rather than always aiming for the end, you're just working on a few features for the next milestone.

Answer 3

I have tried a lot of different workflow stuff. It seems like the most helpful parts of any workflow scheme are specifications (what done looks like), Timelines(how to get to done) and Tasklists (what to do right now).

Really the first and last ones are the most important. You need to know what you want to make as precisely as you can. You also need to know what to do at a given time.