I’ve been working, very slowly, on a physical control panel for Paisley, my home server. The easiest way to do this would be to connect an Arduino to one of the USB ports and the use the Arduino to power whatever input and output devices that I want.
Now, where’s the fun in that?
Instead, I found a bunch of microcontrollers sitting in a plastic container, so I reached for my old Dragon Atmel programmer. I stole a MAX232 from the museum to handle translate an RS232 signal that I’m taking straigh off the server’s mtoherboard, to a nice, 5V logic signal that can be read by the microcontorller. I managed to get to a point where a python script on the server sends characters to the serial port, and an LED blinks on my breadboard every time that happens. Success!
Then I tried connecting an LCD. I found Peter Fleury‘s LCD library for Atmel devices which had the all the LCD’s pin be driven by the microcontoller’s port A. Of course, this did not work out. I used my fancy nScope (I really should dedicate a post to that cute gadget) to realize that I can’t seem to get port A to work at all. I tried a bunch of other microcontrollers, but they were not even communicating with my Dragon.
So I had to modify the library to use other ports. That wasn’t that hard, and it actually worked. Kind of.
Oh no! I took the red pill!
I accidentally gave the lcd_puts command an integer, which it probably interpreted as a memory address, sending the Matrix-like text to the LCD. reverting the command to lcd_putc, instead, gave, naturally, a different character than the character I was sending from the server. I’ve seen this a thousand times before, when sending bytes between a computer to a microcontroller over serial. Depending on the language used and the direction of the transmission, there are various solutions to this. Unfortunately, I don’t remember the right one for this situation. I think it’s time to use the Dragon’s JTAG terminal to see what exactly the AVR thinks it’s getting and take it from there.