Eric’s Code Shack

Came across a post by Justin Etheredge discussion whether changing between languages is just a matter of syntax.

Or, to pick a specific example, can a Java programmer quickly and easily learn to write C# code?

The answer is obviously “yes”. Development is about a way of thinking and approaching problems, and given the similarity between Java and C#, a good Java developer should take a minimal amount of time to learn how to write functional code in C#. The biggest barrier is libraries, which are more different than the languages are.

The answer is equally as obviously “no”. Sure, you can write functional code, but you will not be able to write idiomatic code. Like a high school senior with 4 years of French class on a trip to Paris, you can make yourself understood, but you aren’t going to be mistaken as a native. You ask a question, somebody replies, “Ce ne sont pas vos oignons”, and you just end thinking of soup.

So, yeah, you can write C# code, but it’s going to be Java written in C#. Given the closeness of the languages, it may be sufficient, but you’re going to force some refactoring on any idiomatic C# speakers who inherit your code.

It can be worse – when I first started writing in Perl, I wrote C code in Perl, which just doesn’t work very well. And over time, I became at least functional, though perhaps not idiomatic in Perl (though, because of TMTOWTDI, it’s hard to judge that in Perl).

However, if you can become idiomatic in multiple languages, your toolset broadens, and you become more useful in all your langauges.

Today, I took a break in the snow and finished the installation of the new light display. It’s functional, except for one light that isn’t working.  I’ve been extra busy this year, so while the main displays are up, there aren’t as many additional lights as I would like to have.

Our recent snowstorm has changed the look quite a bit – normally you only get a little light from the streetlight on the left, but now there’s a ton.

On the left, there are 8 strings of multipcolored LEDs in a circle around the light pole. To the right in front of the truck are some other lights. Hiding behind the truck is the first animated display, the “tree of lights”. The big tree (about 40′ tall) has red leds around the trunk, and features to animated displays. At the top is the second animated display, the “ring of fire”, arrayed on the tree is the new display. To the right you can see the original animated display, santa in the sleigh and on the roof. Finally, outlining the house is a red/green/blue/white string, the last animated display.

Tree of Lights

16 channel sequenced controller, about 1500 lights total. From base of tree to top is about 14′.

The controller is 68HC11 based.

Ring of Fire

Ring of Fire is 16 high-output red LEDs driven by a custom 16 channel controller, supporting 16 dim levels per LED.

The controller is Atmel AVR based.

I wrote a fair bit about it last year.

Santa

The display that started it all. It animates as follows:

1. Blue lights in foreground strobe towards santa.
2. Reindeer, sleigh, and santa appear.
3. Santa leaves sleight and hops up on the roof edge.
4. Santa goes up to the peak near the chimney.
5. Santa disappears, and then his hat disappears soon after.

Then the whole things reverses itself.

The display itself is painted plywood, with about 800 lights in total. After 12 years the lights had gotten a bit dim, so this year we replaced all of them. The santa at the top of the roof is usually a it more distinct, but he has a big snow beard this year.

The controller is based on the Motorola 68HC11, running 8 channels.

House Lights

The house lights are 4 individual strands in red, green, blue, and white, with a 4-channel controller that dims between the colors. So, the house changes between colors.

The controller is based on the Motorola 68HC11, with 4 channels, this time dimmable.

Tree Lights

The tree lights are the new display for this year.

These are jumbo lights lit up with C7 (7 watt) bulbs inside of of a colored plastic housing. They really don’t show up that well in the picture because of all the light coming off the snow, but even so, I think I will likely need to upgrade the bulbs in them to something brighter (say, in the 25 watt range). And I think I will go with clear bulbs – having both colored bulbs and colored lenses works well for yellow and orange but the blues and greens are really dark.

The controller can support up to about 100 watts per channel, though I’m not sure my power budget can support it.

The controller is Atmel AVR based (my new platform of choice), and the code is written in C. There are 15 channels, and each of them has 32 dimming levels.

You can find a lot more boring info here.

A trip through the new project in pictures:

