Close

Part 8: The Cycle (is too long)

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 05/13/2016 at 22:040 Comments

After wiring up the static RAM, the next obvious step is, well, to test it. Right?

I wired in some test code that writes a %256 value to each memory location and reads it out; then displays a good-or-bad pixel on the LEDs. Good enough. And it works! Mostly.

Occasionally I get a failure right off the bat, and I can't figure out why. So, more debugging code inserted, and reprogram the device to try again.

Sadly, the reprogramming takes 5 minutes. Which is okay for a once-in-a-while update, but when I'm spending 5 minutes uploading every little test and I've only got 45 minutes or so to work with, that's a heck of a long time to wait.

So the RAM goes on the back burner, and let's diagnose why it takes 5 minutes to update over the radio.

Step 1: look at the protocol.

The HEX file is being sent in ASCII to an RFM69-equipped moteino. The remote end uses a custom protocol to pick that up, sends an ACK that contains the entire line received, store it in flash locally, and wait until it sees the Intel HEX terminator. Then it fires up an ICSP connection to the Pro Mini and programs it in one fell swoop.

Step 2: profile.

Turns out that most of the time is spent in the receiving of the HEX file. The programming takes somewhere around 6 seconds.

Step 3: profile some more.

If I take out the write-to-flash, it's not noticeably faster.

If I drop the contents from the ACKs, it's not noticeably faster.

In fact, I can gut all of the actual work - just receiving and replying is just this slow. Hmm.

Step 4: send less data.

Over a couple of days' lunch, I've rewritten the programmer to send binary data instead of the Intel HEX data. The packets are about a third their original length. And, once I found the mistake in my packing that data, it works just as well.

And is faster. We're down to 2 minutes.

Bonus: the write-to-flash step was just because it was convenient, not because it was efficient. I gutted that, and now it writes directly to the Pro Mini while it's receiving. Because the ICSP programming protocol isn't time sensitive (and this is why I decided to use ICSP instead of the bootloader), it doesn't really matter how long it takes to receive, parse, and write each chunk of code.

Not too bad. Now I'm back to my little red light showing that the RAM is failing to work, and I have one less excuse stopping me from fixing it.

Fortunately, my order from LowPowerLabs has arrived! Which means I can spend time wiring up two little RFM69 remotes instead of debugging this RAM...

Discussions