Looking for a parallel LCD solution with P2 streamer
rogloh
Posts: 5,787
in Propeller 2
In my video driver stuff I would quite like to add a parallel RGB output mode but have an issue with generating CLK and DE from the same video COG on arbitrary pins.
The CLK should be easy enough to generate as long as it's an integer divider ratio from the P2 system clock (perhaps with non-50% duty cycle if the pixel divider is odd). But the DE output pin may have pin restrictions on where it can be placed. I'm not sure we can send it to any old pin. It may need to come from the streamer hsync output on one of the the lower 8 pins below RGB to keep it synchronized with the data.
I think I asked this a long time ago and @cgracey mentioned if you use the streamer, it would take over the pin outputs and you can't have a smartpin use the same pin group, but if he did a respin he might be able to fix this limitation (I'd have to dig up the old thread where it was first raised). So if it wasn't fixed in rev B it might still be the case that you'd need DE on the 8 pins below to be able to direct the hsync control to it from the streamer, and CLK on one of the 8 pins outside the 32 pin streamer group so the streamer doesn't override it. This will have some impacts on board layouts etc and may push CLK/DE to different portA/portB groups.
Is there some better way to be able to allocate the CLK/DE pins more freely for parallel RGB LCD use? How could you setup a smartpin to reliably remain in sync with the streamer if you want a DE signal output, where DE is high for active video low for otherwise inactive(blanking) periods?
The CLK should be easy enough to generate as long as it's an integer divider ratio from the P2 system clock (perhaps with non-50% duty cycle if the pixel divider is odd). But the DE output pin may have pin restrictions on where it can be placed. I'm not sure we can send it to any old pin. It may need to come from the streamer hsync output on one of the the lower 8 pins below RGB to keep it synchronized with the data.
I think I asked this a long time ago and @cgracey mentioned if you use the streamer, it would take over the pin outputs and you can't have a smartpin use the same pin group, but if he did a respin he might be able to fix this limitation (I'd have to dig up the old thread where it was first raised). So if it wasn't fixed in rev B it might still be the case that you'd need DE on the 8 pins below to be able to direct the hsync control to it from the streamer, and CLK on one of the 8 pins outside the 32 pin streamer group so the streamer doesn't override it. This will have some impacts on board layouts etc and may push CLK/DE to different portA/portB groups.
Is there some better way to be able to allocate the CLK/DE pins more freely for parallel RGB LCD use? How could you setup a smartpin to reliably remain in sync with the streamer if you want a DE signal output, where DE is high for active video low for otherwise inactive(blanking) periods?
Comments
I have a parallel LCD with 6 bits for each R+G+B colour (18 in total) and have 6 spare LSBs "gaps" over all 3 groups of 8 colour pins which would be great to make use of for these signals, but I'm concerned this may not be possible.
https://forums.parallax.com/discussion/168719/p2-streamer-and-parallel-lcd-video-support
I would imagine DE could be integrated with streamer ops like the sync pulses are.
The only other way is a smartpin based DE pin and if it is doable and can somehow remain sync'd to the streamer then I guess it could go anywhere outside the streamer pin group allocated to the LCD parallel RGB outputs. I'd rather like it if a smartpin DE and CLK pin's could go anywhere but perhaps that is not possible when driven from the same COG.
I think a smart pin can be configured to invert the output if we want DE to be high during active video. I haven't tested that feature myself.
EDIT: sync should be able to generated automatically as smart pin PWM. DE is not unlike a sync signal, but it will need masking for inactive lines.
EDIT2: What it seems you need is a way to mask streamer output on the 2 bit gaps. PWM mode overrides the output.
EDIT3: Doesn't streamer output have to go though the smart pin? Otherwise how does bit dac mode work with hdmi?
R(8) : B(8) : G(8) : 0(8)
Yes the sync DAC uses the lowest 8 pin data of the 32 pin data group.
EDIT: No, I keep forgetting, the base period doesn't work like that. It keeps up a regular tick-tock internally as long as DIR is high.
If I have the parallel output AND the DAC mode enabled at the same time I think I might be able to do this...
P2 pins
23-0 RGB bytes (24 bits) - the lowest 8 bit sync group wraps and is mapped to P56-P63 but not enabled.
24 - output pin is setup in DAC output mode gets RGB Sync output and is used as LCD DE signal
25 - LCD CLK pin (a smartpin setup to output the system clock divided by some integer)
I'd just set the DDDD values in the streamer commands to 0100 which is this (though it could be put in other places in the 4 bit group):
0100 -- -- -- X0 output X0 on DAC channel 0
Plus in my own case I also have these two GPIO controls as well
26 LCD PWM backlight
27 LCD power on/off
[Pins 28-31 are still left free for an external SD card in my case but it could be used as another SPI bus or serial for wifi, on board USB etc]
This works very well with dual purposing the LCD over a RasPi compatible header because all 28 lines can be broken out there too. The unused 6 LSBs on 18 bit panels can also be used for i2c/spi control of capacitive touchscreens or resistive types with P2 ADCs from other COGs. It's a very handy pin use of port A.
We can likely bit bang LCD vsync, hopefully an LCD hsync as well though I expect many LCDs would use either CLK+DE, OR CLK+VSYNC+HSYNC, they probably wouldn't need all 4 signals together but I probably shouldn't rule it out.
Included on the RasPi header of P2D2 (going by the silkscreen in the rendering)
P0-P17
P19-P26
P28
P30
[P18, P27, P29, P31 get excluded]
hsync rdfast ##1<<31,##@HyperBuffer 'needs to be here for proper timing xcont m_bs,#0 'horizontal sync xcont m_sn,#1 _ret_ xcont m_bv,#0The XCONTs do all the necessary timing work and all is needed is the right bit patterns in the immediate datas used at each XCONT during blanking. And as James mentioned, invert the output for DE so that a zero value produces a high during visible and a one value produces low during blanking. Even V-sync can be part of the XCONT immediate patterns if we want.Yep. Done lots of this in the video driver work, it's far easier to use the streamer to generate the sync synchronously with the pixel data right on the boundary you want, and trying to sync up manually can become a bit of a PITA and ties the COG down waiting when it could be doing useful things in otherwise idle times like generating mouse sprites etc. The SETCMOD LSB value lets you invert the sync state which is very handy.
Not sure about how easily you do VSYNC with the streamer, unless you put it in the streamer parallel data pin group too and ensure you never set that bit in the normal pixel data and always use positive vsync etc. That's a bit restrictive for my liking. I've done VSYNC on VGA with direct bit bang pin change. It is potentially slightly asynchronous to pixel generation but okay on my analog/LCD/plasma monitors I've used it on. You want hsync to be locked to the data though.
V-sync can be controlled as per VGA examples. It doesn't need a specific clock alignment, just as long as it's stable. I was just throwing that in as a realisation of the flexibility of the immediate data patterns.