Planar EL Display Driver

MasterC · 2012-02-01 16:33

Hello,

I need to interface a Prop to a 512x256 monochrome Planar EL display (to be exact, model EL512.256-H3-FRA). I was hoping to use the Prop' video generator to do so, and ideally I was hoping to use or tweak the default video drivers from the Propeller library, or find something in the obex that I could use without too much tweaking. It seems like what I need to do can't be too far off from either the standard TV or VGA implementations. However, I searched around here for quite awhile, but I'm afraid I am not well versed enough in video output schemes to tell for sure what might work at first glance. If anybody can provide any pointers, I would very much appreciate it!

The datasheet for that display is available from a google search, but it looks like the video input interface boils down to four lines:

VID - signal that supplies the pixel information
TVID - (optional) Second data input for two bit parallel mode
VS - vertical sync
HS - horizontal sync
VCLK - shifts data on the VID and TVID lines into the display

From this and the timing diagrams, I can gather what my driver would have to do. What I don't know is if that is like something that already exists.

Does it sound close to something one of the existing objects can handle?

Thanks!

pedward · 2012-02-01 21:16

Grr, when you hit Ctrl-C to copy, the stupid forum editor cancels your reply!

In short, you need to shift data out and synthesize a clock. The video generator doesn't generate an external clock AFAIK.

The most novel way I've seen this done is this:

'send out 16 longs
mov pixelcount, #16

loop:
rdlong phsa, buffer
shl phsa, #1
xor outa, pinmask
xor outa, pinmask

...do this 32 times...

shl phsa, #1
xor outa, pinmask
xor outa, pinmask
add buffer, #4
djnz pixelcount, #loop:

You will have to generate the hsync and vsync signals per the datasheet, but the snippet above should give you an idea. The high speed propeller communication object uses the same shift mechanism IIRC, I know kurenko wrote an object that does.

kuroneko · 2012-02-01 21:20

pedward wrote: »

The video generator doesn't generate an external clock AFAIK.

It does when you use PLL mode 2 (%0_00010_000).

pedward · 2012-02-02 00:56

Are you suggesting that if you use SE PLL mode 2, the APIN is a clock output that matches the PixelClocks frequency?

That would mean you could WAITVID to send 32 bits serially, or 4 bytes parallel transfer. I think the limiting factor would be minimum number of PASM instructions to fetch and stuff data from hub memory. Certainly faster than the 20Mbits using the stuff and shift method.

kuroneko · 2012-02-02 01:03

pedward wrote: »

Are you suggesting that if you use SE PLL mode 2, the APIN is a clock output that matches the PixelClocks frequency?

Yes, provided you enable the output

IIRC, the display goes up to 70Hz frame rate so a 10MHz pixel clock is more than enough.

pedward · 2012-02-02 01:17

I wonder if this will be added to the v1.5 datasheet? Seems that a once this is documented, all sorts of neato stuff will come. You could use VGA mode to blast data out while reading from external RAM with another COG.

kuroneko · 2012-02-02 01:49

pedward wrote: »

I wonder if this will be added to the v1.5 datasheet?

Got a spare first-born?

pedward wrote: »

You could use VGA mode to blast data out while reading from external RAM with another COG.

Get cracking then!

JRetSapDoog · 2012-02-02 02:31

Hmm...one website I saw *only* wants $1,650 (USD, I believe) for that EL display. I think I'll order three to stock up. Well I jest, of course, and I knew it'd be expensive, perhaps in the $100-300 range, but didn't expect it to be THAT expensive. I thought they already retired the Space Shuttle fleet; stuff like that ought to be going cheaper. Still, that's how it is in display world, isn't it! Only the popular TFT RGB displays are cheap (maybe OLED's, too, progressively), which is nice since we all like color. Demand really drives the prices down, and screens at 7" and under diagonally are really starting to get affordable, even the ones with driver boards (composite/VGA or some kind of RGB driver chip) But the B&W LCD displays are generally more expensive, as well as the bistable ones (that don't need power to maintain an image). I know this is not tech help, but it puts the display in in context for the interested reader. And, regardless of the price, it's definitely appropriate to consider how to drive this beast with the Propeller for the general learning of all. EL display link: http://www.planaronline.com/product/?id=996-5059-00lf

BTW, Sharp has an interesting 6" bistable display that works a bit differently than the normal ones that uses a technology called "memory LCD" (with a memory bit behind each pixel, or maybe 2 bits, I forget, as it may have 4 shades). It was released a couple years ago. At one point, I think it was sampling for around $90 bucks, but since it seems like no mainline manufacturers have picked it up, it'll probably stay expensive and/or fall by the wayside. I wonder if anyone here has used it, or any of the other bistable displays. Anyway, I wish Sharp had come out with a limited color version of it as they had roadmapped to do, but, so far, I guess not, which will apparently leave the market to Qualcomm's Mirasol (already on e-books in Korea/China and Taiwan) and Samsung's Liquivista technologies to battle it out, though I doubt such displays will be available cheaply to Joe and Joanna Hacker, even if they had the hardware (and skills) to drive them. Anyway, the cost of the EL display of this post really makes me appreciate the Solomon and Illitek driven displays and the composite/VGA driven displays, as well as the cheaper RGB ones. We now return you to your regularly scheduled program.

Rayman · 2012-02-02 02:54

Our 3.5" and 4.3" drivers use the video mode with pixel clock.
You only need one or two data lines instead of 6 or 8, but still it should work...

MasterC · 2012-02-02 10:02

Rayman wrote: »

