So, I have one of those awesome daylight visible multi-mode 7" Pixel Qi displays (PQ070WS01). …But it’s LVDS.
I know nothing about hardware, but I’m hacking my way through things. I’ll be using a FEZ Hydra for my prototype. The minimum data transfer speed is 22-52Mhz. Can I make this happen using native code and a few GPIO pins? Has anyone tried anything like this?
…And if this isn’t possible, what’s the simplest way to interface to an LVDS display?
What resolution? Hydra is 800x600 max and typically LVDS displays are a lot more.
PQ070WS01 - Pixel Qi / Solar Technologies - www.LcdSolar.com - English version Default Class looks like 1024x600
Funny. That’s the exact same display I’m looking to drive with a G120/G400. They really are quite amazing to see.
One possible way is to use GHI’s VideoOut module to convert the FEZ’s TTL LCD signals to VGA. Pixel Qi also has a corresponding LVDS-to-VGA adapter for about $200. So essentially, for $125 + $200, you can use VGA as a common interface. This is my plan for the prototyping phase, but of course I’ll probably need a TTL-to-LVDS chip and bypass VGA to save cost for the production versions.
That won’t work.
The VideoOut module is “…capable of outputting at 320x240, 640x480, and 800x600 resolutions”
So, it won’t be able to drive a 1024x600 display at its native resolution. The Pixel Qi device you mention may be able to do upscaling/resampling, but that’s going to look gross. Just find a display that’s actually the right resolution. Way easier, and you’ll end up with something that doesn’t look like bird poop.
Ianlee’s Hydracade looks pretty good, and it appears to use the VideoOut module. For my application, sunlight readability is the critical parameter, so a little bit of fuzziness/pixelization is fine 
According to Gus, the VideoOut is cabable of outputting higher resolutions via software upgrades that we might see sometime in the future. If you’re ambitious you might dig further into that and see if it’s something you want to attempt yourself. Of course, the memory in the Hydra may be the limiting factor at this point in time.
@ ianlee74 - What’s the native resolution of the display you’re using for the Hydracade?
Hmmm… I’d have to do some digging but I think its 1280 x 1024. It’s a Westinghouse I had laying around I acquired for a previous job.
What about rolling your own board for this? TI have a suitable chip that can take the RGB and SYNC etc and convert to the LVDS you need.
http://www.ti.com/product/ds90cf583
Also this
Resolution is 1024x768. I can’t do this with bitbanging in native code? I’d be willing to dedicate an ARM7 to the task if needed. Those LVDS support boards are huge.
Thanks, I’d like something smaller but maybe these look like good options.
@ Dave - That LVDS8000 adapter board looks promising. Reasonable price, too.
Now I am curious. NETMF outputs a maximum of 800x600, but the display I’m looking at is 1024x600. What will I see on the screen if I try to interface the two using a RGB-to-LVDS adapter? Would I see inactive pixels where the display exceeds the dimensions of the NETMF output? Would the image stretch to fit the screen? If I end up with a band of dead pixels, will they be evenly divided such that my 800x600 image sits centered on the display? Or would my original image be left-aligned, with all the unused pixels to the right?
You have to remember that all that board contains is shift registers to convert parallel RGB data to differential serial (LVDS) data. It won’t touch your data. So, you’d still have to get your graphics controller to output the correct timing parameters for the display. Wrong timing parameters = gibberish display.
Your display is expecting 1024 pixels worth of data to be written before the horizontal sync signal is pulsed. If you only write 800 pixels of data and then strobe the horizontal sync, not only will that line’s data be incomplete, but the LCD’s back porch timing requirements won’t be met either, which will produce unexpected behavior.
At worst, it will reset the display, and you’ll just see flickering, with no image displayed at all.
At best, it would continue drawing the rest of your image without any issue. The pixels that you don’t set would (I assume?) appear uninitialized, so each one would be a random color, essentially.
Not particularly attractive.
The only way you could possibly address this problem (and center the image if desired) is to use an extremely long front and/or back porch setting in the display controller on your microcontroller. This would run the pixel clock while keeping the data set to 0.The problem is that you’d have to manipulate the horizontal sync pin (since it would be high during the front porch and back porch when it shouldn’t be).
If I were you, I’d drive a CPLD with the horizontal sync pulse and the clock pulse, and then have it output a modified horizontal sync pulse. I’d guess you’d end up with something like this:
1024 - 800 = 224 pixels difference. Each pixel is drawn in one clock pulse. So, if you want the image centered, that means you should set the Hydra’s front porch to 224/2 + fp (where fp = the display’s rated front porch setting).
Likewise, you’d also set the back porch setting on the Hydra to 112 + bp (where bp = the display’s back porch setting).
Now, you’d program the CPLD to assert its output and start counting the pixel clock as soon as the horizontal sync input asserted; once it counted fp number of pixel clock transitions, it should deassert its output. It would need to count the correct number of pixels afterward to know when to assert the output again (for the back porch).
It’s a hack, but I bet it’d work, as long as you can set the fp and bp settings in the display controller to such large values.
Good luck!
@ jay - Thanks for your input! That’s exactly the level of detail I need to figure out how to tackle this. Much obliged.
Where does this 800x600 limitation come from? My thought was to write some RLP/Firmware native code that bit-banged the display. Is that not possible? I thought we had up to 80Mhz GPIO on the STM32F4?!?
I think the 800x600 limit comes from the maximum frame buffer size that’s been provided.
http://www.ghielectronics.com/community/forum/topic?id=3497&page=4#msg37022
A 800x600 image is almost 1MB. Having higher resolutions is not exactly a good idea on a 16MB system. Maybe for a hobby project but not commercially.
FYI, instead of a transflective LCD for sunlight readability, I’m now looking at high-luminance displays. They’re RGB and the native resolutions are more in line with what NETMF supports.
Transflective would have been really nice to use because they’re low-power and low-heat, but it looks like I may have to make do with a big honking LED as a backlight to counteract the sun.
Here’s some vendors:
http://www.lcdsolar.com/high-luminance-displays
http://santechnology.com/products/sunlight_readable_tft.php
Unfortunately, this display is a mandatory requirement. My plan is to dedicate an ARM7 to handle my video (480x480), display and touch input. I’ll use a Cortex-M4 to interact with my SD card, sensors and serve as a state machine. My data requirements are low, so I was going to use serial link between them.
So, considering my specific application, do you still think 16MB isn’t enough?
I’ve got a lot of things on my plate, but unless someone says this is impossible (eventually) I’m going to give this a shot.