• AVR Freaks

LockedRGB 8*8 Matrix design help!

Page: 123 > Showing page 1 of 3
Author
Guest
Super Member
  • Total Posts : 80504
  • Reward points : 0
  • Joined: 2003/01/01 00:00:00
  • Location: 0
  • Status: online
2005/11/04 10:03:56 (permalink)
0

RGB 8*8 Matrix design help!

Hello,

I am currently trying to start a new project using a R,G,B 8*8 Dot Matrix Module. I have seen one other post featuring controlling a 8*8 LED module. I wanted to know if anyone has any Ideas about effectively driving this sort of display. My display essentually would be 3 times the data needed to control it compaired to a regular LED Matrix.


This is the schematic of the Module I am using
http://www.autoxsystems.com/documents/88RGBMatrix.pdf

This is a picture of the Module I am using


I have a very advanced background in Microchip desing and PCB layout so those sorts of things are not an issue.

I need to know how I can drive this display effectily. I was thinking about using a very modular design. (Each RGB 8*8 Matrix has its own controller board) this would allow the every module to function completely on its own without any kind of overhead to the cpu! So every Controller baord would essentually need column drivers and 1 row driver. I was thinkings something like a 18F88 or similar 40Mhz chip to do the processing. I also would assume I need jfets to actually drive the display.

In the End a complete unit would have a 1 RGB Module and 1 driver board and I would be able to have 16million colors (256 Grey Scaling)


Any help would be great!

