tiistai 22. huhtikuuta 2014

Software guy in FPGA land

I have to admit it, I am primarily a software guy, have always been. I can take a random chip, look through its datasheet, build connecting electronics around it and make it dance with software (with some assistance from suitable MCU of course). But if you reverse the situation - that is, if I need to make a hardware module to do the dancing (in this context I mean FPGA) I'm lost. I am familiar enough with basics, but to actually implement something relatively simple (say, a simple controller that can take data from outside, store it in internal memory and run a sequence based on data) I seem to be facing a very steep cliff.

For example this little thing. Pen for scale; actual board size is 60x60mm (JTAG wires you can see behind the board go to small helper board I put in there to make development a bit easier).














I've had this sitting on my desk for almost a year now (mostly because the projects that actually do pay the bills have been a priority). This is an 8x8 RGB led matrix. What I hope makes it interesting is the fact that it is self-controlled, chainable (you can in theory chain dozens if not hundreds of these together in any shape you want, based on your current need) and it is trivially controllable by even tiniest of the MCUs (say, the PIC12 I wrote about earlier - with a little help from a shift register to extend output pin count, but an Arduino with simple adapter shield should do nicely).

The idea is that you "pre-load" data in by clocking RGB data (each component separately, with up to 10 bits in parallel for each; so loading first to LEDs is R10 - dataclock - G10 - dataclock - B10 - dclock - R10 - dclock - G10 ... and so on). Timing requirements are not strict so you can take your time calculating next value between data clocks. When you have your entire matrix loaded with data (that is, every LED in every module you have in chain), you can signal them all to switch data to new with "flip" signal pulse. So essentially you can load an image to them, flip, load new image (and you can take all the time you want), and flip again - no jitter, just instant image change. Very very simple. (some details omitted, they aren't that important right now)

This takes in 5v input (though I already found out that it can tolerate 12v, for short periods at least, it just gets really hot - that should teach me to use same power source for different projects and then forget to change) and with every LED at maximum brightness (white) single module uses about 1,5A. Typical use of course would be less, directly proportional to overall brightness.

Now, as you might have guessed, "the dance" here is ability to drive all the LEDs, load new data in background and then load new current scaler values when needed. Since I had some spare time now, I started with VHDL again (it was a long time in between, so even basics needed a quick refresh), and actually have made some progress. That is to say, it won't work. Something fishy when trying to access internal RAM. The fetch process itself appears to be running nicely, just the bits in RAM refuse to come out.

But at least it seems that during the period of inactivity the background processes in my head haven't been idle - when last working with it I was completely stumped on how to build process to access the RAM, now it seemed to be crystal clear from start.

Except that "doesn't work" part. But I'm working on it.

Ei kommentteja:

Lähetä kommentti