8x8 RGB LED Matrix Control Help!

[rWAVE]

I recently acquired an 8x8 RGB CC LED matrix and wish to control it with a 12F683 variant (PICAXE 08M) via BASIC. What I am trying to do is this:

The Pic uC will monitor the outside world for one of eight "events". Each event will have been previously assigned a unique color (i.e. red, green, blue, orange, yellow or any other color of the rainbow) and a graphics "pattern". Each event's unique pattern could consist of any number of the 64 pixels available on the matrix. Upon the uC sensing an event, the matrix will display the assigned color and pattern continuously until another event occurs.

Due to pin limitations on the 08M, four 8-bit serial-in, parallel-out shift registers (24 columns, 8 rows) are planned for the required display multiplexing. PWM is contemplated for the clocking, as an interrupt-driven BASIC routine may prove to be too slow.

My problem is grasping how to handle each of the individual events color and pattern. Each of the 64 available pixels has three LEDs (RGB) that need to be individually driven by its own PWM. And some sort of memory is required (I think) for storing each event's unique pattern that can be clocked out synchronously with the muxing of the display. This leaves the uC to only sense external event interrupts, output appropriate color and pattern and await the next external interrupt.

I would appreciate any suggestions on how to approach this project.

 

[Nigel Goodwin]

I would suggest using a bigger PIC, and using a proper PIC rather than a very limited PICAXE - I doubt a PICAXE would be fast enough, or have enough program space to do it.

 

[hjames]

Have you done the 'back of envelope' calculations on space and time requirements yet?

A 100Hz update rate ends up being 800 rows per second. If you want 4 bit color, you'll need to be able to do 800*16 = ~13Krows/sec => ~77usec. 6 bit color (2^6=64) ends up needing ~20usec. A proper SPI/UART module would make this easy, bit-banging would be a bit tricky.

The framebuffer would need to store 64 pixels * 3 colors per pixel = 192 values. If you use a 4 bit color scheme, you might be able to cram this into 96 bytes. PWM'ing can be done relatively easily, and shouldn't need a lot of space.

The other question being image space - at 100 Bytes per image, this will eat up program space in short order...

This might work if you jump into the assembly and do it properly, but I doubt any interpreted language would be able to do this, especially not crammed into this chip.

 

[rWAVE]

THANKS for the input, but I may not have been clear. The uC is only used to service the 8 external events (i.e. interrupts) and enable the appropriate 3-bit color and event pattern stored external of the uC. As this is to be a "hardware" educational project, I am trying to better understand what external hardware is required. I will save the software solution for another day (and another uC). Hence, I plan to implement the framebuffer in external RAM (or equivalent). Also, the 08M only has a single PWM output and I'm still trying to grasp how I control each of the RGB LEDs with only one (can the other two be somehow derived in hardware from the one?)

 

[cadstarsucks]

You can PWM each row or column driver individually. You can, if you want that kind of control change your output drive to a '595 and use its output enable. No, there is no way to derive it from another PWM.

As far as individual control is concerned, you would have to work it into your refresh routine. If you refresh the whole display 100 times a second normally (19KHz clock, '595 latching shift registers), you can go to 80KHz and get 4 intensities individually selectable on each die but if you do not have 48 bytes spare do not bother trying.

You are looking at about 24 bytes to address every LED, 48 bytes to give you 4 brightnesses on each.

D.