Serial Communication/Endianness Post

I just posted a new article to my Embeddedrelated.com blog about endianness and serial communication.  It discusses what endianness is and why it's important to serial communication. It also has a tutorial on transmitting data from a microcontroller to a PC an plotting it using Octave.  This is part of the data processing aspect of my stoplight costume.  I'm using Octave to develop DSP techniques to process the accelerometer data to determine whether or not the person wearing the costume is in motion - part of this is getting the data out of the microcontroller and on to the PC.  That's what the article discusses. When I start documenting the software aspects of the costume I'll write about the actual DSP techniques used to process the data, but for now you can read the article.

Redesign #1

Several things about the overall design and approach for my Halloween costume have been bothering me lately:

Accelerometer Woes

The MEMS accelerometer I'm using to detect motion is not well-suited to the task which I'm using it for. I've come to the conclusion that MEMS accelerometers don't so much measure acceleration as they simply register it.  Discerning what exactly is happening in the outside world from the output of the accelerometer is a bit of a dicey proposition.  Still, I have made significant progress on the issue thanks to an Electronics Stackexchange post by Olin Lathrop detailing a method to derive meaningful data from the cacophony a MEMS accelerometer produces.  Using his approach I've been able to process the data to identify what I will call 'motion events'.  It can't tell you how fast you're currently going, but it can pretty well determine if you've started to move from a stand-still.  This is all the information I need from the accelerometer.  Despite this success, the methods used to process the data will probably introduce significant delay when detecting these events - possibly on the order of 1 or 2 seconds.  Still, it is just a Halloween costume so I'm going to try not to feel too bad about this.

Power Usage/Battery Life

The power usage of the board is still pretty poor - it will eat through a 9V battery pretty quickly.  A costume isn't going to be impressive if it runs out of juice in a few minutes.  To some extent there's just no way around this: LEDs are power-hungry.  If I want any significant amount of light they have to draw 10-20mA each.  Multiply that by 30 LEDs and that's a lot of power.  Of course, they don't have to be that bright all the time. I built PWM into the design so that they could be dimmed when necessary - that's worth a bit of extra power.  I will also get some gains my simplifying my power architecture as I mentioned in a previous post and I can also use low-power modes on the microcontroller and modify my design to allow the accelerometer to sleep when it's not used.  I'll also be adding a battery monitor circuit so the microcontroller can read the current state of the battery and act accordingly (although I don't know yet what actions it might take). These fixes don't matter nearly as much as the LEDs though, which leads me into my next point...

LED Driving

My first instinct for driving LEDs was to use a linear approach and control the brightness with PWM.  The reason for this was that it was simple and straightforward.  It's also not the most efficient approach: a fair amount of power is dissipated in the biasing resistor.  That's wasted power - it makes no light.  This can be avoided by driving the LEDs with current instead of voltage.  The benefit of this approach is that very little power is wasted: most of it is dissipated in the LEDs which is exactly where you want it.  For best efficiency a switch-mode current driver should be used.  There are many off-the-shelf ICs that can be used for this purpose but to minimize costs and maximize board space you can build your own switcher out of discrete components.  In this case, it's worthwhile to use the ULN2803 as the switching element and the microcontroller to generate the PWM.  The ULN2803 is designed to switch inductive loads and has most of the protection circuitry necessary.  It would be nice to have some sort of current-sensing ability but this difficult to implement and isn't strictly necessary - the current system doesn't use any feedback and it doesn't suffer. A full description of the switching circuit can wait for another day but it's wortwhile to note that this circuit doesn't have to be on the main microcontroller board: most of the components can be located on the LED boards.  This allows the microcontroller board to drive LEDs either using a switch-mode current approach or in the current linear approach.  I prefer to let the microcontroller board be more versatile, so I think I'll modify the LED boards to use this new approach if it ever comes to it.  With only minor changes to the microcontroller board it will be able to support both approaches.

Accelerometer Interface

This has proved more complex than I first imagined.  Two main issues:

• Because they're not running on the same supply the microcontroller can't directly control the accelerometer pins.  This means I can't set its measurement range, run a self-test or put the accelerometer to sleep with the microcontroller: I have to use jumpers instead.
• I should have gotten an I2C accelerometer.  While analog measurements are fun, they're prone to noise and I have high-currents running around this board (more on that in a second).  It is possible to design the board such that the high-current paths and noise are isolated from the accelerometer signal path but if we're optimizing the signal path I vote for making it as short as possible by leaving it entirely inside the accelerometer. You can't get much shorter than that.

Noise

Noise has been a significant problem with this design.  The main issue is the high-current path used to drive the LEDs.  The first time I tried to drive the LEDs and read the accelerometer I was surprised: the accelerometer data was garbage.  The scope showed that there was so much noise on the accelerometer lines that they were worthless. Sure enough, turning off the LEDs made it all go away.  After examining my layout I wanted to kick myself even more: the power supply for the microcontroller is drawn from the same trace as the power supply for the LEDs.  The noise induced by the high-current PWM switching is not isolated from the microcontroller at all!  Part of the reason for this is that the layout is so crowded that I couldn't really do it any other way. Why is the layout so crowded?  Two reasons: 

1. It's a single-layer board so it was difficult just to get all the traces going to the right places. 
2. I used through-hole components which are large and bulky.  

I've been considering some approaches to minimize the noise but I don't think I will be able to remove it completely.  One approach I considered was to filter the PWM coming out of the microcontroller to provide a smooth control voltage to the ULN2803 rather than a jerky square wave.  One problem with this is that it will force the ULN2803 to work in linear mode rather than saturation mode - this will dissipate more power inside that IC and subsequently use up the battery quicker. That's not a tradeoff I'm willing to make right now, so I think I'm going to settle for a better layout and adding a large capacitor on the supply pins of the ULN2803.  This will have the effect of minimizing the length of the traces that have switched high-currents on them and also separate those traces from more sensitive areas of the board.

Final Word

There are thankfully a small number of fixes which can remedy most of the problems I've discussed here:

• Redesign the board and use all surface-mount components
• Replace the voltage-mode accelerometer with an I2C accelerometer
• Simplify the power architecture to power the LEDs from the battery directly and use a single switching 3.3V power supply to power the accelerometer and microcontroller
• Utilize low-power modes on the microcontroller and accelerometer to save power
• Physically separate the 3.3V and 9V portions of the board and place the ULN2803 much closer to the 9V battery.  Add a large capacitor on the supply pins of the ULN2803. 
• Modify the ULN2803 circuitry to support both the current LED driver approach and the switch-mode current driver approach

Looks like I'll have to redesign the board and possibly upgrade to a two-layer, professionally-made board.  More on this as I develop it.

Heartbeat LEDs

I've started blogging at Embeddedrelated.com, so go over there and check out my post on Heartbeat LEDs. It's a bit basic but you'd be surprised how often they come in handy and how rarely I see people actually use them.

Enjoy!

Oops

I messed up.

Oooh it hurts to say that but it's true. I should say it again.

I messed up.

Ah, still stings a bit.  Maybe it will get better if I explain just how I messed up.

My last post linked to my overview of design considerations in voltage regulator circuits.  In that writeup I staunchly defended the circuit I had designed to power my costume.  Here's the block diagram:

The general idea is that a 9V battery powers two separate voltage rails (5V and 3.3V) which are generated from linear voltage regulators.  The 5V rail powers the microcontroller and LEDs and the 3.3V rail powers the accelerometer.  Hopefully some of you will have raised your eyebrows at this point regarding my design and noticed a few things:

1. Two voltage rails?  That seems like needless complexity. Why not drive the microcontroller from 3.3V?
2. The microcontroller and accelerometer have different voltage sources.  Doesn't that make it difficult to interface them?
3. You're using linear voltage regulators in a battery-powered application?  Don't they waste a lot of power?  Isn't that bad for battery life?  
4. Why drive the LEDs from a regulator? Aren't they high current devices? Won't that force you to choose a more capable linear regulator and dissipate a lot more heat through the regulator?  
5. What's that cool graph paper you use?  It looks all retro engineering-y!