I was late in getting started on the project due to putting finished touches on the office, but I ended up with this wonderful new workbench. Quite the step up from the old door on top of shelf units that I’ve used for the last 35 years or so (really).

Left to right, we have the Tektronix dual-channel 20MHz oscilloscope (thank you eBay), a bench power supply, a perfboard with sockets on it in front of my venerable blue toolbox (also 35+ years old), a outlet strip with a power supply plugged into it, a perfboard, a STK500 microcontroller programmer, a weller soldering staioin, and a fluke voltmeter.

This the project in its first working version. On the far left partially clipped is the power supply. The upper-left part of the prototype board (the white part) has the zero crossing circuit, and the upper-right has a solid-state relay. A brown wire takes the zero-crossing signal to the microcontroller on the development board, and a brown wire takes the signal back to the relay. The Atmel AVR microcontroller that I use comes in a lot of different sizes, so the development board has any different sockets to support the. On the far-right is a white serial line which leads to my laptop – the AVR is programmed over a serial link.

Back to the zero-crossing circuit. To switch AC power, you use a semiconductor device known as a triac. The triac has a weird characteristic – once you turn it on, it stays on until the voltage goes back to zero. That happens 120 times per second, so to implement diming you need to control when you turn on the power for for each half-cycle.

Here’s a picture that should make it easier to understand.

The wavy part is the AC sine wave, and the nice square pulse is the zero-crossing signal, which goes high whenever the AC voltage is low enough. The microcontroller gets interrupted when the zero-crossing signal goes high, and then waits a little time until just after the real zero crossing happens.

If it turned the output right at that point, it would stay on for the whole half-cycle, which would means the light was on full bright. If it never turned it on, it would mean the light was (does anybody know the answer? class?) off. If it turned it off halfway in between, the light would be at half brightness. To implement the 32 levels of brightness means dividing the half-cycle into 32 divisions of each area, corresponding to areas of equal power.

(To be better, I should take into account the power/luminance curve of the incandescent bulb that I’m using and use that to figure out what the delays are. Perhaps the next version).

To do this for multiple channels, you end up with code that does the following:

1. Check all channels to see which ones should be turned on at the current time.
2. Figure out when the next time is to check.
3. Set an interrupt to that time.

That gives us a set of lights stuck at a given dim level. To animate, you need to change that dim level over time. That is handled at two levels.

The interrupt-level code handles what I call a dim transition. At least, that’s what I call it now, since I didn’t have a name for it before. We have a vector of current dim levels, one for each channel, and a vector of increments that are added to the current dim vector during each cycle.

So, if we want to slowly dim up channel 1 while keeping all the others constant, we would set dimIncrement[0] to 1 and set the count to 31. 31 cycles later, channel 1 would be at full brightness.

If we want to do a cross-fade, we set two values in the increment vector.

That all happens underneath the covers – the main program loop doesn’t know about it. The main program loop figures out what will happen next after the current dim transition, and then blocks.

My early controllers were all table-based, with the tables pre-computed. This was because I was writing in assembler. The current system could also use that approach, but with only 2K of program memory, the procedural approach is more compact, though it is considerably harder to debug. I have a C# program I use to create and test the animations, but I need to rewrite it to use DirectX because I need a 120Hz frame rate to match what I the dimming hardware does.

To get back to the zero-crossing circuit, I first built this circuit using a wall wart with a switching power supply. Such power supplies are small and efficient, but put a lot of noise into the transformer side. I wasted a lot of time on this, and ultimately switched back to a conventional wall wart (from an old Sony discman I used to have) with a linear power supply. Problem solved.

Back to pictures:

Here’s the completed controller board.

In the center is the AVR 2313V microcontroller. The U-shape is the solid-state relays that switch the AC for the lights. These are nice little Panasonic AQH2223 relays, which switch 600mA (about 75 watts) (though you can get the in versions that do 150 watts), are tiny, and, most importantly, they’re less than $2 each.

