LED Video Screen/monitor
Areal Person
Posts: 197
·
Could someone tell me what would be involved with building a multi LED video display
(320 x 240 or smaller) circuit (like for a led video monitor etc.)? Should I use the video signal for this or something else.
·
How would I go about doing this with the propeller ? Is it possible ? What general type of circuit would be needed ? TI and others have 16-channel RGB drivers with DOT correction (TLC5940NT) etc.. Would I use these in the circuit along with the prop chip ? This would be just for displaying images on the LED matrix, like a slide show, not full motion video.
·
·
Thanks,
-Areal
Could someone tell me what would be involved with building a multi LED video display
(320 x 240 or smaller) circuit (like for a led video monitor etc.)? Should I use the video signal for this or something else.
·
How would I go about doing this with the propeller ? Is it possible ? What general type of circuit would be needed ? TI and others have 16-channel RGB drivers with DOT correction (TLC5940NT) etc.. Would I use these in the circuit along with the prop chip ? This would be just for displaying images on the LED matrix, like a slide show, not full motion video.
·
·
Thanks,
-Areal
Comments
You're insane.
I was thinking 5mm LED's (Actually, they make whats called a LED "Lamp" that uses some kind of filament
not electron generated photon) It would need to be segmented design, say 16x16 pixel groups (or so)
seems to me the design needs to be segmented, scalable with some kind of synchronization betewwn
pixel groups that are cooradnated by the processor(s) that are mapping the display signals.
How does that sound ? What do you think
-Areal
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
Post Edited (Paul Baker (Parallax)) : 11/16/2006 10:59:28 PM GMT
just ask daktronics.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
But what general type of circuit would be required to actualy transfer the image/image pixel(s)
from the memory (SD, Modified RAM, Hard drive or whatever) so that the proper LED was
turned on (or mapped, whatever) to the source image pixel located on the SD ? Should it be
some kind of memory mapping circuit ? or should it be somthing else ?
Does it just need to be serial ? or is there more to it than that ?
"discrete drivers" Whats that ?
I'm not concerned about cost as long as the solution will scale, that way I can spend what I want to.
Thanks
-Areal
Post Edited (Areal Person) : 11/17/2006 12:22:40 AM GMT
Check out the Good thread index. Especially the 3rd message down under 'Programming bits' you get to SD/MMC cards.
Paul.
8x8 tri-color LED matrix.· might make the physical design easier.
http://www.sparkfun.com/commerce/product_info.php?products_id=760
the above matrix plus a serial controller.
Post Edited (Lawson) : 11/17/2006 3:29:15 PM GMT
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
Did you look for MAX6974/6975 ?
Those are very cool drivers for big LED screens.
Regards.
Alberto.
prop demo board to come in, then I going to start working with the LED driver chips.
I've got to figure out how the memory buffer that holds the the image is going to map
to the actual LED's on the big display. I'm not sure if the word "map" is the correct term.
For example, lets say that I have a picture of a bird or whatever loaded into memory.
The LED video controller must use that image to Illuminate each LED so that there is a picture.
What I'm trying to figure out in general is what kind of circuit(s) does that job. And what is the best
way to implement it. Can anyone answer that question ? Maybe an electronics expert ? Can I just
use NTSC ? I dont think so. but what would I use?
Thanks,
-Areal
Areal, it depends on the format of your image(s). Since you want to do a slideshow, you are going to need to use some external memory like a SD/MMC card. Since these have alot of capacity (and hence space isn't much of an issue), you should choose a non-compressed format such as BMP. Here is a brief page describing how the format is organized. You would use the 24 bit color option which permits any color for each pixel. You would read off the data from the memory interface row by row and feed them out to your drivers. All thats required of the Propeller is to fetch the data from the memory card, rearrange the data into the format expected by the drivers, then send the data out to the drivers. If you design the chain of drivers correctly, the only amount of rearrangement that should be (possibly) necessary is the reording of the rgb bytes. IOW the mapping basically boils down to how you organize the drivers and thier associated LEDs, you should mimic the way BMP does it as much as possible to make it easier on you software-wize.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
your right, I think I was over complicating somewhat. What about an async serial data stream LED driver
that could switch a data packet based on the address it contained. That way the driver could
route the color information to the correct LED. The packet might look like this.
(START 0x81)(RED PWM)(GREEN PWM)(BLUE PWM)(ADDR)(CHECKSUM)
The START just starts a new packet
The next three frames are the color info
The formated address for switching
The checksum (2's complement of the sum of the other frames, modulo 256).
and some pseudo assembler might look like this.
movlw 0x81
addfw RedPWM, W
addfw GreenPWM, W
addfw BluePWM, W
sublw 0x00
movwf chksum
Do you think I could get it fast enough to work ?
if so, what kind of switching circuit would I use for the routing ?
And, could I not tie this circuit(s) directly into the Propeller(s)
and that work ?
-Areal
Post Edited (Areal Person) : 11/20/2006 8:24:34 PM GMT
But a little suggest.....
To show video in 320x240 (ie) with this format.... (START 0x81)(RED PWM)(GREEN PWM)(BLUE PWM)(ADDR)(CHECKSUM)
·you'll need· about 12/14 bits per pixel (MAX6974/75) per color RGB, more the start bits, by 320*240 pixels, by 25 or 30 times per second (fps)....
so basically a lot of bytes of info per frame, at a very high pixel frequency..........think...
I·think BMP could not ·be a good idea......sorry... You're right Paul.
Regards.
Alberto.
·
Strive onward, dude.
You'll need at least 60deg LED or more.....( each pixel making a triangle ....one with the vertex of the triangle up, and the next down...that could be one choice).
In a 256x192 pixel screen, the distance between pixels about 15mm is fine.
Regards
Alberto.
http://www.mvd-fpga.com/en/produitsECRAN.html?gclid=CPiNm-3epoYCFQpbUAodBkEgEQ#caract
Regards.
Alberto.
I think it is very possiable to do this with the propeller. However, thats currently just my
opinion. And its based on everything I've read. We still have allot of lab work to do.
I'm trying to get enough information together to design and prototype a scaled version for a proof
of concept. We'll have a website in a few weeks (I hope) and I'll post it so everyone can see whats going on.
So everyone please, please continue to post resources, ideas & suggestions about how to pull this off using
the propeller, And I'll keep everyone up to date on progress.
It looks like this project will be going forward.
Thanks again.
-Areal (Mark)
But at this point...I would like,·if Paul Baker, could explain, or give a link where read.·Why is so difficult ??·to·manage the LVDS signals.
It's about talking of the PCB design ? or what ?????.
In the other side ..... I think could be useful at this time, to begin·to think in a frame grabber....
Regards.
Alberto.
We're waiting for your explanation..!!·
Regards.
Alberto.
Not technical info, but interesting.
Please, read this comment by me ... (Sent 22/11/2006) in this thread..
Thanks.
Alberto.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
Sorry, LVDS use was eating my mind....
Regards.
Alberto.
I'd suggest if you're going to do still images - decide on your color depth (8-bits per color to 16-bits per color), then find a dual-port RAM that will fit your frame (this will be your frame buffer). For 8-bit color depth at 320x240, you'll need about 2MB. Next you'll want to figure out your refresh rate (Film-like 24/25Hz, PAL-like 50Hz, or NTSC-like 60Hz). You need to make sure your memory is fast enough to dump its contents within that time frame. For the 320x240 resolution at 60Hz, you'll need memory that has at least 13MHz 8-bit wide bandwidth (you want more headroom so that timing constraints aren't a pain in the butt).
This way you can write to the memory at the processor's pace, and the display can use the pixel information at its pace (and they will be different
I'd also suggest looking into some Xilinx CPLDs and creating your own 12-channel PWM generator. I built a 4-channel PWM generator's logic in MS Excel for demonstration purposes (16-bit input bus, an address decoder, [noparse][[/noparse]4] 16-bit data latches, 4 channels of 16-bit depth comparators [noparse][[/noparse]driving output pins, and a 16-bit counter and input clock divider), so it's not too hard to do - but you need to learn VHDL to use the Xilinx stuff.
The ammount of power this will draw may also shock you... unless you can multiplex the "pixels" (think of it - 3 [noparse][[/noparse]red, green, blue] LEDs @20mA each [noparse][[/noparse]assume 2.25 volts for all] X 320 wide X 240 high = 10,368 Watts!!)
-Tim
Post Edited (GreyBox Tim) : 12/1/2006 9:50:44 PM GMT