Close

Number 3: The Microcontrollers

A project log for Purposeless LED Display

When life gives you an empty glass candle holder, why *wouldn't* you jam a ton of LEDs in it?

jorj-bauerJorj Bauer 03/30/2016 at 13:300 Comments

I should probably talk a little about the electronics in this build.

Yes, I chose a Moteino. The RFM69 with flash onboard. The frequency is immaterial (but I'm using 433 MHz). The flash was deliberate: when done, I want to be able to reprogram this thing via wireless, which you can do if you plop on the flash IC.

But there are two microcontrollers in there.

The Pro Mini has a pin driving the LEDs as a single strip. And the two microcontrollers have their RX and TX lines connected (swapped, of course) so they can talk RS232 to each other. I have a half-baked protocol that I've been using to control LEDs for my Christmas trees, so I used the same protocol here (yay code re-use!). And there's a pin on the Moteino that's being used to drive the fan via PWM (using the onboard temperature sensor in the RFM69 to keep an eye on the temperature, driving the fan appropriately).

But none of that lets me reprogram the Pro Mini wirelessly. That's a real problem I want to solve: I would hate to finish this thing off and find a bug, have to open it up to reprogram the Pro Mini.

Of course, the solution is obvious: use the Moteino as an Arduino programmer.

So: a pin on the Moteino is connected to the RST line of the Pro Mini, and pins 11, 12, and 13 of the Pro Mini are driven from the Moteino as well. With those lines it's fairly simple to implement the programming protocol. The one down side is that doing it this way blows away the bootloader. Which is fine: I just have to program the pro mini via the Moteino (or any other in-circuit programmer). I can put the boot loader back if I absolutely need to.

It works like this:

I compile code for the Pro Mini, and find the .hex file that was generated.

I have a (Perl) script that sends the .hex file, with some necessary header info to invoke the "programming mode" in the Moteino.

The Moteino stores the .hex file's text contents in flash as it gets them. When it detects that we're done (which, again, I did in a kind of half-assed way that's sufficient for now but makes me kind of uneasy) then it starts programming the Pro Mini.

Along the way I added a "reset the Pro Mini" command from the Moteino, so that I could reboot it if something weird happened; and I added some feedback while it's programming in the form of pulsing the fan so that I can tell when it has started receiving a program, when it starts flashing, and when it's done flashing and is rebooting the pro mini. Because there's no good way to get feedback on the LEDs while the pro mini is being reprogrammed.

Well, maybe "no good way" is a bit of an overstatement. It's certainly possible for me to flash bits of code, reboot the pro mini to execute it to show something on the LEDs, and then flash more bits of code. Repeat. But that seems like a lot of work for very little feedback.

The process is slow: I haven't optimized it at all. It takes somewhere around a minute to flash the pro mini. And there's a race condition somewhere that I haven't quite tracked down. But it works well enough for now.

Discussions