Writing code for embedded applications can be difficult. There are all sorts of problems you can run into – race conditions, conflicting peripherals, unexpected program flow – any of these can cause havoc with your project. One thing that can really mess things up is if your microcontroller is getting stuck on a routine – without the right debugging hardware and software, this can be a tricky one to spot. [Terry] developed a microcontroller load meter just for this purpose.
It’s a simple setup – a routine named loadmeter-task on the microcontroller sends a train of pulses to a mechanical ammeter. The ammeter is then adjusted with a trimpot to read “0” when the chip is unloaded. As other tasks steal CPU time, there’s less time for loadmeter-task to send its pulses, so the meter falls to the left.
Overall it’s a quick and easy bit of code you could add to any project with a spare GPIO pin, that might help you debug. Plus it’s cool to know how hard your project is pushing the silicon.
If you’d like to know more about what your chip is doing, check out this post about the usefulness of in-circuit debugging, or read about Bil Herd’s experiments with ICE and OBD-II.
The Hardware side was simpler than expected.
Apologies for anyone reading, I moved this webpage some time ago and it is now located at my new site: https://mecrisp-stellaris-folkdoc.sourceforge.io/instrument-mcu.html
The headline would be a perfect pun if the meter scale were in Amps!
There’s a problem with the hardware design! When the output to the meter transitions to low, the reverse EMF from the coil in the meter will be hard on the microcontroller port. To make it safe, put something like a 1N4005 across the meter. (Anode end to ground). This will absorb the inductive kick from the meter.
Surely you’d want something faster than a 1N400x diode ?
1N4001 has been the standard back-EMF protection diode since forever. I don’t suppose the 4005 is any faster or slower.
I suppose you’d have to calculate the voltage over time, caused by the field collapsing in the coil, and the ability of the mcu’s GPIO pins to cope with it. In practice though, it’s a solved problem.
My favorite trick is to add two lines to the ISR to switch a GPIO high on entering and low on exiting. Then an ordinary multimeter set to duty cycle will act as a load meter. Something similar can be added to the main loop, going high when there is something to do and low when idle or going to sleep..
Ah, dogma.
Kickback is never more current than was originally applied, and the built-in substrate catch diodes on almost any chip easily handle this.
1n400x series diodes are BTW far too slow to catch the peak from low inductance things like ammeter coils. They take a goodly time to turn on and off (try them on a fast square wave like a CCFL inverter if you don’t believe me). A 1n4148 or similar would be a better choice – if it mattered at all.
Kids these days.
We are seeing no ordinary embedded hobbyist kicking the dog here folks, this poster knows his stuff. I come from a time long gone, when one would use a parallel array of 1N914 diodes as a frequency trippler into GHz.
The built-in substrate catch diode was exactly my reason for not worrying about any inductance from my old meter.
Back in the early ’70, I put a ‘scope across the ‘IDLE’ LED on a TI980 minicomputer and used it to time how long interrupt routines took to execute.
I usually soft output serial data at 115k on the power LED pin, you can also toggle it fast, user will generally always see it solid
Only marginally related, but this week I had a colleague swipe the USB wall wart I was using to power a Pi for a prototype IoT controller, so I hooked it up to an old analog benchtop PSU. The PSU’s current gauge was limited to 2A, and of course the Pi will oscillate between ~300mA at idle and ~1200mA based on load.
I was running a script that executed a SQL query every 500ms and an HTTP request every 250ms, and I happened to notice the current gauge. I couldn’t help but feel like I was watching a heartbeat.
My favorite trick is toggling a pina when a task or ISR enters and exits, then using a scope to check timings. Haven’t found a better way to debug ISR stuff. Other suggestions?
I’ve used this for _decades_. Pretty hard to beat, especially if you have lots of pins, scope channels etc. A led per pin used for this can be fun too. With a multichannel scope, you can see threads running inside/interrupting other threads. Very cool technique to use to learn to model it all in your head so as not to need it every time.
Toggling a pin to measure ISR timings has been critical with the product I’m working on.
The http://www.synthimuse.com has no code in the main() loop, it’s all in ISRs and this technique has been my mainstay timing tool.
I work mainly with Microchip tools and I’m saddened that their debug toolchain doesn’t seem to offer a way of characterising the load presented by all the different branches of the call graph. Unless; does anyone know any tricks for this?
Roundrobin multitaskers are interesting beasts.
This is a novel idea – I’ll use it.
The other thing I like to do is make an idle task and slowly increase it’s on time. Until the overall code fails. That also gives a pretty good idea of what percent load the box is doing.
Get serious.
This is actually a technique that’s old as micros
It’s quite useful
This would be kinda cool to build into a custom PC, like a gaming rig or something.