I am including a picture that is not mine in this forum. It is a design that a guy named mike worked on and I just wanted to include it in this forum because He really hit it home. I just want to do RGB and make the controllers more modular.. ( I use this word alot in here (modular) basicly what I mean is every controller is completely independant. they can run on there own.


aspforum.mchp.guest
#1

42 Replies Related Threads

    Ldanielrosa
    Super Member
    • Total Posts : 285
    • Reward points : 0
    • Joined: 2004/05/01 15:50:06
    • Location: Bellingham, WA. Usania
    • Status: offline
    RE: RGB 8*8 Matrix design help! 2005/11/04 14:10:26 (permalink)
    0
    I'm looking to do someting similar, but but not bound to 8*8 or RGB. My idea involves charlieplexing 17 pins for as many as 272 LEDs. I'm not looking for 256 graduations in intensity, 16 will do well.

    Two of my hurdles are likely to include reasonable brightness with a 1/17 duty cycle (and not frying the LEDs with high current pulses), and a reasonably flexible driver that doesn't take too much space.
    #2
    Guest
    Super Member
    • Total Posts : 80504
    • Reward points : 0
    • Joined: 2003/01/01 00:00:00
    • Location: 0
    • Status: online
    RE: RGB 8*8 Matrix design help! 2005/11/04 14:21:13 (permalink)
    0
    What is your project? What kind of design are you trying to make? 1/17 duty cycle may give you very low brightness results. maybe you could consider running less but use the same number of pins!

    what exactly are you trying to do?
    #3
    DSchabel
    Super Member
    • Total Posts : 1714
    • Reward points : 0
    • Joined: 2005/05/24 14:00:34
    • Location: Western NY State
    • Status: offline
    RE: RGB 8*8 Matrix design help! 2005/11/04 14:34:17 (permalink)
    0
    ORIGINAL: AutoX Systems
    In the End a complete unit would have a 1 RGB Module and 1 driver board and I would be able to have 16million colors (256 Grey Scaling)

    That's going to be tough. And expensive.

    You'll need something that can control the current drive at 8 bits' resolution for each of 24 channels on each board; in other words, 24 8-bit DACs with 24 voltage-to-current conversion circuits (assuming a voltage-out DAC; otherwise you'll need 24 current amplifiers).
    #4
    Guest
    Super Member
    • Total Posts : 80504
    • Reward points : 0
    • Joined: 2003/01/01 00:00:00
    • Location: 0
    • Status: online
    RE: RGB 8*8 Matrix design help! 2005/11/04 14:43:47 (permalink)
    0
    couldn't I just use PWM? Lets say I scan the screen at 60Hz I could use pwm on each output to control its brightness no?

    I would sure like to figure out how the companies out there make those large video screens. I do believe I should use a 8 bit resolution DAC or I have been suggested in the past to use a DM136(16Bit) or a TICB595 per R,G,B
    #5
    DSchabel
    Super Member
    • Total Posts : 1714
    • Reward points : 0
    • Joined: 2005/05/24 14:00:34
    • Location: Western NY State
    • Status: offline
    RE: RGB 8*8 Matrix design help! 2005/11/04 15:02:53 (permalink)
    0
    ORIGINAL: AutoX Systems

    couldn't I just use PWM? Lets say I scan the screen at 60Hz I could use pwm on each output to control its brightness no?

    I suppose this is theorically possible. But let's run the numbers. First, let's refresh at 30Hz (more than sufficient). Then, for each of the 8 scan rows (meaning that you have 1/240th second), you need to update 24 different PWMs simultaneously.

    So, your TOTAL period for any bit is 4,166usec, and you have to have granularity of 1/256 of this to get your 8-bit resolution. Therefore, your PWM granularity must be 16.3usec. In this time, you have to control the output for 24 different PWMs (8 columns x 3(RGB)), including all the overhead.

    That's a pretty tall order. Perhaps if you drop off the LSB and just use 7 (or even 6) bits of granularity for each. Then, IF you had a dedicated PIC for each 8x8x3, you just might be able to get away with it. Believe me, no one would ever notice 2,097,152 or even 262,144 colors as opposed to 16M. There will be far more variability in the individual LED outputs than 1/128!

    Besides, you could actually store the data in the PIC's memory this way: 8x8x3 = 192 bytes.
    < Message edited by DSchabel -- Nov. 4, 2005 5:04:24 PM >
    #6
    K8LH
    Super Member
    • Total Posts : 1887
    • Reward points : 0
    • Joined: 2004/03/26 05:12:34
    • Location: Michigan, USA
    • Status: offline
    RE: RGB 8*8 Matrix design help! 2005/11/05 08:00:26 (permalink)
    0
    Hi Dale,

    Gosh, those are incredibly ambitious design goals... The multiplexed wiring on those particular displays is going to be a limiting factor for PWM or D2A drive as it more or less imposes a 12.5% duty cycle and as soon as average PWM drive on the R, G, and B elements making up a pixel becomes less than about 70% you won't have usable brightness (I'm guessing on that percentage)...

    Would you consider scaling down your design? A seven color moving message display (see primary colors below) would be relatively simple using hardware similar to my single color moving message design... That is, a processor, p-channel row drivers, and in your case three '5841A or similar sinking column drivers for the 24 columns (8 columns with R, G, and B elements)... Use 2-msec interrupts and 'scan' rows of 24 LEDs one at a time for a 16-msec overall 'scan' period (62.5-Hz Refresh Rate) and 12.5% LED duty cycle (anything over 10% should provide acceptable brightness)...

    If you absolutely must have more than seven colors then keep the 2-msec row 'scan' period but split it in half using 1-msec interrupts and you'll end up with 00%, 50%, and 100% PWM for any individual LED to produce more colors... Caveat -- efficient data/color/bit managment is starting to become a problem at this point...

    And if you need still more colors, split the 2-msec row 'scan' period into four by using 500-nsec interrupts for 00%, 25%, 50%, 75%, and 100% PWM on any LED... Caveat again -- data/color/bit management nightmare and some colors with average PWM rates on the R, G, and B elements less than about 70% just won't be bright enough (again, I'm guessing on that percentage)...

    Best luck on your project... I think it would be neat if someone could show us how to get those 16 million colors using this type of multiplexed display...

    Regards, Mike
    < Message edited by K8LH -- Nov. 5, 2005 11:03:11 AM >

    Attached Image(s)

    #7
    Guest
    Super Member
    • Total Posts : 80504
    • Reward points : 0
    • Joined: 2003/01/01 00:00:00
    • Location: 0
    • Status: online
    RE: RGB 8*8 Matrix design help! 2005/11/05 11:50:14 (permalink)
    0
    Wow, I haven't logged on for 36 hours only, and such interesting threads flourish. Hope it's still time to hop in.

    Looks like the time is ripe for full color dot matrix with PIC. I am working on such a design also.

    First design constraints, like DSchabel and K8LH pointed out, are drive complexity and physical interconnect complexity.

    Simple analisys show that to drive a reasonably large display with full color (like more 12bit pixel depth or more) rises the project complexity to a point that it requires completely new approaches.

    I agree with K8LH in that driving a simple primary color or maybe 1/2 duty primary is still in the bounds of the shift-store column drivers.
    Compared to the monochrome design:
    Memory requirements: 3 to 6 times the framebuffer size;
    2 topologies of column drivers:
    A) - 3 strings of SPI-driven col drivers, for R,G,B bits;
    B) - A single serial string that aligns 8R, 8G, 8B bits for each module (better);

    The PWM approach is awkward, because it is really a dithering. The rows have to be scanned in a substantially higher frequency than in monochrome. You have to maintain a pixel PWM cell frequency higher than 50Hz, or you will have bad color flickering and visual mouaret patterns.
    For a 400Hz frame refresh, we can update each pixel 8 times within that 50Hz cell.
    This would allow a 9-bit RGB, or roughly 500 colors. Some code combinations, especially the yellows and purples yield the same apparent color, so the number of distinct colors is always lower than the pixel depth may suggest.

    To efficiently implement the scan-refresh routine, the framebuffer probably needs to be 'layered', with each pixel depth stored as a full framebuffer array, much alike the first EGA/VGA internal memory organizations.

    Now, at 10MHz SPI clock, assuming 900ns per byte, we can have a column fill in ~100µs, for a 256 pixel line, giving some slack for function call, FSR incrementing, etc. At 400Hz each row has 312.5µs time to be filled, so it seems that we have enough bandwidth to do the refresh (32% of processor load).

    The above is for a PIC18 running at 40MHz. If you use a dual SPI engine + dual USART, you can interleave 3 arrays of serial streams in roughly the same 100µs, since each byte takes 8 instruction cycles. So it sounds reasonable to use this PWM topology with a 24x256 pixel panel, or a 48x128, for example.

    Framebuffer memory is another story: A single module of 8x8 RGB dots with 9bit pixel depth requires 576 bytes of RAM buffer space. So, if we set aside 2880 bytes of RAM for the frame buffer, we can have 5 modules, or a 8x40 pixels display. Not much.

    These numbers show clearly that any serious RGB graphics with PICs require a external memory bus, and probably another strategy of pixel drive.
    I am experimenting with a PIC18F8722 with 128KB of external RAM to implement the framebuffer, and using SPI for the column drive. The use of external RAM means that getting the pixels take more time, using TBLRD*+. But the simplicity of the column drive makes it tempting to implement this way.

    The other approach I will try is to use the external memory bus driving the data directly into a XILINX FPGA, that either drives the pixels or uses multiple high-speed SPI buses to stream the framebuffer to other FPGAs local to the dot matrix modules, and drive the LEDs with current DAC or local PWM. The FPGA approach, with the internal distributed RAM, have the advantage of implementing color correction curves for the display at the local LED drive level. But of course, one has to ask what is left of the PIC in this FPGA case.
    < Message edited by j_doin -- Nov. 5, 2005 3:53:06 PM >
    #8
    Guest
    Super Member
    • Total Posts : 80504
    • Reward points : 0
    • Joined: 2003/01/01 00:00:00
    • Location: 0
    • Status: online
    RE: RGB 8*8 Matrix design help! 2005/11/05 11:57:44 (permalink)
    0
    ORIGINAL: DSchabel

    Besides, you could actually store the data in the PIC's memory this way: 8x8x3 = 192 bytes.

    Actually, if you have 3 bits per {R,G,B}, it will be 8x8x3x3: 576 bytes.
    8x8 pixels
    3 LEDs
    3 bits per LED.

    This would give you 512 colors per pixel, or ~500 discernible colors, depending on the color sensitivity of the observer.

    /EDITED:

    DSchabel, you are correct, sorry for my imbroglio!
    With 192 bytes you can have 256 levels of R,G,B fields, or 24bits per pixel.
    For my proposed 9bits/pixel {3R,3G,3B}, it would need 72bytes for a 8x8 pixel matrix, not 576bytes as I said before.
    < Message edited by j_doin -- Nov. 5, 2005 8:34:02 PM >
    #9
    Guest
    Super Member
    • Total Posts : 80504
    • Reward points : 0
    • Joined: 2003/01/01 00:00:00
    • Location: 0
    • Status: online
    RE: RGB 8*8 Matrix design help! 2005/11/05 16:01:55 (permalink)
    0
    AHH Yes!

    So much information! I all sounds good but I'm even considering using a very special Maxim chip. Look at the data sheet for this chip! MAX6960-MAX6963. The chip allows for 256 step panel intensity control (good for fading out the display or matching) and it incorperates a 4 step color pixel level intensity control. Plus much more. I have not went through this data sheet with a fine tooth cobm but I did print it out about 4 months back and held onto it becasue it seamed proper for a project of this intensity. It seams all in one but I just seams to easy! They are not cheep but cutting tinto the pricing of other discusions you sarafice $ for time.

    Take a look at the datasheet:
    http://www.autoxsystems.com/documents/MAX6960-MAX6963.pdf

    With just the right drivers I think this is going to be the IC I want to use.

    It would be rather simple to create a display using on 7 colors. The (Byte count) would be low and the amount of overhead used by the processor and ram at a minimium.

    I just thing that even having 4-5 levels of brightness 0%, 25%, 50%, 75%, 100%. you really wouldnt need to have anything more.

    I can tell you right now I do not know of any company trying to manufacuture smaller RGB message systems. Even if you only used 4 levels you could still get ruffly 128 colors. THATS PLENTY for this type of project.

    Sorry Guys 16 million really is a high goal to set! BUT if you put that out in the open the feed back you get puts things in better perspective.

    Any one have any idea as to how to drive the RGB display? I am actually not very familiar with jfets. I have never used them before. does any one have a sample schematic of there 8*8?

    I think that timing will not be that much of a problem. I'm sure that a 18F running at 40 to 48 Mhz will give me enough room to run a "Caveat"

    As our code developes I'm almost positive that in the beginning we could have just 7 colors but as advancements in out firmware we can always upgrade to some sort of PWM manipulation.

    Look over that datasheet guys and give me some feed back! if you think it is a waste of time and it would probebly be easier to design a micro to do the same thing then I'll try!
    #10
    Guest
    Super Member
    • Total Posts : 80504
    • Reward points : 0
    • Joined: 2003/01/01 00:00:00
    • Location: 0
    • Status: online
    RE: RGB 8*8 Matrix design help! 2005/11/05 16:20:57 (permalink)
    0
    I think that I'm just going to try and use Mikes desing but multiply it by 3 to make the display at least usable with 7 colors.

    I'm almost positive that I will have the capabilities to upload new code into the PIC's to update for brightness control in the future.
    #11
    Guest
    Super Member
    • Total Posts : 80504
    • Reward points : 0
    • Joined: 2003/01/01 00:00:00
    • Location: 0
    • Status: online
    RE: RGB 8*8 Matrix design help! 2005/11/05 16:58:42 (permalink)
    0
    Hmm. Nice driver.
    For RGB you need 3 streams of drivers, like my suggestion above. The datasheet shows that to sustain 50frames/s with 256 drivers you need 10MHz SPI clock, like our calculations above.

    The nicest thing about it is that it generates a local frame refresh and have control of up to 256 PWM levels per pixel.
    The memory update is another story. I think you will need local framebuffer for things as text rasterization and animation.

    One idea to reduce the on-chip memory requirements is to work locally with one-bit depth framebuffer for the text, and add the text color on-the-fly, during raster transfer to the drivers.
    #12
    Guest
    Super Member
    • Total Posts : 80504
    • Reward points : 0
    • Joined: 2003/01/01 00:00:00
    • Location: 0
    • Status: online
    RE: RGB 8*8 Matrix design help! 2005/11/05 17:05:18 (permalink)
    0
    ORIGINAL: AutoX Systems

    I think that I'm just going to try and use Mikes desing but multiply it by 3 to make the display at least usable with 7 colors.

    I'm almost positive that I will have the capabilities to upload new code into the PIC's to update for brightness control in the future.

    I think this approach is sensible. My first prototype will have this approach also, with some small changes.
    I will use a 74HC594 and use the /STCLR pin to implement a hardware fade-in/fade-out | brightness control. With a PIC PWM synced at the line refresh frequency you can have the brightness of the row to be modulated by the CCP output of the PIC, yielding nice fade-in / fade-out effects. I already do this with my 16F873A-based monochrome panel by software with a 16-level brightness and it is totally practicable using the CCP hardware.
    #13
    Guest
    Super Member
    • Total Posts : 80504
    • Reward points : 0
    • Joined: 2003/01/01 00:00:00
    • Location: 0
    • Status: online
    RE: RGB 8*8 Matrix design help! 2005/11/05 17:40:52 (permalink)
    0
    Ahh YES!

    The Lovely 74HC595. I have always likes this chip due to its low cost! running somewhere between $0.29 piece to $0.20 piece. I don't think I completely follow you on how you use the Clear pin to create a brightness control?

    Can you explain it a little bit more indepth? do even a baby could understand it?

    I was thinking of this driver: I have worked with it before and I think If I just make my modules larger 8*16 I could use 3 drivers to control 2 RGB Matrix's.
    These drivers run about $1.70 piece. 3 drivers is suitable pricing for this project. They operate much like a 74HC595 but have high current outputs:


    http://www.st.com/stonline/products/literature/ds/10155/stp16cl596.pdf

    I could use 1 chip per R,G,B. It also offers an adjustable current input... This would help trim the display in to displaying proper "white light" when all led's are illuminated. You make like this little device!

    I wanted to stay small modules 8*8's but this is looking like the driver I will actually use. Plus its readily available!

    I would like to use 74HC595's but I don't think they will take the current load of the blue diac's.
    < Message edited by AutoX Systems -- Nov. 5, 2005 6:49:44 PM >
    #14
    Guest
    Super Member
    • Total Posts : 80504
    • Reward points : 0
    • Joined: 2003/01/01 00:00:00
    • Location: 0
    • Status: online
    RE: RGB 8*8 Matrix design help! 2005/11/05 17:43:14 (permalink)
    0
    Also check out this little project. It does not use multiplexing but it does show how to control an array of High Current LED's

    http://www.st.com/stonline/products/literature/an/11313.pdf
    #15
    Guest
    Super Member
    • Total Posts : 80504
    • Reward points : 0
    • Joined: 2003/01/01 00:00:00
    • Location: 0
    • Status: online
    RE: RGB 8*8 Matrix design help! 2005/11/05 22:13:34 (permalink)
    0
    The PWM brightness control is like this:


    For a 100% brightness:
    At start of each row scan:
    Fill the column drivers with the current row values;
    wait for the next row time
    repeat for next row.

    For a 50% brightness:

    At start of each row scan:
    Fill the column drivers with the current row values;
    wait for 50% of the row time;
    clear the current column drivers (pull down the /STCLR lines)
    wait for the rest of the row time;
    repeat for next row.

    So, if you place a CCP PWM output at the /STCLR lines, you can 'sweep' the ON time of the rows from 0 to the full row time, in 256 steps of brightness. If you make this sweep as a ramp, you achieve very soft fade-ins and fade-outs.
    < Message edited by j_doin -- Nov. 6, 2005 2:14:03 AM >
    #16
    DSchabel
    Super Member
    • Total Posts : 1714
    • Reward points : 0
    • Joined: 2005/05/24 14:00:34
    • Location: Western NY State
    • Status: offline
    RE: RGB 8*8 Matrix design help! 2005/11/07 08:34:16 (permalink)
    0
    ORIGINAL: j_doin

    Hmm. Nice driver.
    For RGB you need 3 streams of drivers, like my suggestion above. The datasheet shows that to sustain 50frames/s with 256 drivers you need 10MHz SPI clock, like our calculations above.

    j_doin, do you really think 50 frames/sec is necessary? Color television has gotten by very well with 60/50 frames per second, interlaced so that the actual refresh rate is 30/25 frames/second. Wouldn't 30 or even 25 be sufficient?
    #17
    Guest
    Super Member
    • Total Posts : 80504
    • Reward points : 0
    • Joined: 2003/01/01 00:00:00
    • Location: 0
    • Status: online
    RE: RGB 8*8 Matrix design help! 2005/11/07 09:30:39 (permalink)
    0
    ORIGINAL: DSchabel

    ORIGINAL: j_doin

    j_doin, do you really think 50 frames/sec is necessary? Color television has gotten by very well with 60/50 frames per second, interlaced so that the actual refresh rate is 30/25 frames/second. Wouldn't 30 or even 25 be sufficient?

    Well you have a good point there.
    I drew my estimative of 50 frames/s as a result of experimentation with a monochrome RED dot matrix graphics panel, with animation (text roll/scroll). The animated text is much 'smoother' when refreshed at high rates. At 200Hz (200 frames/s) the text seems 'painted' on the LEDs, i.e, you can detect no flicker at all. I tested at 100Hz, 85Hz, 75Hz, 60Hz, 40Hz, and 30Hz. Below 75Hz I can distinctly see the animation flicker. At 60Hz I can see static text flickering if I run my eyes on it, like normal reading eye scanning, if I place the panel at 50% brightness (using 50% PWM on the rows). At 85Hz, even at 10% brightness the text is solid. All the above tests used a carefully handcoded refresh routine, with CCP hardware based timings, and verified to be very low jitter (50ppm).

    In color television, you have 25frames/s (e.g., in europe) or 30fps (america). But the frame is divided into 2 field scans, so the eye is presented with a 50Hz or a 60Hz image. Moreover, since the field is interlaced, the change in content from field to field is minimum, so you never have sharp cuts during normal scene viewing, but a 'blending' of images. This spacial blending work together with physiological retinal persistence to present a smoothing of the images.

    In non-interlaced video systems, eye tolerance of 60Hz screen refresh is much lower than for television. A good example is VGA noninterlaced mode. If you configure your board to output 60Hz NI video it quickly becomes unbearable for most people.

    It is relatively easy to find people with fast retinal receptors that can trigger at 40Hz. Some people can even perceive distinctively a 60Hz flicker. Of course, the fastest receptors are away from the fovea, so this flicker can best be seen at the peripheral vision field.

    Another thing is that a LED is a very fast device, showing almost no turn-off delay. This means that PWM excited LEDs fully turn off in a matter of microseconds, leaving only retinal persistence to build the temporal smoothing effect. On any color TV, you have phosphor permanence to aid in this temporal filtering. For instance, if you use a high-performance graphics monitor and use it at 60Hz VGA, the flickering is much more perceptible than on an old VGA-only monitor, that have a much higher persistence phosphor.

    So, I think that for reasonably confortable viewing a 50fps would be minimum. But I'm drawing estimatives from personal experience here, and I still did not test with RGB LEDs, so you may end-up being right on this.
    < Message edited by j_doin -- Nov. 7, 2005 1:36:37 PM >
    #18
    Guest
    Super Member
    • Total Posts : 80504
    • Reward points : 0
    • Joined: 2003/01/01 00:00:00
    • Location: 0
    • Status: online
    RE: RGB 8*8 Matrix design help! 2005/11/07 09:41:28 (permalink)
    0
    ORIGINAL: DSchabel

    [...] 30 or even 25 be sufficient?

    Another point in the discussion: I discovered that for higher resolution (or far viewer positioning) if the refresh is 'interlaced' the flicker is a little bit smaller.

    When I do the refresh using rows {0,2,4,6,1,3,5,7} the text is much more 'solid' at a given rate than when using the {0,1,2,3,4,5,6,7} sequence.
    #19
    DSchabel
    Super Member
    • Total Posts : 1714
    • Reward points : 0
    • Joined: 2005/05/24 14:00:34
    • Location: Western NY State
    • Status: offline
    RE: RGB 8*8 Matrix design help! 2005/11/07 09:44:40 (permalink)
    0
    ORIGINAL: j_doin

    ORIGINAL: DSchabel

    [...] 30 or even 25 be sufficient?

    Another point in the discussion: I discovered that for higher resolution (or far viewer positioning) if the refresh is 'interlaced' the flicker is a little bit smaller.

    When I do the refresh using rows {0,2,4,6,1,3,5,7} the text is much more 'solid' at a given rate than when using the {0,1,2,3,4,5,6,7} sequence.


    Darn it! You beat me to it again! grin

    I was thinking this very thought while reading your post above.
    #20
    Page: 123 > Showing page 1 of 3
    Jump to:
    © 2021 APG vNext Commercial Version 4.5