Note that these do not have built-in zero-crossing circuits built in. Most solid-state relays do, but you can’t use those to do dimming.

The top has the one transistor used to generate the zero-crossing circuit, a 7805 voltage regulator to provide +5V to the circuit, and a few passive components.

Careful viewers will notice that the upper-right socket is empty. That’s because it’s only a 15-channel controller, but I used 16-pin sockets.  The blue wire that holds the AC socket wires on is wire-wrap wire that I had lying around – these are hot-glued down later on. The two black wires provide the rectified voltage (about 15V IIRC) from the wall-wart.

The controller board is in a small plastic box designed to hold 4×6 photos, and then that’s inside of a larger box. This lets me keep all of the electrical connections inside of the box. It’s not really required for safety, but if you have a lot of exposed plugs and some water on them, you can get enough leakage from them to trip the GFI on your circuit. So having them all inside is better.

The box will be enclosed in a white kitchen garbage bag for weather protection when it’s outside. That seems low-tech, but has worked will in all of my controllers over the years.

Cabling

Projects like this often come down to cabling. Each light needs a wire that goes from the controller out to the light. I did a random layout of lights on the tree, and put them on 5 different ropes so they could easily be pulled up the tree on a pulled.

Here are the 15 lights and all the extension cords required to hook them up. In this case, I used 24 15′ extension cords because it was cheaper and easier than building the cables up from scratch.

That’s all for now.

I’ve been searching for a new project to do for this season’s holiday lights. I typically have four or five ideas floating around my head, and this year is no different.

Lots of choices, so I’ve had to come up with a “rule” about new projects. The rule is that the project has to be in the neighborhood of effort-neutral. It already takes too long to put up (and worse, take down) the displays we already have, and I don’t want to add anything that makes that worse. Oh, and they can’t take too much power, because I’m already on a power budget.

Unless, it’s, like, especially cool.

I had an idea that met all my criteria. It was small – small enough to be battery powered, if I did my power calculations properly, and was going to be pretty cool.

It was, unfortunately, going to be a fair pain-in-the-butt to build – the fabrication was a bit complex, and the plan was to build a number of identical pieces. Oh, and it required me to choose the perfect LEDs from the 15 thousand that Mouser carries.

So, I hadn’t made much progress.

Then, one day I was waiting for some paint to be tinted at my local home store, and I came across these.

They’re holiday lights. Jumbo-sized holiday lights.  The bulb part is made of colored plastic, and measures about 7″ high. At the bottom there is a large fake lamp socket. Inside of all of it is a genuine C7 bulb of the appropriate color.

I bought 3 sets, 15 in all.

To be different, I wanted to build these as self-contained devices, with a separate microcontroller in each of the light bases. The microcontrollers I’m using cost about $1 each, so there isn’t too much cost there, but the big challenge is a power supply. Generally, I build a linear power supply, which is simple and performs well, but you need an expensive and bulky transformer.

There is a way around that, with the reasonably named “transformerless power supply”. Realistically, a better name would be the “high-voltage shock-o-matic”, because it involves hooking things directly to the AC line, can only supply a small amount of current, is inefficient, and is hard to troubleshoot. Oh, and if one component fails you get 150 volts instead of the 5 volts you were expecting.

I decided to build one of these, so I ordered up some parts, wired it up, plugged it in, and immediately lost the magic smoke from one of the resistors. Turns out I miscalculated, and I needed a much-more-expensive power resister.

Thinking about it some more, I decided that since I still needed power to each bulb – and therefore a wire to each bulb – it was simpler to just build a simple system with one microcontroller.

For your “enjoyment”, a report on the Triathlon I did last Sunday…

A recent discussion on how to deal with dependencies when you’re an agile team got me thinking…

Whether you are doing agile or waterfall (and whether the team you are dependent on is doing agile or waterfall), you should assume that what the other group delivers will be late, broken, and lacking important functionality.

Does that sound too pessimistic? Perhaps, but my experience is that the vast majority of teams assume the exact opposite perspective – that the other group will be on time, everything will be there, and everything will do what you need it to do. And then they have to modify their plan based upon the “new information” that they got (it’s late/somethings been cut/whatever).

