Graphics
Now, I could be perfectly happy with the result I'd gotten now: I had a nice network-controlled LED-board on which I could display all kinds of text and perhaps even black and red/green graphics. I was not: the hardware it all ran on was at least 15 years old and pretty clunky. It also couldn't do grayscales, and having to telnet in to change the display wasn't ideal. I decided it would be nice if I could find a more up-to-date way of controlling the LEDs. Scrapping the original hardware and connecting my own controller to the LED-modules seemed to be the way to go for that.
To drive the LEDs, I needed to have something that could output pixel data at fairly high frequencies, especially when I wanted to do PWM to get grayscale data too. In my previous LED-board build, I used individual AVRs to generate the signals for each part of the board. By splitting the load that way, I could get away with not having a very fast pixel clock. This time, the board was a bit too big to go that route: the serial connections in between the AVRs would be a bottleneck.
Instead, I decided to try my luck with a FT2232H. This chip is marketed as an USB2.0 dual-port USB-to-serial-converter, but as I saw in my FT2232 NAND reader, the chip can do much more than that. It has various modes in which it can output parallel data at, if you program it correctly, nearly the 480MBit/second the USB2-bus can handle. It also had the advantage that I could write the initial software for the PC, moving it to an embedded platform as soon as I got it to work.
Luckily, the guy who sent me the board already figured out the interface to the
LED-modules:
The modules work similarily to the ones in my
earlier build: you use the clock and data-red/data-green
lines to clock in a row of pixel data, then you set the A0-A3 lines to the binary line number
you want to display. Make the strobe line high for a while and that line gets displayed. Do
that for each line you want to display and keep doing that and you get an image. You really
need to keep feeding the display data: like a monitor, it doesn't have a framebuffer to store
the incoming image in so you need to maintain the incoming screen of pixel data or the display
will go blank. If I wanted to drive the display using an FT2232H, I needed to keep streaming
data to it.
I ended up using the FT2232 in 'host mode', giving me a 16-bit bus with write strobe. I hooked
everything up like this:
I also wrote a little PC program that would load multiple PNG files and use the
grayscale algorithm I used on the other LED-board
to convert them into data usable on the LED-board, then use that to control the
FT2232H to actually output the pixel data. When ran on the PC, all this worked like
a charm:
Ok, so the idea works, at least on a PC. Time for the second part of the plan: move everything
to an embedded controller. I still had a couple of Carambola
boards left: the Linux-driven 350MHz MIPS CPU coupled with a good bit of network connectivity
should do the trick. I hacked together a board for it all, thinking I was almost done:
It seems the software I wrote for it works.
Unfortunately, the best laid schemes of mice, men and hardware hackers...
During testing, I found out the Carambola had trouble keeping the stream to the FT2232H going when it had to do network access too. This probably was solvable by using a realtime kernel or hacking in the hardware drivers, but that would cost me a fair amount of time and effort. I decided to just take the easy way out and plug in something more powerful and be done with it.