Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Help building 256 shades Monochrome LED Display

Status
Not open for further replies.

Bus Master

Full Member level 3
Full Member level 3
Joined
Dec 9, 2001
Messages
186
Helped
9
Reputation
18
Reaction score
3
Trophy points
1,298
Location
Just behind You ;-)
Activity points
1,455
pic18f monochrome lvds lcd

Hi all,

I'm building a 256 shades Monochrome LED Display, it's a 55 x 35 LEDs matrix.
I intend to use xilinx CPLDs for row PWM generation, an atmel 8051 member uC runs at 33 MHz and a 512 KB RAM chip. I have some questions:

1- Do i have to calculate the frame animation at runtime or i can simply download the whole frames from PC into system RAM?

2- How to apply effects online? i.e., shades

3- Using a xilinx X95108 CPLD, can i implement 7 PWM independent channels, 7 bits each? (This chip contains 108 macrocells).

4- Is a 25 frames/sec. good choice and not to be flickery?

Your help is highly appreciable as this is my first multi-shades LED display.

Yours,
 

mbi5026 +schematic

>Do i have to calculate the frame animation at runtime or i can simply download the whole frames from PC into system RAM?

Do the maths. 25 frames per scond means 48KB/second which can be sent out by a PC without much difficulty. Some buffering would be a good idea to avoid picture disruption when your multitasking operating system does somthing else for tens of milliseconds. You can store 272 frames in your 512KB RAM.

>How to apply effects online? i.e., shades
Do mathematics on the numbers representing each pixel.

>7 bits each?
256 shades with 7bits?

>Is a 25 frames/sec. good choice and not to be flickery?
Flicker will depend on the off and off periods of the leds rarther than the frame rate. 25 frames a seconds does not have to mean each led produces a burst of light 25 times a sconds, you could drive the leds faster than the frame rate.
 

    Bus Master

    Points: 2
    Helpful Answer Positive Rating
mbi5026 led matrix rgb eda

throwaway18:
Thank you very much for your reply. I've made a mistake, i'll use 7 bits to have 128 shades. I intended to use 256 shades (8 bits) but this would lead to more than 108 macrocells in the xilinx cpld, which will be of TQFP or PQFP package and i can not use this package in a (silk screen) made PCB for prototype.

Thank you very much.

To all,

Is there any design examples for a multiple shades LED displays? all i found in edaboard.com is a simple LED displays discussions. specially for implementing a PWM generator on a CPLD.

Yours,
 

japan pıc rgb 8x8 dot web

I do not know if i understand, but are you planning to create 256 gray scales.

The human eye only know the diference between 16 and 20 gray scales.

So, why 256 ?
 

monochrome shade

Because all commercial LED displays use this no. of grayscales, so, there must be a serious reason for this issue.

What do you think?
 

led panel fpga

Yes, the human eye is less sensitive to grayscales - but I assume that
your LED display doesn't produce gray light? :wink:
 

13 mm pixel pitch monochrome led display

This a little complicated way to make it. But worth the complexity. When we use the MOSFET's coupled with 1nF or so capacitor connected between Gate & Souce, much like DRAM cell, it remembers the analog voltage written to that for long enough time. So, it's just like write once & come back after certain time to refresh it. And the LED gives light proportional to the current through it, upto some extent. I cannot guarantee you that you can achive true 256 colour or gray shade display by this, but you can control the brightness of LED upto good level, by connecting it to the Source & VSS. Now, use some DAC & analog multiplexer combination to write through the array of MOSFET cells. Much like, CCD devices.

The better approach may be, to use this technique, write only when change is needed or refresh cycle is needed, which obviously reduces the flicker to a large extent, keeping the hardware & software complexity to a compromising level. The disadvantage is that it may cost you a quite good amount, as however cheap the MOSFET's are, you should use almost one for each LED.

Alternatively, you can use this approach for having one MOSFET for each column and when scanning across each row, change the required voltage level on the MOSFET input capacitor. This also is a good idea, but every cell you need to handle both DAC as well as scanning.

Another disadvantage of this is, you may not be able to show fast changing graphics on screen. Just like, a real time video, is difficult to display on a LCD monitor. Of course, the memory capacitor plays an important role, if you reduce the capacitor you can increase the trancient responce, but refreshing rate becomes high.

Added after 46 minutes:

I remember people using Linear power supplies for such display units. I am not sure whether SMPS still fails at that, but for sure it may cause interference with PWM. Hence I advice for a linear power supply of enough capacity. Are you scanning the entire board at once or deviding the entire board into small chunks and scanning them? In later case you need a bit large capacity power supply.