I pretended I had good answers to these questions.  There are two rails because I need the microcontroller to run on 5V because then it can use a 20MHz clock rate.  Don't you want that extra performance in case you need it?  You know... for the complex maths and large amounts of data this costume will be processing? And no, it isn't a problem to interface the microcontroller and accelerometer because it's an analog accelerometer, so the 3.3V levels it produces can be easily read by the A/D on the microcontroller no problem!  Yes, I know I don't get to use the full range of the A/D (0-5V) to read the accelerometer because they're using different operating voltages.  I could always connect the A/D reference to 3.3V and get that extra precision back.  No, I didn't actually do that and no I can't directly manipulate any of the control lines on the accelerometer to change the measurement range or put it to sleep.  I'm sure I'll never need to put it to sleep - this is a battery-powered application! How important could that be?

Linear regulators? They're fine!  I've been using them forever! Why change now?  My calculations indicate they're 80% efficient in this application!  Why add all of those extra components like inductors and zener diodes for a mere 16% more efficiency?  Oh, oops.  I guess I did my math wrong and the linear regulator is only 55% efficient.  But hey, 40% more efficiency that... that can't be... worthwhile, right?  In a battery-powered application?

But the LEDs - those need to be power from 5V!  The green LEDs have a forward voltage of 3V - way too close to the voltage rail to allow me to properly bias them. I think.  I didn't really check.  Wait, power them directly from the battery and avoid the voltage regulators?  I cant... I can't do that... because... because the battery voltage will decay as the battery drains!  They LEDs will get less bright as that happens if I drive them directly from the battery!  Of course, I am already using PWM to dim them, so as the battery dies I could increase the duty cycle to compensate.  But I can't do that because I didn't monitor the battery voltage on the microcontroller via the A/D.  Because... because...

Because I'm an idiot.  There I said it.  It hurts less now. Supposedly, scientists say that sometimes your brain subconsciously makes a decision and then only afterwards you consciously justify it. (I ate that pie.  All of it. Because I had low blood sugar. Yeah I did kinda feel grouchy...) That's exactly what happened here. I wanted to start making circuits, soldering things and etching boards so I decided first and thought later.  I pulled up an old circuit from my past, used it without thinking and paid the price for it.  While testing the board I was always checking the 5V regulator to make sure it wasn't getting hot.  I was tearing through 9V batteries during testing too (20 minutes of run-time?  That will be an impressive Halloween costume!).  I saw all the signs of a poor design but was able to justify them until I actually sat down and started writing an article about the decisions real engineers are supposed to make when designing circuits like this.  The article just wasn't coming together - I couldn't make all of the pieces fit.  Nothing seemed to make sense.  Because it didn't - I hadn't followed my own advice.

At big companies with complex, involved processes for running projects they love to collect Lessons Learned.  What did we do wrong on this project?  What can we do better in the future?  What worked? What didn't?  While most processes and 'learning experiences' like this at big companies seem useless and painful, Lessons Learned is one tool that you should utilize everywhere you work.  We're all imperfect and we all have a lot to learn.  We all need to own up to our mistakes so we can correct them and become better engineers.

This means sharing - a perhaps uncomfortable amount of sharing.  Honestly I can't say I'm comfortable admitting my mistake like this.  I knew switching regulators existed, I knew microcontrollers could run from 3.3V.  But I wasn't basing my design decisions on engineering - I was pretty much basing them on nostalgia (Ah, the LM7805!  Reminds me of my childhood!) and inertia.  This is a trap that all of us will run in to when we work on projects alone.  With no one to watch our back and call us out when we make terrible decisions we will create less awesome stuff.  Some of it will be downright embarrassing.  All of it we will want to hide.

If we want to be better engineers and make more awesome stuff we're going to have to venture way out of our comfort zone and share our mistakes.  Trust me, you haven't seen the last of mine.

Power Supply Design

I've started writing up the design of power supplies in my costume project.  When I say 'power supply' I don't mean anything as exotic as designing a linear regulator out of parts or designing a 300KV supply for a Tesla coil but instead a more pedestrian 'which chip do I pick and why?' sort of writeup.  There are an absurd number of potential voltage sources out there - more than enough to get confused.  The writeup focuses on the criteria you would use to select a voltage regulator and discusses the differences between linear and switching regulators before discussing the reasons for choosing regulator I did.  You can read it here.

