The Mitochondrion 3.5 – An Excessive Glowstaff (7 of 8)


You wire it all up. You plug it in. You turn it on… and nothing happens.

Most of the time in this project was spent scratching my head and swearing at it. Most of that time was spent debugging software. So here’s my tips on debugging Picaxe code and complicated projects like this:

1) Put an LED directly on the microcontroller. Flick the LED from within the program, so you can tell if the code is running at all. Bonus points for connecting the LED to the power supply, not ground, coz the Picaxe outpin pins all drop to ground then a download starts. This gives you a clear indication of whether the download is starting.

2) Switchable behaviour within programs is most handy for turning on debugging from within the code. The Picaxe complier supports conditional directives but I found myself using a debug_flag variable, for idioms like:

if debug_flag=0 then
	// No debugging
elseif debug_flag=1 then
	sertxd ("OMG ponies!\t", #num_ponies, cr, lf)
elseif debug_flag=2 then
	sertxd ("OMG flying ponies!\t", #num_ponies, "\t", #altitude, cr, lf)

3) If your code isn’t too long, use the debugging switch to test subroutines, use cases, and so on.

4) The debug command is a pain in the arse. Use sertxd instead, to send you just the data you need in, along with labels indicating where you’ve got to in the program.

5) Code and circuit simulation are all well and good and should be used, but they’re not much help when your circuit includes other logic devices. My VSM can’t simulate the LED drivers, for instance.

6) Main cause of bugs for me – Variables reused. Subroutine A uses the variable loop_counter, hopes that nothing else will change loop_counter, and calls sub B. Sub B needs a counter and reuses uses loop_counter, resulting in everything turning to custard very quickly. The correct solution is scoping (and maybe namespaces) but Picaxe BASIC doesn’t scope. The next solution is a vast number of variables. The 40X1 has 28 bytes for variables. The solution I ended up with was to shuffle as much of the runtime data off into the scratchpad to free up the variables so that they could be used as named pretend local variables, with names like A_loop_counter and B_loop_counter.

7) Pointers are evil. However, they do let you use one byte of variable space to refer to the 128 bytes of scratchpad space and let you make pseudo-arrays in the scratchpad. This can go horribly wrong and stab you in the face but I expect that. I used to be a C programmer.


Looking back, the main causes of failure have been:

1) Not having regulated power to the microcontroller. Always do this. Otherwise, turning lots of LEDs on in the same millisecond can drop the supply voltage enough to crash your microcontroller.

2) Wiring coming loose. IDC connectors are passable, but any other kind of connection? Ugh. Soldered joints might be covered in heatshrink, but they still fatigue and snap. Soldered joints covered in heatshrink and hot melt glue still fatigue and snap. Bolt everything up good and tight and don’t take any mechanical loading through the solder.

Here’s how I made the joints between the five circuit boards:

3) Dry solder joints. If bending the board causes crashes, or makes it start working, then it’s probably a dry joint.

4) Batteries dying. Don’t put NiMH battery packs in parallel. Just no. They end up fighting each other, both on charge and on discharge, until one cell just craps out. If, for instance, you’ve the perfect space for two packs of four cells to give you five Volts, maybe you’re trying to fit AAA cells into a one-inch tube like me, resist the temptation to put those packs in parallel. Suck it up, put them in series and live with having the wrong voltage. What’s one more DC-DC converter anyway?

