Author Archives: ericgu
Here’s a video of the completed project. The video is from my Canon G3, so the quality isn’t very good. For sake of comparison, the blue and red globes in the video are 50 watts each, while each LED is only 350mW. The LEDs a bit brighter than they appear because the video is about 20 degrees off-axis.
My second animated display. This one has 16 channels and runs using a Motorola 68HC11 microcontroller. In the background you can see the house outline lights, which are a four-color dimming system also based on a 68HC11
The last few days have been fairly hectic. I wanted to get “Ring of Fire” into a demo-able state (to take into work on Friday), so that it could go up today.
First up was building the project board. As I mentioned before, the LEDs pull 70mA, so I need a separate transistor to drive them, as the AVR can’t handle the current requirements. The switch uses a 2n3904 NPN transistor, a 10K base resistor, and a 100K resistor between the emitter and base. And finally, an 42 ohm current-limiting resistor in line with the LED, in between the collector and 5V. That’s 16 transitors and 48 resistors, and after about 5 minutes, it was clear that that wasn’t going to fit on the board. I decided to put the current-limiting resistor next to the LEDs, and could barely fit the other components on the board. Here’s a picture of the board:
Yep, that’s a whole bunch of wires.
Next up was finishing the LED wiring. One of my bike wheels is built with 16 spokes, so I used it to mark the location the LEDs. Then I spent about 4 hours mounting the LEDs onto the ring. Here’s a picture of a mounted LED:
The black wire is the 5V bus, and continues all the way around the ring. The yellow part is a 42 ohm resistor attached to the ground side of the LED, which is then attached to a red wire that runs all the way back to the controller. The LED is then attached to the ring with hot glue. Here’s what the completed ring looks like.
That completed, I turned back to the software.
Problems that I hit along the way:
Originally, I was going to put ping-pong balls on the LEDs to diffuse the light, but it turned out that the LEDs have a fairly wide viewing angle, so the diffuser wasn’t needed.
So, the project is done, up and the tree looks pretty nice.
After firming up the animations that I wanted to do, I got two things accomplished in the last few days.
First, I build the “ring” part. I had bought a 5′ piece of pvc electrical conduit to use as a form, and my plan was to bend it into a circle by heating it with a heat gun.
Initial results were disappointing. The circle that I got was about as circular as the ones I drew when I was in kindergarten, so I decided I needed a form.
And there, sitting in a box because of my laziness at not putting them away, was a set of spare wheels for my bicycle. A little experimentation showed me three things:
A quick trip to Lowes and another 30 minutes with the heat gun, and I had a nice hoop (size 700c) completed.
Firmware
After digging out my development board (I use the Atmel STK500) and buying a copy of the CodeWarrior AVR C compiler, I was ready to get started. Well, not quite – I had to set up my work area since we’re getting ready to gut and redo our office. My main tools are:
I don’t really need the power supply as I’m using a wall wart to power the development board, but it looks nice under the scope. The multimeter is useful to look at LED currents, and because I’m using PWM to control the brightness of the LEDs, the scope is invaluable for debugging. If you don’t want a full-sized scope, there are some decent PC-based solutions, but keep in mind that the precision electronics required for ‘scopes are never cheap. I like having the real buttons and knobs rather than having to use a UI on the laptop to do things, though I would really like a TDS1000B.
<aside>
I’ve often advocated that developers should learn multiple languages because knowing languages effects how you approach problems. If you are fluent in Perl, you’re much more likely to know when to use a nice regex in C#.
Similarly, it’s good for your skills to spend some time working on a seriously constrained machine like a microcontroller. The 861 I’m using has a whopping 512 *bytes* of memory, which sounds pretty tiny until you note that the 261 only has 128, and some of the 8-pin versions only have 64 bytes. Trying to structure your algorithms and code to use that amount of memory and the 8K of flash for the program memory will stretch your mind in ways that writing C# code won’t.
I’m undecided on the benefits of writing in assembler. I can be a learning experience, but I’m not sure if the pain of remembering how indexed address mode works transfers over to more rational languages.
</aside>
My first order of business was to get the chip in the board, make sure I could burn it, and get a skeleton program running. Getting the chip on the board was trivial, but I had real problems getting it to program (which is done with a PC program that sends the code over a serial cable to the board). After a lot of trial and error – mostly error – a kind soul on avrfreaks.net pointed out that the connections on the STK500 were wrong for my chip, and things started working correctly then.
Codewarrior is a nice product. Microcontrollers require a lot of configuration up front – you need to set how you are using each of the pins, what interrupts you want, and 35 other things. You do this by writing code that stuffs particular values in specific registers on the chips. Something like:
TCCRO0A=0x09
Where you found that by careful reading of the 227 page user’s guide for the chip. It’s pretty tedious, but CodeWarrior provides a “get started wizard” where you specify what chip you’re using and then go through a dialog and choose what options you want and then it generates all the initialization code that is needed for your chip. It’s a huge timesaver.
After tracking down one problem that was keeping my interrupts from firing (traced to missing a bit in one of the interrupt configuration registers), my main loop woke up and started operating. I did a bit more debugging and then ported one of my animations over from C# to C.
It looked okay on the scope (minus a few glitches), but it seemed slow. Plugging in the leds on the STK500 to 8 of the output bits I’m using showed that a) the animation was working, but very slowly and ii) the LEDs were flickering like nobody’s business.
As I suspectected, the 861 running at 8 MHz doesn’t have enough horsepower to handle 256 levels of dimming. I’m not getting the 100 Hz that I need to keep the leds from flickering, and there’s not enough free time after the interrupts to do the animation at any reasonable speed.
I’ll spend a little time seeing if I can’t speed up the interrupt routine, but the real fix is going to be to reduce the number of dimming levels down to 16, which should give me enough time for everything to run smoothly.
Then, it will be time to start attaching components to the ring
To make some progress before my parts arrive (they showed up yesterday), and to have a good way to test my animations, I decided to build a simulator.
The simulator is build in windows forms, and is intended to prototype both the approach I’m going to take in the real software. I’m also hoping I can steal code, as the real software is going to be built in C this time, rather than directly in assembler.
To build the simulator, I had to decide how I was going to encode the animations, and how the main loop would work.
Because of time constraints, my plan was to build this as a sequencing system rather than something involving dimming. So, I coded up a very simple scheme of encoding the output in 3 bytes:
Count byte first 8 lights second 8 lights
Where the light bytes tell you what lights are on, and the count byte tells you how long to stay in that state.
I then tried to write a “lights go around in a circle animation”. The table looks roughly like this:
0x08, 0x80, 0x00
0x08, 0x40, 0x00
0x08, 0x20, 0x00
…
0x08, 0x00, 0x01
So that’s 16 lines of entries, taking up 48 bytes for a very simple animation, with me doing a lot of bitwise math in my head.
I then decided to do a more complex animation – there’s one light on at the bottom, the other lights circle around, and give a whack to the fixed one, which starts moving. So, in essence, a fixed spot moves backwards as the main animation goes forwards.
A full cycle of that involves 16 full circle cycles, or 768 bytes. Each of which had to be hand-figured out, basically by overlaying a fixed mask on top of the moving circle animation. I got through two cycles through a lot of debugging and testing, and decided I’d had enough. It was like programming a system without any looping constructs.
So, I decided to abandon the table-based approach to take a programmatic approach. Well, strictly-speaking, it’s a hybrid approach, where the animation is controlled programatically, but the low-level stuff is handled on an interrupt.
I also decided to incorporate dimming, since I really wanted to. So, here’s the design.
Interrupt Handler
The interrupt handler executes N times for each cycle (arbitrarily set to around 1/100th of a second to avoid flickering), where N is the number of dim levels I want to support. Consider N to be 64 for sake of argument.
PWM Cycle
The lowest level operation is to implement the PWM loop. Each time the interrupt fires, a byte counter is incremented, and compared to the dim level array elements (one per led), and the output bit is cleared if the counter is greater than the dim level for that light.
So, we have this array of lights all turned on, each with a number saying how bright it is, and as the PWM cycle continues, lights get turned off as their dim level is reached. Those with a low dim level are turned off early, those with a high level are turned off later.
The current levels are stored in a
byte current[16];
When a PWM cycle is finished, we reset all the outputs to high and the counter to zero, and then move to the animation cycle to see what to do next…
Animation Cycle
The animation cycle implements changes to the current array values over time. This is done through a delta vector and a count. Basically, we have:
byte delta[16];
byte deltaCount;
and every time we go through the animation cycle (ie each time a PWM cycle finishes), we add the elements of delta to current, and decrement the deltaCount.
So, if current[0] was 63 (ie full on), and we want to dim it to zero and turn current[1] full one, we would set up the following:
delta[0] = 255;
delta[1] = 1;
deltaCount = 63;
The first time through the cycle, current[0] = 63 + 255 => 62, and current[0] = 0 + 1 => 1. We’re just adding 1 to current[1] 63 times, and subtracting 1 (by adding 255 to it) from current[0] 63 times.
If we didn’t want dimming, we could also encode this as:
delta[0] = 193; // 256 – 63
delta[1] = 63;
deltaCount = 1;
That would flip from one light to the next in a single cycle.
Note that we can achieve a hold by clearing the delta array and setting deltaCount to whatever delay we want, which leaves current[] unchanged for that period.
After the animation cycle has completed, we need to get the delta[] and count values for the next cycle. We do this by copying from deltaNext[] to delta[] and from deltaCountNext to deltaCount, and then setting deltaCount to zero. That gives us the delta set, and we continue as before.
That’s all for the interrupt routine, but it rather begs the question – where did the values in deltaNext[] and deltaCountNext get set?
Main animation loop
In previous incarnations, the main animation was just handled in the same section of code as everything else – when the animation cycle ended, you’d figure out what you needed next (well, actually, you did it right before you needed it).
This has two whopping disadvantages.
The first is that you have to do it in the spare time between cycles. That’s not bad if you are doing simple animation (ie not dimming) or you’re doing dimming in hardware (which I’m not), but in this case there may not be enough time to do the main animation loop in the time left for an interrupt (at 64 dimming levels, about 156 microseconds for everything, including the interrupt routine).
The second is that you have to write the animation as a state machine – for any given set of counters, you need to know what the next delta[] should be. That’s not going to be much fun for more complex animations.
I therefore decided to let the main animation loop run in the main execution thread (well, there is only one thread, which the interupt preempts as needed). It therefore has the full animation cycle to come up with the next set of values (though, if the count=1, that’s the same as the PWM cycle), or 10 mS, and there should be enough time leftover to do the work I need to.
The main loop will use a blocking function to tell it when it needs to proceed. It’s:
void SpinWait()
{
while (deltaCountNext != 0)
{
}
}
So, we’ll just hang in that tight loop. An interrupt will come along, do what it needs to do, and if it’s at the appropriate point, deltaCountNext will be set to zero and when the interrupt returns, we can go on to generate the next values.
That allows the animation to be coded as something like:
SpinWait()
deltaNext[0] = 255;
deltaNext[1] = 1;
deltaCountNext = 63;
SpinWait()
deltaNext[1] = 255;
deltaNext[2] = 1;
deltaCountNext = 63;
which is a whole lot easier to understand, and you can even use this thing called a “loop” so that it’s easy to write. The simplification is roughtly analogous to how it is easier to write an enumerator using yield than the old way.
Back to the Simulator
The simulator implements this by having a timer fire off every 10 mS, and it calls into the interrupt code (which does everything except the PWM loop). The main loop runs in a separate thread, and everything is peachy.
That’s all for now. I think my next task is to write a few more simulations to make sure the code does anything, and then move the code to the microcontroller, hook up a scope, and see what I get.
No, not that…
Some of you may know of my devotion to holiday lighting, and I’ve been spending a few months thinking about this year’s display. Last year’s windstorm did a number on a few of the displays, but most were fixable (the spiral tree that took flight was not…).
I wanted to build something new, something different. I settled on using an Atmel AVR as the microcontroller, and LEDs as my light source. I considered a lot of different designs, but procrastination and my unexpected encounter with the pavement have left me with less time and unable to do any heavy fabrication, so things had to be simplified.
In the front of our house, we have a tall tree (30+ feet (2.34 hectares)) that I believe is of the Norway Spruce variety. Last year is was decorated with a number of the 50-light globes, and a big white 200 light globe for the top. I lost about half the 50 light globes and the 200 light globe only has about 20 working, so I’ve decided that the replacement top ornament will be a ring perhaps 18 inches (1.66 decalitres) across with 16 red leds distributed evenly around the ring. It’s 16 because I think that’s a nice number, and it lets me use a simpler microcontroller since I only need to control 16 outputs. And using LEDs will mean that I don’t have to use solid state relays, which are a bit pricey…
Hence “ring of fire”
Here’s the part slist:
I chose the 861 mostly because it had 16 pins, and at $3, what’s not to like?
The LEDs are designed for sign and signal applications. They run at 70mA rather than the 20mA most LEDs use, and they have a wide viewing angle (ie the light is spread out rather than going straight ahead). The 43 ohm resistors will go in series with the leds to get that 70mA at 2V on the LEDs from the 5V power supply.
The transistors and 10K/100K will be used to switch the LEDs off and on. The AVR can sink 20mA of current, which is a fair amount, but not enough for the LEDs, and even at 20mA it couldn’t drive them all at once.
I think I have a 5V power supply that will work. The LEDs pull 2.24 watts when they are all on, but unfortunately at 5V the 42 ohm resistors will pull 3.36 watts, which puts me up near 6 watts. If I drop down to 3.3V, 20 ohm resistors would give me 65 mA, and that would mean 2.08 watts for the LEDs but only 1.35 watts for the resistors, so I could get by with a 4 watt supply.
The AVR will run on anything from 1.8V to 5.5 V, though it won’t be quite as fast at the lower voltages.
Software is in two stages.
The first stage will be a simple table-based animation system. I’ve built it a few times before, and last night I built a simple simulator in winforms. That will get it up and running.
The second stage will be to add dimming to all the LEDs. That requires doing PWM on every channel, and I’m not sure that there is enough horsepower to do that in the AVR.
To do flicker-free dimming will require an update frequency of around 100Hz – the dimmest setting would have a brief spike of “on” every 10 mS. That period would need to be divided by the number of light levels – to do 256 would mean that the code would have to update the output state about every 40 microseconds. That’s roughly every 750 clock cycles at 20MHz, which seems possible but difficult.
On the other hand, 64 levels would increase that to 3000 clocks, and 16 levels to 12000 clocks, so it looks like some sort of dimming is doable. It helps that the table-driven code doesn’t use a lot of resources.
All my previous projects have been written in assembler, but I’ve decided to use CodeVisionAVR as the development environment, which gets me a C compiler and IDE.
I’ll post other updates as things progress…
There was a post on an internal alias about moving a team that has not been creating any developer-written tests to one that does TDD. I wrote a reply that I think may be of more general interest…
Developers are fluent in code. I think any time you are talking to developers about engineering practices, you need to be showing them code. I think showing TDD workflow is very important. I also have stopped using the term “Unit test” as it means 45 different things before 10am.
I’m a big fan of selling the problem rather than the solution. Here are some problems that I think resonate with the developers I know:
Time Savings
Nearly every group with existing code has a section of code that either is or has been a bug factory, and most developers can make a decent estimate of what parts of new code are “tricky”. If you use TDD (or just write tests for) that set of code, you can save yourself a huge amount of time debugging. You can also factor in the difficulty of debugging certain parts of code – there is a big benefit there.
Flexiblity
People also tend to own code that a) needs changes and b) is brittle and c) nobody understands any more, and everybody knows how much of a pain that is.
Freedom to focus on new stuff
All devs like to work on new stuff rather than fixing old bugs. If you have good tests along the way, you won’t have to be dragged away from the new stuff to fix the old stuff as often.
Pride
Everybody likes to write code that works well, nobody likes to own the bug factory. In fact, I think people leave groups to get away from something they know is a bug factory but nobody else does.
Permission
Group dynamics often push devs toward meeting a team’s definition of code complete rather than spending the time writing tests. Now, I happen to think that TDD often gets you to code complete sooner (in a tradition milestone approach), but if you’re just learning it, that isn’t the case. You need an explicit declaration that it’s okay to be spending the time writing the tests
Tests as examples
If you are creating a component that is consumed by somebody else, you can save a bunch of your time by having unit tests. Not only do you spend less time responding to email and doing bugfixes, the tests often provide very nice examples of how to use your component.
You may not that I don’t list “Design by example” there at all. I think that design by example is a much better way to create software, but it’s an experiential thing rather than something you can put on a powerpoint deck.
Hope that helps.
One of my readers asked whether there were any UI unit testing tools.
While I have seen some ASP.net tools like this, in general I’d expect that you would unit test a UI by making the UI a very thin layer (one that doesn’t really need testing), and writing the unit tests to talk to the layer underneath.
Though I haven’t had the opportunity to try it on a full project, I think that Presenter First has a lot going for it.
O’reilly publishes Beautiful Code
Jonathan Edwards counters with a beautiful explanation.
Now, I haven’t read the new book, but I have a strong resonance with what Edwards wrote. You should definitely read the whole thing, but I few sentences jumped out at me.
A lesson I have learned the hard way is that we aren’t smart enough. Even the most brilliant programmers routinely make stupid mistakes. Not just typos, but basic design errors that back the code into a corner, and in retrospect should have been obvious.
and
It seems that infatuation with a design inevitably leads to heartbreak, as overlooked ugly realities intrude.
Precisely.
If there’s anything that agile says, it says that we should build things simply and with a eye to revision because we not only are we “just not smart enough”, there are too many unknowns when we start.
The problem with “beautiful code” as a concept is that it is closely related to “beautiful design”, and I’ve mostly come to the conclusion that any design effort that takes more than, say, 30 minutes is a waste of time.
The concept also gets confused about what the goal of software is anyway. The goal is not to have beautiful, elegant, code. The goal is to have *useful* code that does what you need it to do.
Discuss and comment
Thanks for your comments.
I decided to go ahead and write the unit tests for that layer, both because I knew what not writing them would be like, and I wanted to play with wrapping/mocking a system service.
I also decided – as some of you commented – to do the right thing and encapsulate it into a class. That would have happened long ago, but though I’ve written it several times, I don’t think I’ve ever duplicated it within a single codebase – and the codebases where I did write it are pretty disparate. Now, I have something where I could at least move the source file around…
Writing tests for this was a bit weird, because in some sense what I needed to do was figure out what the system behavior was, break that down, write a test against my objects, and then write mocks that allowed me to simulate the underlying behavior.
So, for example, I created a test to enumerate a single file in a single directory, wrote a wrapper around DirectoryInfo, and then created a mock on that object so I could write GetFiles() to pass back what I wanted. And so on with multiple files, sub-directories, etc.
So, I did that, went to write the little bit of code that I needed in the real version (to use the real GetFiles() calls and package the data up), hooked it up to my real code, and it worked.
*But*, when I went back and looked at the code, I found that what I had really done was create two sets of code. There was the real code that called the system routines and shuffled the data into my wrapped classes. And then there was my mock code that let me control what files and directories got returned. But there wasn’t any common code that was shared.
So, my conclusion is that I really didn’t get anything out of the tests I wrote, because the tests only tested the mocks that I wrote rather than the real code, because the only real code was the code that called the system functions.
In this case, TDD didn’t make sense, and I will probably pull those tests out of the system.TDD may make sense the next level up, where I’ve written a new encapsulation around directory traversal, but it seems like the only code there is hookup code.
So, the result of my experiement was that, in this case, writing the tests was the wrong thing to do.
Recent Comments