Schematic Capture

I said that the next post I made would be about the LED driver circuit - right?  I honestly don't remember and refuse to read my old post.  It's like hearing your voice on a tape recorder - or voicemail I guess.  Tape recorders don't exist anymore. Anyhow that's not going to happen.  You'd think I would have learned by now that every time I say the next post is going to be about something I'm usually wrong.  I only do it to build suspense and try to get people to come back and read the next post.  Of course, this isn't worth much unless people read my blog to begin with - and unless I write a next post...

Instead I'm going to briefly discuss schematic capture and the schematic capture tool that I use.  Briefly put, schematic capture is the process where you generate a schematic diagram for an electrical circuit.  A schematic can serve several functions:

• Informational only - A schematic is informational only if you just need to draw a circuit to show someone.  You could do this with a 50K schematic capture tool, Visio or with a pen and paper.
• Layout - You may want to generate a PCB with your circuit on it at some point.  To do this you need a schematic capture tool that can integrate with a layout tool.  I'll discuss layout in a later blog post.
• Simulation - If you should need to determine how much power your amplifier is dissipating by simulating the circuit you'll need a schematic capture tool that interfaces with a circuit simulator like SPICE.

As you might image your choice of a schematic capture tool depends on which of these purposes you want to fulfill.  Generally the very expensive Electronic Design Automation (EDA) packages contain all of the above: schematic capture, simulation and layout.  You can do anything with them if you can afford them.  In case you can't there are many open-source alternatives which also might suit your needs depending on what they are.  If you want to start comparing schematic capture tools or even complete EDA suites some of the things you'll want to consider are these:

• Basic Functionality - Your schematic capture tool must be able to support the functionality necessary to do what you want with it.  For example, almost every schematic capture tool can be used to generate schematics for informational purposes but even this is not strictly true - some online circuit tools may not offer an export function. To support layout and simulation functionality it must be able to generate a netlist appropriate to the purpose you intend.  
• Compatibility - Following from the above, your schematic capture tool must be able to generate outputs that are compatible with other applications.  This may be something as simple as generating a graphic or PDF version of the schematic for publishing and complex as being able to generate a SPICE netlist and stimulus in the proper format for your simulation tool.  Ensure you know what types of outputs the other tools in your EDA toolset will accept.
• Availability of parts/libraries - The more pre-made parts that are made available with the schematic capture tool the quicker your design process will be.  If a wide variety of parts are not available you'll have to generate them yourself - this can be tedious to say the least. However take note: not all parts are the same.  Some part libraries are only for specific purposes such as simulation.  You can't use those parts to generate a netlist for a PCB program. Vice-versa, parts that can be used to generate layouts may have no simulation information associated with them. It is also generally helpful if the parts are popular and freely available from a variety of sources - parts you can't find or are too expensive aren't very worthwhile.
• Interface/Ease of Use - There are some very awful schematic capture tools out there.  I won't name names but when you use one of the bad ones it feels like the keyboard is made of needles. Don't tolerate poor software - there are very likely alternatives.
• Neat features - There are lots of features which are desirable to make your life easier:  Bill of Materials generation is good, Design Rule Checks can help out a lot, integration with source control systems may be worthwhile, etc.  While these features are fun and neat this bullet is at the bottom of the list for a reason: compatibility, library support and ease of use are definitely more important.

 There are many options out there and I've used a few.  Here's a few names you might recognize:

• Cadence OrCad/PSPICE - Known by many names, this professional suite of EDA programs that let you design electronics from step 0 to product.  It has everything: schematic capture, simulation, layout, a well-stocked component library and a huge price tag.  Seriously, it's tens of thousands of dollars.  This is only for colleges and businesses. While I used it in college and at some places I've worked I wouldn't use it for my personal projects.
• Multisim - National Instruments' answer to OrCad.  I have very little to say about it.  My university tried switching to it in my junior year and it really failed to impress anyone.  I assume it's also expensive but I've never bothered to check.
• gEDA - An open source suite of EDA tools that aims to be the free software EDA toolset.  I haven't used this one mostly because it's geared towards Unix/Linux and I use Windows.
• KiCad - Another open source suite of EDA tools.  I just haven't used this one.
• Eagle - An EDA suite that is something of a standard in Maker circles.  Everyone tends to use it or release libraries for it. Do you have a part from Sparkfun or LadyAda?  They've released an Eagle library with that part.  I also do not use this - mostly because the free version is restricted and it's not open source (although they have opened up their file formats).

