scottie4442:
I did not understand tha last part, 3:3:2 mapping(?). I do understand the PWM part, and I have looked at this with another board, just did not want to reinvent the wheel here. I was thinking about doing the 8bit thing. I am going to have to get with my fellow professor that teaches programming and see if he can help me with the C code, I am good with RealBasic (kinda like Visual Basic but better) but I have not had too much experience with C, I am going to have to figure out the whole PWM thing from the ATMega8 side, I have done this with circuitry but not from software.
Thanks for the help so far
Since there are 8 bits, you have to divide them for RGB. Say 3 bits for R and B and 2 for G. So you get 0, 12.5, 25%, 37.5, 50%, 62.5, 75, 87.5 and 100% (almost) for red and blue. Green only gets 0, 25%, 50% and 100% (almost). It is almost because there is some overhead (1 interrupt cycle), so you don’t get 100%.
Another possibility is to use a color LUT. Depending on how much memory you want to dedicate and perhaps performance (I have not done any calculations), you can have many more color possibilities. This is how old PC cards worked.
As for the PWM, it is merely counting and comparing. At the start of each frame cycle (say 60Hz), you load the brightness value and turn on the corresponding LED (unless it is 0). Each loop, you decrement the value and if it is 0 turn off the LED. Since you have 8 rows per frame and 8 brightness levels, you will need to interrupt at least every 1/(60 * 8 * 8 ) S. I am not sure of my math, I have been thinking about how I would do it, but have not spent the $ yet.
I was a little concerned regarding the actual design of the controller.
1. All channels have the same R value. I wonder if you get consistent brightness across RGB. I am curious what the actual current is.
-
They are using 74LS595 for high side drive. These seem to be driving the LEDs brightly, but I don’t think they can source a lot of current. If it works don’t fix it?
-
A user has had problems with ghosting. This may need to be addressed.
-
I think that it is excessive to transmit all 64 bytes everytime unless it is live video. Since their SPI clock is limited to 125 KHz, this may limit the number of displays. Lets see, 125 KHz gives roughly 15625 Bps or 244 displays/S.
-
The use of SPI makes it a little hard to daisy chain these things. Although the current design makes them independent, it puts some row, column translation burden on the host.
I have to admit that these is all random musings of and interested mind (what’s left of it). I am sure that others will correct me soon :lol: .
