Now that I’ve finished some of the scientific work that was monopolizing my time, here’s some geeky and nerdy gadget for Linux fans. BTW, why is it that trying to find out what “geeky and nerdy” actually means, is also “geeky and nerdy” :-) ?
It’s just a rehash of the 8×8 RGB matrix, but as I didn’t have any better ideas (yeah, could’ve made a pumpkin thingy…) I just wrote a little perl script and modified the firmware a bit.
Behold: THE LOAD MONITOR !
It needs the PERL module Device::SerialPort installed!
As root:
1 2 3 |
perl -MCPAN -e shell install Device::SerialPort exit |
The user must also have RW access to the serial port (e.g. /dev/ttyUSB0). On openSUSE this is done with putting the user into the UUCP group ( as of openSUSE 11.2 it is ‘dialout’ ! ) + re-login.
Code: power_monitor.pde power_monitor.hex (ATMEGA 168) power_monitor.pl
Just one color right now, no moving history yet. I will upgrade it tomorrow I think.
→ Update 1: 26.10.2008:
Put some colors into it. Low load: green, high load: red
Code: power_monitor-v2.pl
→ Update 2: 28.10.2008:
Now comes with a history graph and stylish new colors. Bottom and top color can be set in the perl script (HSV color space).
Code: power_monitor-v3.pde power_monitor-v3.hex (ATMEGA 168) power_monitor-v3.pl
→ Update 3: 29.10.2008:
Next update to the perl script. Now implements a scrolling history plot, instead of restarting at the left edge.
Code: power_monitor-v4.pl
OK. I declare this project as finished. Maybe I’ll get a nice wooden box for it.
→ Update 3: 24.11.2008:
Some illustration on how the matrix is redrawn by the ISR routine and how the ON/OFF stream is created for each LED.
→ Update 4: 22.11.2009:
Hey!
Nice work with the LED matrix. I have been thinking about using a similar construction for a robot mouth that could be drawn from a PC.
First of all I do not understand 100% how it all works. Is it correct that the rows are redrawn sequentially when the timer gives an interrupt (from a clock scaled to 16 kHz)? And for a brighter color the LED is lit more often?
When using an Arduino for this, could that same Arduino do other things like controlling servos for instance?
If you want to you could drop me an e-mail for some discussion on this.
Hi,
yes, the IRQ input clock is set to about 16kHz. I also precharge the value of TCNT1 inside the ISR (TCNT1 = __TIMER1_MAX – __TIMER1_CNT;) to make it overflow more often (= LEDS don’t flicker, a few more colour values possible). The overflow event is triggered as soon as TCNT1 = 0xFFFF (16bit counter). With precharging it runs at about 16MHz / (1024 * __TIMER1_CNT) = 51.4Hz
The timing was optimized to keep the CPU running the ISR most of the time. If the timing is bad, the LEDs will flicker and get darker. It is possible to do some RS232 in the LITTLE time that is left. Basically all the arduino does is redraw the matrix.
As I’m planning to let ‘game of life’ run on it, I’ll still have to test if there’s enough CPU time left for other stuff. I’ll need a new oscilloscope to check the timing though. Maybe I’ll get me one for x-mas :-)
Yes, the matrix is redrawn like old TVs. I’ll add an illustrative graph to explain the ISR a bit.
I think the arduino library for controlling servos uses TIMER1, so you’d have to switch the matrix to TIMER2. This is possible. In fact I was running on TIMER2 before, but switched to TIMER1 as it offers bigger prescaler divisors. I had the problem that the ISR would lock up at some point. It turned out that it took too long to redraw the matrix when I increased the number of brightness levels.
I think the only job of the servo library is to send a pulse to the servos every 20ms or so. Maybe this won’t hurt the redrawing, but I’m not sure.
If you send me the servo-code I can plug it into the matrix (lol) and see if it still works.