Our 3.5" and 4.3" drivers use the video mode with pixel clock.
You only need one or two data lines instead of 6 or 8, but still it should work...

Thanks Rayman - where do I find these drivers?

pedward, thanks for the info and example code; I'll keep this in mind if I decide to implement without the video generator.

kuroneko, it sounds like you are saying it can be done with the video generator, but so far I do not understand exactly how...using one of the existing drivers (with a tweak), or from scratch?

Rayman · 2012-02-02 12:04

It's on my website under PTP and PSB...

kuroneko · 2012-02-02 16:20

MasterC wrote: »

kuroneko, it sounds like you are saying it can be done with the video generator, but so far I do not understand exactly how...using one of the existing drivers (with a tweak), or from scratch?

Think of it as a constant stream of data sent out from the prop to the display. The video generator outputs the clock and the associated data which you have to provide every now and then, e.g. with 10MHz pixel clock and 1bit mode you'd have to provide a long worth of (pixel) data every 256 system clock cycles (@80MHz). This leaves plenty of time to update relevant address pointers and maybe do some other stuff. That said, you have slightly less time given that you need to generate the sync signals as well (either manually or with the video h/w) but it should give you the general idea.

I haven't looked at existing LCD drivers in terms of signal generation but I believe they are similar enough to what you need (Rayman?). So it may be beneficial for you to start with one of them and tweak it and maybe later - when you're comfortable with the HowTo - write one specifically for this display.

Rayman · 2012-02-02 17:19

Wow, nice price. If they're really more that $1000.00, just send me one and I'll write you a driver for free

MasterC · 2012-02-02 18:09

Thanks guys. Figuring it was a long shot, I tried using Rayman's PSB graphics demo (after changing the cols and rows constants to 32 and 16 for my display) and hooking up the control pins on my display to the corresponding pins from the VGA port on the demo board (along with Rayman's Pixel Clock pin). Didn't work. Of course, I wasn't sure what would happen, since I don't need color, so I just hooked up one of the three VGA color pins to the display's VID pin. I was hoping to see some activity on the screen, even if it wasn't the correct pictures, but no such luck.

Anyway, I was hoping to get up and running quickly by leveraging existing objects, but I'm starting to wonder if I would actually come up to speed quicker by writing my own display driver. I was looking through Rayman's code and Chip's default VGA and graphics drivers trying to figure out what I need to change to work with my monochrome display, but I keep getting lost somewhere between the "front porch" and the "back porch" and all the other stuff in there. I think my display driver doesn't need all that complexity. Then again, it would be really nice if I could make use of the existing graphics object, and I'm not sure I know how to do that starting from scratch.

If you have any further input, I'm all ears (and I'd really appreciate it).

Thanks!

P.S. Yes...this display is a bit spendy!

pedward · 2012-02-03 00:15

I would recommend looking for a 2 color driver and trying that. Your 2 colors are on/off, so you simply need all 1's or all 0's for the color values.

Your code then becomes:

waitvid pixels, ones_and_zeros

The ones_and_zeros is a constant declared in the DAT section as $0000_FF00 since the upper 2 bytes aren't used in 2 color mode.

You then configure the VGA mask in Vpins field of VCFG to be % 0000_0001 for a single bit output. The PLL mode needs to be 2 per kurenoko's post, that APIN will be your clock output. You then need to configure a pixel clock (FRQA value) for the number of pixels per line, plus the extra clocks around hsync and vsync, multiplied by the number of rows and then multiply that by 70hz. You will end up with around 9.8Mhz pixel clock. The PLLA clocks per pixel should allow you to either do dot addressing or stretch the pixels to use less system memory for the screen buffer. The frame clocks is just 32*PixelClocks.

You will need to twiddle the hsync and vsync bits in software, or you can use part of the color mask value, but that complicates things more than need be. Just stuff a line, twiddle the sync, stuff a line, twiddle the sync, etc, until you have a complete output.

You can use the random number generator to give you test data, or you could use an alternating pattern such as $AAAA_AAAA or $5555_5555, which would give 1 pixel on/off vertical bars. This would help with testing to ensure alignment from row to row, and it simplifies the coding to eliminate the need to stream data while working out the mechanics of driving the display.

potatohead · 2012-02-03 08:27

A great alternative to writing your own would be to strip one of the existing ones down.

Get it to generate your test pattern on the display it's built for. Then (assuming you have gear) look at the timings you see, compare to data sheet and compare to instructions in the driver. That's to get you oriented. Make small modifications to each, verifying against the data collected earlier.

That's your template.

Take the timing data from the target display, and modify the driver to match those.

On your way through, comment the driver code so that you know what each instruction does. That's how I got some of my early driver code working nicely. You may learn there are short cuts, or special requirements, at which point, you also know enough to perform a rewrite.

Circuitsoft · 2012-02-03 19:07

If you don't have a logic analyzer, drop another propeller chip on top of the one in use, lift P30, P31, and Reset, and connect them to their own prop-plug. http://forums.parallax.com/showthread.php?110762-Propalyzer-Distribution-New-Update-1.0.1.4-Available&p=788230#post788230

MasterC · 2012-02-06 10:19

Thanks to all who replied! pedward, I was assuming much of what you said is what Rayman's driver had done, except for the changes to make it 2-color. I'll have a closer look! The advice that you and potatohead gave about generating a test pattern and viewing it on a working display first is very good. Also, I do have equipment available to me...just was being lazy and looking for shortcuts. It seems I'm going to have to just break down and get into the nitty-gritty on this.

Thanks again!

Planar EL Display Driver

Comments