OMAP3530 OLED display

This depends on the particular OLED display you have in mind and how it interfaces, do you have any details on your particular OLED display?

So far I have not worked with any OMAP35xx hardware with an OLED display, usually a direct LCD or a DVI/HDMI based display is used, for which there are definitely drivers, so if your OLED display works like a LCD than you may at least have some good display driver code to start with.

Bernie,

OK, I'm currently checking which OLED to use,

BTW - I found a press release by MicroOLED (http://www.alphagalileo.org/ViewItem.aspx?ItemId=55344&CultureCode=en) where the OLED is connected via HDMI interface to the OMAP,

Many Thanks,

HR

Hi,

We're using a CMEL PO430WQL on our OMAP35x design without any problems... We just connected it to the display bus and configured the timings and bus interface and it runs fine. It's a bit different to use, and if you want to do brightnes / contrast you'll need the supposedly confidential (but easily findable!) HX5116 datasheet but it works. Note that it guzzles power if you have a white UI....!

~Pev

As Bernie mentions, connecting to OLED should be no different to any other display technology since I think that the actual display interface timings etc... are very similar to "normal" displays.

I have some Wiki pages with more information on connecting to various displays at the following locations...

http://wiki.omap.com/index.php/Display_Subsystem

http://wiki.omap.com/index.php/LCD_connectivity

Now, there are some interesting things you can do with the display sub-system to help the 3D stereo display example. You can have 2 frame buffers in memory then configure the display sub-system to combine these into a single, "wide" display output with one image on the left and one image on the right. If this stream is then sent to 2 displays, but the DE signal (ACBIAS on OMAP) is modified externally so that each display only has the DE signal active for one or the other image, then each display will only show one frame buffer image. The displays will effectively each see extended horizontal blanking periods, but most displays can handle this. Alternatively a small FPGA with a line buffer could store one line of one image, then divide the pixel clock and send each line to each display at the same time, thus maintaining both the blanking time and a slower pixel clock.

Just some thoughts :)

BR,

Steve

Steve, Pev,

Thank you very much !

HR