What do you do when you have a microcontroller you’re trying to optimize? One method is using a debugger, but for AVRs and such that’s not a very common technique. For lower-level electronics projects, it’s nearly impossible, even. [Cnlohr] built a small Minecraft server that listens to in-game redstone circuits, but the performance of his real-world to block-world bridge wasn’t what he hoped. He came up with a pretty clever way of figuring out what was slowing his server down without any special gear at all.
[cnlohr]’s Minecraft server is just a simple AVR microcontroller, Ethernet adapter, and SD card affixed to a beautiful glass PCB. The performance of his server wasn’t what he expected; downloading a largish file from the server resulted in a download rate of about 55kbps, much slower than he expected. He wasn’t quite sure what the hangup was, so he took a camera and with a long exposure time took a very blurry picture.
The Minecraft server has a blue LED to show when the SD card was being accessed. In the picture above, [cnlohr] saw that SD card access was taking far too long, and if he wanted to optimize the code this would be the place to start.
Not bad for a dead-simple method of seeing where the code on your microcontroller project is slowing down.
[youtube=http://www.youtube.com/watch?v=bHbeFnSWSxI&w=470]
that’s super clever, i like it.
brilliant indeed :)
thread-state and read/write logging that is later graphed on a time-scale.
I’ve been doing that for a long time to figure out if my pwm levels are reasonable. I first used it to figure out my pwm frequency — take a quarter second snapshot and count how many dots I get.
I didn’t even think about that – mind if I point that out on the video (and give you credit)
Just realized most people aren’t subscribed to their comments – I’ll add it and I can remove it if you request.
By all means; it’s not super duper important for credit – but thanks :) The only hard part is lining up the timing of the long(ish) exposure to match the led blink cycle you want to catch if it is variable.
My wife’s grandmother programmed Soviet punchcard machines and optimized based on the noise the mechanisms were making. She started with absolutely no formal training but soon became to go-to person when you wanted your program results soon.
That’s really cool.
Neat. I understand in theory how such could be done. I never thought about it before but you are essentially hearing ram being read into a CPU. You could literally sense when a job was I/O(memory in this case) bound and increase the processing speed with no fear of breaking the card reader or jamming the whole works with paper.
Also a great way to measure frequency, if you don’t have a scope and the device is flashing at a relatively slow rate. I measured a 60 HZ line frequency on an led once by making my camera aperature speed 1/4 second and then taking a picture of the led as I was swinging it. Sure enough, counted 15 blinks on the led, so I was pretty sure my frequency was good.
I guess it is a clever method if you don’t have an oscilloscope or logic analyser.
soundcards make okay oscilloscopes as well
Cunning.
He could also have used a (slow) multimeter to measure the voltage on the LED’s as they’re acting as PWM in this case.
A scope (even a soundcard one) will do very nicely for this sort of thing, we’ve spent many hours debugging with scopes, logic analysers and the bus pirate hanging on various IO pins, LED’s being a favourite as they are also readable with the Mk1 eyeball.
You can also do it with spare hardware timers (anything that will free-run, unaffected by CPU load, and you can read the time you started/stopped).
I did something like this (without the motion blur) once. I was concerned with the amount of available CPU time on an AVR — in particular, whether my input interrupt handler was leaving enough time for the main program. So I programmed the interrupt handler to turn off an LED whenever it was running. Thus, if I had a starvation problem, the LED would be completely dark. (I chose to turn it off, rather than turn it on, because it’s easier to judge almost-completely-off than almost-completely-100%-brightness.)
I used this approach “the other way round” to determine the shutter speed of my DSLR: http://blog.blinkenlight.net/experiments/measurements/shutter-speed/