I have told Gerald that I would create a set of LCD interface boards to bridge between Rev. C and a select set of panels.
Right now, I am planning on interfacing to an 640x480 6.4" NEC display, and a AUO 7" WVGA display (same display used in the raw LCD documentation on the elinux wiki). If there are other widely used panels I would consider interfacing to those as well.
Please reply back if there are particular panels that you would like to see supported.
Interfacing to this display is not a matter of simply level-shifting the
LCD lines. This is a LVDS interface and the lines would need to be
serialized in the right bit pattern.
I doubt that I do this one unless someone wants to pay for the
engineering time and/or there is a large concrete demand.
Let me know if you're willing to explore implementing this display further.
From: beagleboard@googlegroups.com
[mailto:beagleboard@googlegroups.com] On Behalf Of Keith Williams
Sent: Wednesday, January 14, 2009 12:41 PM
To: beagleboard@googlegroups.com
Subject: [beagleboard] Re: LCD interface boards
Do you have a spec or datasheet for this? I'll definitely take a look
at it.
From: beagleboard@googlegroups.com
[mailto:beagleboard@googlegroups.com] On Behalf Of Leandro Gentili
Sent: Wednesday, January 14, 2009 2:31 PM
To: beagleboard@googlegroups.com
Subject: [beagleboard] Re: LCD interface boards
This LCD has not Touchscreen included. The small connector is for
backlight
led. You can find a touch screen for this lcd in sparkfun for $23.95
Leandro, thanks for letting me know. I thought the little connector was the
touchscreen, but after looking at the specs, you are right; this is for the
backlight LED. So, the touchscreen part number is HT043A-NCOFD52 and the
specs are available here:
Hello Keith,
I'm using this board from Olimex [1]. The board use a "LCD 3.5"
320x240 24bit color TFT color with backlight and touchscreen "
There are some specs file on the site: [2][3]. (thanks to Olimex that
post this info)
The LCD looks very good and small to fit on top of the beagle board;
but I'm only use it, and I don't no if it's ease to find on digikey or
farnell, and how mutch it cost.
I am interested in a REVC board to run and learn about Ubuntu and ARM
as I see it as a forthcoming popular netbook platform. I will want to
run and develop code using MySQL.
I am looking to build a standard silver box containing the Beagleboard
and a powered hub in the base and a LCD screen or panel in the lid
running at at least 1024x768 which is what I run my 17" monitor at.
Would you be supporting a LCD panel at this resolution?
The REV C2 board will support all the same resolutions as the current and earlier boards. It has the added feature of a header that provides the raw LCD signals for use by expansion cards. These are the same signals that drive the TFP410 DVI-D framer device on all of the boards today.
I have not found a definitive statement about the resolution and
refresh rate available out of the S-video port.
I want to take 1.3MP web camera input, do some processing on a set of
images, and output video on a near-realtime basis.
There is some doubt as to whether the actual DVI-D/LCD resolution is
1280x1024 or 1024x768 expressed on some posts.
It appears 720px24 is supported, I presume on the DVI-D/LCD panel and
not on the S-video port.
The "Display Sub System" in the OMAP is very flexible - See chapter 15 in
the TRM. Basically the main constrain is that the maximum pixel clock
frequency is 75MHz according to the TRM page 2056.
As long you are running below this limit you can basically decide you output
resolution yourself (up to a maximum size of 2048x2048 AFAIR). It's
therefore possible to run either 1280x1024 or 1024x768 - It's "only" a
matter of SW...
The HW can do 2048x2048 resolution, but at lower refresh rates. The actual resolution is of course determined by the support eh SW running can provide. depending on the video CODEC that is used, this resolution can vary. It does to 720px24. It can also do 1024x768 and 1280x1024. The limitation arises in the video CODEC that is used to provide that resolution when trying to perform for example an MPEG4 decode. If you just havea GUI for example siting there, then depending on the refresh rate a specific monitor can support, you are OK. If you want full screen video decode, the resolution would need to come down or you would need to provide the video in a window.
Other issues arise concerning certain monitors and their supported refresh rates. I you cannot support a specific rate needed for that monitor, it may not work where that resolution may work on another monitor will more flexible refresh rates being supported. native LCD panels are much more deterministic because you can fix it at the exact timing it requires. Monitors can have limitation based on what their front ends can handle.
S-video I believe would be limiterd to the 480p standard and I don’t think you Can get higher than that.