Regarding CPLD, I am not very strong there. :(
 

    Bus Master

    Points: 2
    Helpful Answer Positive Rating
vsm vidx.dll

Bus Master said:
I intend to use xilinx CPLDs for row PWM generation
I am not sure that a direct connection CPLD to LEDs is a good idea. I think CPLD will get warmed a lot because it have to provide a working current for each diode. It could be overloaded.
I think you should use specific LED driver ICs.
 

    Bus Master

    Points: 2
    Helpful Answer Positive Rating
proteus vsm model vidx.dll

:idea: Let concentrate at only one dot LED, to generate 256 shades color this means LED must blink at 256 times x 50 Hz = 12.8 kHz

Note that 50 Hz frequency is good enough for human eye

If you want to make a matrix of LED you have to flick whole frame at 12.8 kHz also. The circuit of this matrix would compose of Dual-Ram, DMA-like circuit to feed out data, one byte per one address and OR to 1 dot.

Another side of Dual-Ram, you might access by MCU or A/D.

All above is my imagination.
:cry:
 

    Bus Master

    Points: 2
    Helpful Answer Positive Rating
monochrome led panel

vrasak said:
Note that 50 Hz frequency is good enough for human eye
Believe me that 50Hz frame rate is not enough. LED has no persistency like CRT has. Human eye will feel a discomfort and get tired quickly. Don't forget that LED displays like signboards have a scan, thus the frequency must be multiplied on a number of lines.
Look at the photo. It is a simple signboard which has AVR microcontroller + Altera ACEX. AVR itself receives, store and process data from RS-232. ACEX chip contains embeded RAM. It was created 2 frame buffers there. But this sign board does't have a greyscale.
The next photo represents a full-color SMD LED module. It has 16M colors, 6 mm pixel pitch, brightness 1300 Cd/sq.m and a gamma correction circuits. The frame rate is 120Hz.
 

    Bus Master

    Points: 2
    Helpful Answer Positive Rating
monochrome led display grayscale usa

Hello YUV,

your work looks very impressive.

Can you give some more details of the work you have done.

regards
 

dot led rgb matrix driver fpga

I use XC9572 and TLC5921
 
  • Like
Reactions: kosta

    kosta

    Points: 2
    Helpful Answer Positive Rating
grayscale led matrix

Windom said:
Hello YUV,
your work looks very impressive.
Can you give some more details of the work you have done.
regards

Hi, Windom!

The signboard is quite simple, it's no sense to describe it.

The full color module has LVDS input inteface, ACEX chip (30K) which process data, and SRAM memory. Resolution of module is 64x64 pixels. It is possible to select a location of displayed area.
Several frame banks are organized in SRAM. Input frame rate is 60Hz, output (to panels) is 120Hz. Extra frames are used to make a smooth image and compensate moving artefacts. Output is fully synchronized with input, but the module will reproduce a picture even if input frequency is absent.
Also, I used 2 FIFOs - one between LVDS and SRAM and the second one between SRAM and LED panels.
LED panels have driver ICs, as usual. Each pixel consist of 3 diodes in a single SMD package.
 

tb62705

Great work brother!
Can You post the schematic for us?

Thanks a lot, Gorkin.
 

18f scan led dot

gorkin said:
Great work brother!
Can You post the schematic for us?
Thanks a lot, Gorkin.

Hi.
I don't think that the schematic itself is interesting. As for me, an architecture is more valuable. :D

Regards, YUV.
 

matix rgb proteus

PWM controlle Methode is compare digital video and Gray scale clock.
Or Each data weight multiply pluse width. 2 kinds methode.
 

led rgb proteus 6

Hi there,

I was interested to see that you're trying to make a 55x35 LED matrix. I'm currently building a tiny 16x16 green LED matrix, and will try to implement 16 shades at 25 frames per second, using a PIC 18F. I want to write some simple games for it, and might even try to get some anti-aliased 3D going :)

To reduce flicker, I'm actually going to flicker the LEDs at 25x15 fps. LEDs with a brightness of 1 will only be on during the first frame. LEDs with a brightness of 15 will be constantly on. LEDs with a brightness of 8 will be on every other frame:

I.E:
Code:
/- one frame -\
000000000000000    brightness 0
100000000000000    brightness 1
100000001000000
100001000010000
100010001000100
100100100100100
...
101010101010101    brightness 8
...
100010001000100
011110111101111
011111110111111
011111111111111    brightness 14
111111111111111    brightness 15


The LED code will be called by interrupt 6000 (25x16x15) times per second (once for each line of the display, and once for each shade of green).

A good way to buffer this kind of thing is to use a tripple buffer.
Buffer 0 is being displayed
Buffer 1 is waiting to be displayed
Buffer 2 is being rendered to

When Buffer 0 is finished displaying, Buffer 1 is "copied" (by pointer switching) into buffer 0.
When Buffer 2 has finished rendering, it is "copied" into buffer 1.

This is especially useful when you can't be sure how long the rendering will take.


> The human eye only know the diference between 16 and 20 gray scales
This is not true. Try taking a greyscale image, and reducing it to 16 shades in Paint Shop Pro. You can easily tell the difference. More shades looks better, but is computationally more intensive. 16 shades is probably enough if you only have a few pixels.


I hope this is of some help.

Hugo
 

    Bus Master

    Points: 2
    Helpful Answer Positive Rating
Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top