If you want to peruse even more open source/free options take a look at this page for a listing of many open source EDA tools of all kinds (schematic capture, simulation, layout, VHDL authoring, etc.).  I've settled on a suite of tools that works well for me.  Eventually I will document all of them but for today I'll focus on my schematic capture software: TinyCAD.

TinyCAD is a Windows-based open-source schematic capture tool.  While it doesn't come as part of a complete EDA toolset it is able to integrate with a wide variety of other EDA tools.  It doesn't, for example, allow you to simulate circuits but instead allows you to export a SPICE netlist that any SPICE compatible simulation tool (which is the vast majority of them) can accept and work with.  It doesn't have its own layout tool but it can easily export netlists compatible with a wide variety of available layout tools: Protel, Eagle, gEDA and PADS. It can also generate PNG graphics of its schematics for sharing. These options give me the basic functionality and compatibility that I need.

As far as available libraries go it doesn't have quite the number of libraries and parts that Eagle has and is certainly nowhere close to professional-level tools like OrCAD.  I don't view this as a large issue because I've found that no matter how much library support your schematic capture tool claims to have it never has the one part you really need.  If you don't get familiar and comfortable with making your own parts and libraries you'll never go very far making things.  TinyCAD has a good interface for making new parts and since everything is XML-based I could probably even whip up a script to generate rudimentary schematic symbols from information in the datasheet to save me time. There are also efforts out there to develop better libraries that incorporate more commonly-used parts and integrate with SPICE and layout tools.

TinyCAD's interface is not fancy and modern but is straightforward and easy to use.  The only feature I've never quite gotten the hang of is the busses but I'll learn someday. I've never felt confused or angry (well, any more angry than usual) when using TinyCAD.  The workflow lets me quickly capture schematics without issue.  You can't give a schematic capture tool a better compliment than that.

TinyCAD has many neat features that keep me coming back.  The open nature of the libraries, parts and schematics means I can create scripts to manipulate all of my design files to automate my work flow.  It can export a parts list/bill of materials for a design.  It offers a design rule check to make sure you don't connect two outputs and unlike other design rule checks this one has proved useful to me. It allows you to create hierarchical parts - you can create a 5V regulator circuit, save it as a hierarchical part and drop it as a block into any new design you want.  TinyCAD is currently under development and not abandoned like some open source proejcts.  Despite the fact that development has slowed down there is a bug list and feature request list on Sourceforge that is steadily being worked at.  And of course since it is open source you can add in your own efforts at any time. There is also a large busy users' group on Yahoo which can help to answer all of your questions.

If you want to be like me and use TinyCAD I've documented the process of installing, downloading libraries, creating libraries, creating your first part and your first circuit.  Find it here.  The next tool I'll document is the layout tool I use: FreePCB.  But before that I'll discuss a few of the circuits I've created for the costume and some of the lessons I've learned in the process.

Until next time!

Github Repo Up!

I put all of the costume project files up on Github here: https://github.com/angryee/light-costume

There's not much explanation there yet but there is a wiki article on Github detailing what most of the files/directories are - see it here: https://github.com/angryee/light-costume/wiki/Directory-Structure

Take note everyone:  open source or open design files by themselves are useless. There's so much information in any given project that at first glance to anyone it's all useless gibberish.  Unless you take the time to thoroughly document the files, tools, directory structure, design decisions and other minutiae it really doesn't matter if you release your code into the wild and promise not to sue - if it's not well documented no one can use it or learn from it.  It just makes you sick trying to figure it out.

It makes me sick just looking at it and thinking how much documentation work I have to do.  I'm going to bed.