16 thoughts on “The Mitochondrion 3.5 – An Excessive Glowstaff (7 of 8)”

    1. JTAG takes six pins. Six fucking pins. You want to tell me how to get a six-pin connector through a one-inch circle when that one inch circle already contains a bolt head (diameter 6 mm), a power connector (diameter 9.5 mm), a programming connector (diameter 8.75), a electret microphone (diameter 7.9 mm), and an o-ring bringing that one inch down to about 22 mm?

      Not that I’ve thought about this, or anything…

      But yes, JTAG would be very nice indeed. However, it would also involve taking the whole thing apart to be able to debug it which is a pain in the arse when some of the bugs only appear when the whole thing is assembled. Obviously, the solution is wireless JTAG. And that’s wireless JTAG that works all the time and doesn’t need debugging itself, which means I’m asking for sparkleponies here.

      1. You can program AVRs over JTAG, so you don’t need the programming header, instead you trade four pins + !RESET + VCC/GND (which should be there anyway, I’d expect?) for three pins + !RESET + VCC/GND. But gain debug *and* program.

        1. Yes, if I wanted to get worryingly low-level and pfaff with AVR development environments and get my head around the vast range of close-pitch JST/Molex connectors that I could use if I could work out which ones would suit.

          Or I can just go “bugger it” and run USB to the Nano and have a separate reset/sleep socket at the other end. Having a separate socket dedicated to that works wonders for performing field resets, and by that I do literally mean reseting it in a field, using a shorted jack plug that can live in my pocket. By touch, in the dark and the mud and the rain, down’t pit while eating a cup of cold gravel.

          1. No, you don’t need to lose the Arduino environment to use an external programmer instead of their USB serial bootloader stuff:


            You might need to hack a bit at the boards.txt and pin mappings header if you deviate a lot from the way the pins are mapped between the Arduino IDE and the 328P (or, if you decide to go beyond the 328P and use something bigger), and you’d need to figure out the debug yourself, but it’s *not* a different toolchain to winavr on windows or apt-get’ing the components on *nix. It’s just a nice wrapper and some libraries. (And, until 1.0, libraries which kinda need some work. They’ve only just implemented serial support without busy looping 🙁 )

            As for connector stuff, the thing is a single keyed connector still allows you to have a reset-dongle with only the appropriate pins shorted. Besides, the Nano has a USB chip sitting there sucking up power while doing nothing 95% of the time, you’d really want that off-board via a squid cable.

            Just throwing stuff out there, you know?

          2. Indeed, all of this is worth thinking about regularly. There remains a bewildering range of possibilities when it comes to connectors and if I just rock up to Molex or JST and say “I’d like a connector please”, then they’re going to give me a stern look.

            Still, I think I’ve got something that will work for the next version. By the time I get on to the version after that, the Arduino Due should be out, for 32-bit goodness, which will no doubt prompt further rethinking…

          1. It would also be easier to go out and buy a premade staff. But one of us seems to enjoy the process of debugging far too much for easy to be an option.

          2. Easier, but orders of magnitude less awesome. Pre-made staffs are… umm… responsive to the overall market size and the realities of consumer products, which is my tactful way of saying a bit shit in comparison but I can’t work out how to do what I want in a saleable product.

          3. seconded.

            “a bit shit” in terms of variety of effect and all, though of course being simpler they are easier to make robust.. as long as you are willing to pay for the one with the polycarbonate tube.

            Basically the best one I have seen online is a huge glowstick with variations on the colours fed from units that plug into each end, the C3 glow staff from concentrate. And even then the list of lighting options on it makes me think thrice, 15 modes. though you can take the ends out and just use them as fancy coloured flashing lights in other things too.. hmm! cost about $400.

            or theres the ones which are collapsible tubes that you stick several of those Flow-Light units into, so you have a cluster of separately operating LEDs, and they add up to about the same as a C3. zomg. here’s a thought! combine the C3 light units with collapsible tubing!

            others are not much more flash than the one I made by sellotaping LED juggling balls on the ends of a broomstick, and can be had for about $150 or so. if you can find somewhere that will post them to NZ. alternatively buy some C3 balls and glue them to a stick.

            so. Happy I’d pay $1000 for one of yours.

  1. I’ve made it a habit to always have a heartbeat led and a power supply led (the latter biased so it goes out if the supply ever sags more than 0.2v or so.) I spent way too long crying over mysterious hangs/nonstarts to give those up. Once it’s debugged and more or less working, they may get removed, but arrrgh.

Leave a Reply

Your email address will not be published. Required fields are marked *