I think groups that plan that way are deluding themselves about the realities of software development. Planning for things to go bad up front not only makes things smoother, you tend to be happily surprised as things are often better than you feared.

A few recommendations:

First, if at all possible, don’t take a dependency on anything until it’s in a form that you can evaluate for utility and quality. Taking an incremental approach can be helpful here – if you are coming up with your 18-month development schedule, your management will wonder why you don’t list anything about using the work that group <x> is doing. If, on the other hand, you are doing your scheduling on a monthly (or other periodic) basis, it’s reasonable to put off the work integrating the other groups work until it’s ready to integrate (based on an agreement of “done” you have with the other group).

That helps the lateness problem, but may put you in a worse position on the quality/utility perspective. Ideally, the other team is already writing code that will use the component exactly the way you want to use it.  If they aren’t, you may need to devote some resources towards specifying what it does, writing tests that the team can use, and monitoring the component’s process in intermediate drops. In other words, you are “scouting” the component to determine when you can adopt it.

(Interestingly, I find myself writing more about agile and team stuff now that I’m not on a development team….)

This is in response to a question about how you balance individual empowerment with the collaborative approach on a agile tem… 

*** 

Agile is all about the team, and being on an agile team requires participants to give up some autonomy towards the team. The team is empowered to do what they need to do to reach their goal. If there are issues around how things should be done or what decision is right, the team needs to come to a decision, and I would encourage management to let the team try to do it.  Further, the team needs to “meta rules” around how to make decisions, and they also need to develop those.

This is very different than the “alpha geek” culture that exists in some groups, where a small number of developers are interested in wielding power. There are some individuals who just aren’t willing/able to work collaboratively – I’ve worked with a few, and if you are trying to run an agile team, they are likely better in a different position.

One of the teams I was on basically came to this agreement:

Developers are expected to use their best judgement when deciding what advice to seek when they are doing development.   There are no rules around when you should seek advice, but as a rough guideline, extending functionality under existing patterns is something you can safely do on your own, and big refactorings or new components are areas when you should definitely seek advice. In between, think about the implications of any design choices you might make, and act accordingly.

The other approach is to adopt pair programming, which is a bigger cultural change, but generally if you get two people thinking about decisions they usually make the right decision about involving others.

A recent question about skill requirements for project managers of agile teams led me to write this:

In traditional project management, “project manager” means “person who is in charge”. In other words, that person makes the decisions, with varying degrees of depth (sometimes it’s high-level, sometimes it’s micro-management).

Agile doesn’t have somebody in change – inherent in the concept of agile is that the group is responsible and the group decides.

There *is* somebody who facilates (scrummaster in scrum, coach in XP), but their job is very explicitly not to make decisions. That means that the person who takes that role needs to be mindful of that and willing to push any decisions that rise up back down to the time. If the person has previous experience (and a preference) for “being in charge”, they are unlikely to do a good job in that role. If they aren’t thoughful about group dynamics in general, they may not do a good job in that role.

Double that comment if the group is not experienced with making decisions together. If they tend to defer upwards and the facilitator is used to making decisions, you probably won’t get a good result.

Ring of Fire is a tree ornament I built this year. A big, high-powered, custom-animated tree ornament.

First, there was the idea and a parts list.

Then I wrote a simulator to create animations against.

When that was done, I built the ring and started on the firmware

And then I did a whole bunch of wiring to hook up the microcontroller to the LEDs on the ring, finished the code, and put it up in the tree in my front yard.

Finally, I took a low-quality video of it.

The oldest of my displays. The “landing lights” are blue lights in canning jars dyed blue. All the santas and the reindeer are made of plywood. Some of the lights on the mid and upper santa are burnt out, but I’m not sure I’m going to get around to fixing it before next year.

Animated with an 8-channel custom Motorola HC11-based microcontroller system driving solid-state relays, all coded in assembler

Santa Animation