I have read a lot of documentation about using dual display on OMAP3x
board.
TI's Display Subsytem Datasheet says you can connect 2 RFB LCD on the
RFBI of the OMAP.
But RFBI LCD panel or RFBI component is for maximum VGA resolution,
and my application need a 7'' LCD of 800x480 pixels.
So cannot use the RFB protocol (MIPI DBI).
On the post of Koen Kooi (http://groups.google.com/group/beagleboard/
browse_thread/thread/115867f718b52e4b/4c64b2c614622053?
lnk=gst&q=dss2+overlay+panel#4c64b2c614622053), it is clear it can
handle 3 pipeline (1 graphic and 2 video) but the FB driver can be
used for 1 or 2 video pipeline.
So would it be possible to connect :
- a MIPI DPI (parrallel) LCD panel and link it to fb0
- a LVDS LCD panel and link it to fb1
???
Your idea is correct, expect that the LVDS connection would (most likely)
need to be made from a converter connected to the same parallel data bus as
the one you want to use for the MIPI DPI panel.
Depending on your needed frame-rate I currently see 3 options:
1) Parallel LCD interface + S-video
2) Parallel LCD interface + USB-video
3) Parallel LCD interface + SPI LCD
The Parallel LCD interface can by external HW be converted to DVI/HDMI, LVDS
or something completely third in case you don't want to use the raw signals
just as is...
I hope this clarified your question? - Good luck
Søren
It’s based on the Davicom 9601 chipset.
I read in the comments that there is a Linux driver available, but didn’t really think things through - of course they were talking about Linux on x86.
DM9601 Driver for Linux: http://www.meworks.net/userfile/24247/lnx_dm9601.rar
This driver is supplied in source form, but I can’t build it on the beagleboard as it can’t find the linux-headers that it needs.
I’ve built the image I’m running on the beagleboard using rootstock to create a jaunty image.
I’ve been able to install the build-essential package with no problems. I can’t install linux-headers-uname -r as it can’t find package find package linux-headers-2.6.29-oer44.1
When I run make to build the driver, t’s looking in /lib/modules/2.6.29-oer44.1/build - on the image I have, this is a symlink to /mnt/debian/v2.6.29-58cf2f1 which doesn’t exist in the filesystem.
I’ve looked around, trying to find a .deb for the linux-headers-2.6.29-oer44.1 package.
for your 3 solutions :
1/ S-video, hum I thinks it is not the good way to have a second LCD
480x800 in Frame buffer mode...
2/ USB-video, seems to be too heavy also
3/ So I need to find a SPI LCD in 7 inch with 480x800 resolution...
Hum, it will not be so easy at the end of the day...
I'm trying to get a USB Ethernet adapter working on the beagleboard.
I purchased one of the cheapest ones I could find http://www.dealextreme.com/details.dx/sku.2797
It's based on the Davicom 9601 chipset.
I read in the comments that there is a Linux driver available, but didn't
really think things through - of course they were talking about Linux on
x86.
It's already enabled/working in the 2.6.29-oer* series...
[ 23.452148] eth0: register 'dm9601' at usb-musb_hdrc-1.2, Davicom
DM9601 USB Ethernet, 00:10:13:50:a3:43
Plug it in and do a "sudo ifconfig -a", it's just really quiet and
never shows up in the dmesg...
BTW, that adapter gets pretty hot, careful where you place it..
can't install linux-headers-`uname -r` as it can't find package find package
linux-headers-2.6.29-oer44.1
It doesn't exist in ubuntu's repo, I've only recently began my attempt
to get it submitted upstream for 10.04...
(and when i was generating the linux-header package, it was broken for armel)
In fact this is the "last chance" option, but of course the simpliest
one as my application don't need the 2 fb to interact, just to have se
same application runing 2 time in the same time.
I just got a 6th idea, which I actually find great (and easy to implement in
case you are anyway going to do a HW add-on board to the beagle
Use two identical displays (attached to the parallel display interface) and
configure the Linux display buffer to be double the size of what you need.
Then you only need some simple logic for gating the H-sync signals going to
the first display for the first 480-lines and to the second display for the
last 480 lines.
You should easily be able to do this with a simple counter (counting on
H-sync and reset by V-sync) and a little logic, which all easily can be
implemented in a CPLD or similar
In Linux you then just need to configure the display as 800x(2x480) =
800x960, and use the upper/lower halves for the respective displays.
I hope my above idea was clear? - Good luck with the project
Søren
Another weird thing with that adapter. (haven't compared on x86) but
after a long period or running it starts having issues downloading
files and eventually takes the kernel down. I'm tempted to pack ice
around it for extra cooling to just compare..
I was thinking of removing it from the blue plastic case just to give it some better airflow - I'll keep your warnings in mind if/when it starts to play up. May even look into sticking some heatsinks on the chip(s) that generate the most heat.
I just got a 6th idea, which I actually find great (and easy to implement
in case you are anyway going to do a HW add-on board to the beagle
Use two identical displays (attached to the parallel display interface) and
configure the Linux display buffer to be double the size of what you need.
Then you only need some simple logic for gating the H-sync signals going to
the first display for the first 480-lines and to the second display for the
last 480 lines.
You should easily be able to do this with a simple counter (counting on
H-sync and reset by V-sync) and a little logic, which all easily can be
implemented in a CPLD or similar
This might not work with all LCDs. Some LCDs get upset if you play with the
timing this way. Also, not all LCDs use just H-sync/V-sync for timing. Gating
just these can really confuse the LCD. Check the datasheet for the timing
constraints.
Having said that, a slightly more complex muxing scheme might have a better
chance of working as it preserves the timing requirements for the LCD but it
requires convoluted software - Double your pixel clock (and the corresponding
line length, 1600 should be acceptable by the DSS) and interleave your video
data between the two panels. This might be doable in a fast PLD or a hand ful
of glue logic chips. Biggest drawback is you have to deal with your two frame
buffer in an interleaved fashion in software:
I totally agree, that you should of cause check with the LCD datasheet. That
being said, I think most LCDs (at least up to 4.3" - Where I have most of my
knowledge) would be able to work having a very long V-sync period - That
being said, many of these have internal memory, making them much less timing
critical than the larger LCDs not having internal memory...
I was as well first thinking about your idea, but discarded it due to the
SW-implications handling the interleaved pixels. One mix of our ideas might
however be worth considering as well. Namely muxing on a line-basis instead
of on a pixel- or picture-basis.
This will logically in the OMAP memory leave the two displays next to each
other (right left) as opposed to (top bottom), which again makes it easy to
handle in SW and gives a logic layout of 1600x480 as in your setup). This
however would required the display to be able to work with long H-sync
pulses instead of V-sync, as per my first suggestion...
So all in all: Instead of 1 idea, we now have 3 new ideas to investigate
> From: Hunyue Yau [mailto:ybeagle@rehut.com]
> Sent: Wednesday, November 11, 2009 8:58 PM
> To: beagleboard@googlegroups.com
> Subject: Re: [beagleboard] Re: dual LCD panel on OMAP3
>
> > Hi Georges,
> >
> > I just got a 6th idea, which I actually find great (and easy to
>
> implement
>
> > in case you are anyway going to do a HW add-on board to the beagle :-
>
> )
>
> > Use two identical displays (attached to the parallel display
>
> interface) and
>
> > configure the Linux display buffer to be double the size of what you
>
> need.
>
> > Then you only need some simple logic for gating the H-sync signals
>
> going to
>
> > the first display for the first 480-lines and to the second display
>
> for the
>
> > last 480 lines.
> >
> > You should easily be able to do this with a simple counter (counting
>
> on
>
> > H-sync and reset by V-sync) and a little logic, which all easily can
>
> be
>
> > implemented in a CPLD or similar
>
> This might not work with all LCDs. Some LCDs get upset if you play with
> the
> timing this way. Also, not all LCDs use just H-sync/V-sync for timing.
> Gating
> just these can really confuse the LCD. Check the datasheet for the
> timing
> constraints.
>
> Having said that, a slightly more complex muxing scheme might have a
> better
> chance of working as it preserves the timing requirements for the LCD
> but it
> requires convoluted software - Double your pixel clock (and the
> corresponding
> line length, 1600 should be acceptable by the DSS) and interleave your
> video
> data between the two panels. This might be doable in a fast PLD or a
> hand ful
> of glue logic chips. Biggest drawback is you have to deal with your two
> frame
> buffer in an interleaved fashion in software:
>
> Something like -
>
> P1P2P1P2P1P2....
I totally agree, that you should of cause check with the LCD datasheet.
That being said, I think most LCDs (at least up to 4.3" - Where I have most
of my knowledge) would be able to work having a very long V-sync period -
That being said, many of these have internal memory, making them much less
timing critical than the larger LCDs not having internal memory...
Well, a quick bench test is to run the LCD, then yank the clocks. If the
display melts, it is a good candidate for getting upset if timing is
deviated.
The other thing is even if it appears to work initially, there could be side
effects like degrading the LC part of LCD if the timing specs are violated.
I was as well first thinking about your idea, but discarded it due to the
SW-implications handling the interleaved pixels. One mix of our ideas might
however be worth considering as well. Namely muxing on a line-basis instead
of on a pixel- or picture-basis.
Pixel by pixel muxing might not be too bad given some of the NEON
instructions. The NEON talk from ARM alluded to single NEON instruction to
write to multple locations while handling the interleaving.
This will logically in the OMAP memory leave the two displays next to each
other (right left) as opposed to (top bottom), which again makes it easy to
handle in SW and gives a logic layout of 1600x480 as in your setup). This
however would required the display to be able to work with long H-sync
pulses instead of V-sync, as per my first suggestion...
Well, if the goal is to pamper the software folks...
Setup a FPGA to take the data in at 2x the pixel rate and buffer it while
simultaneously feeding each LCD so all the timing seen by the LCD is as
expected.
Well, if the goal is to pamper the software folks...
Setup a FPGA to take the data in at 2x the pixel rate and buffer it
while simultaneously feeding each LCD so all the timing seen by the LCD is
as
expected.
Another brilliant idea - Thanks for a great brainstorm...
Yet another variant of option 6 could be (if the displays do not use
all 24 bits) is to dedicate one DSS_DATA lines to the muxing. It is
synchronized with the pixel clock and sync...
So you just have to make sure the proper mux "picture" is stored in a
1-bit color channel in the framebuffer.
about the news solutions :
- multiplexing in line or colomn in the same fb will need software
trick after. My application will be a flash .swf file run by gnash (or
with the future Flash Player 10 under development). So how to make
runing 2 times the same application with an offset in the frame
buffer ? Maybe by doing a "double application" with the goods
dimensions, and runing just like it was independant... maybe
- sending at twice rate the data to a FPGA who will redistribute to
the 2 LCD, is a good idea, but my LCD should be running at 40MHz
already !!! (it is a AT070TN83 from Innolux, but it can change if
needed. I choosed this one because it has T-CON board integrated and
LED driver also inside...)
- using a bit of color from DSS_DATA for muxing is possible as I just
use 16 bits (RGB565). But I need to think more this solution.
Anyway, thanks a lot for all your ideas, I thinks I need to make order
in my head now...
Another solutions came to me :
- doing a RFBI interface to each LCD to use the MIPI DBI with 2 LCD
panel like shown in the OMAP datasheet. This should not be harder that
the FPGA distributing the bit at 2x rate clock...
At the begining I stop thinking about RFBI connection because I just
found 2 chip doing it :
- on is Renesas R61517 with resolution max = WQVGA: 240 x 432
- and the best one just can do VGA 480x640 : Toshiba TC358730XBG
But at the end, maybe doing my own RFBI compatible interface will be
possible.
