Shop OBEX P1 Docs P2 Docs Learn Events
Looking for a parallel LCD solution with P2 streamer — Parallax Forums

Looking for a parallel LCD solution with P2 streamer

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?

Comments

  • evanhevanh Posts: 15,126
    edited 2019-11-27 03:23
    I believe each OUT bit is an OR between all cogs and all streamers together. However, depending on the smartpin mode, a digital output is either smartpin or OUT. So a smartpin can take precedence irrespective of what a streamer might be pumping.

  • Ok, but is that true from the same COG? I recall in the past this was an issue. I'd really like smartpin precedence and have the one video COG controlling these additional LCD control signals and certainly not need a second COG one for driving the CLK, DE pins if they fall inside the streamer group sync or RGB pins. Though I sort of need to come up with a reliable way to generate DE if the pin is separate from the streamer group itself.

    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.
  • evanhevanh Posts: 15,126
    That discussion was all about bit-bashing of OUT. Not smartpins. Using a smartpin would be the way to get a non-stop clock, and I believe non-stop is important for many LCDs. I'd probably go for mode %00110 = NCO frequency.

    I would imagine DE could be integrated with streamer ops like the sync pulses are.

  • Yeah clock out on smartpin is a must. The DE might be bit bashed (it only changes state twice per scaline during blanking, however a smartpin would simplify controlling it. It really needs to be sync'd to pixels so if it were included as part of the output of the streamer itself (on one of the 8 sync pins below the blue group), that could work, it just limits the board design to have your DE signal there, and if you wanted to put RGB on pins 23-0 (as I sort of do), it pushes the DE pin up to one from P2 pins 56-63 which may not be all that desirable.

    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.
  • SaucySolitonSaucySoliton Posts: 482
    edited 2019-11-27 06:15
    evanh wrote: »

    I would imagine DE could be integrated with streamer ops like the sync pulses are.
    Yes.

    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?
  • roglohrogloh Posts: 5,122
    edited 2019-11-27 06:05
    I guess multiple back to back streamer operations could stall it and we could try to sync up a smartpin for DE then at startup time that will remain locked. In my sync overlay code I can have dedicated frame / line sync for each output type (up to 18 instructions), so I think controlling it's output, basically driving it low during vsync, would be ok. The streamer method to output DE makes it a lot simpler however, though it constrains the pin selection (can't be helped I guess).
  • evanhevanh Posts: 15,126
    edited 2019-11-27 06:22
    What is current layout of 24-bit RGB in hubram for direct DAC data? Isn't the 8-bit h-sync DAC inherently part of that?

  • roglohrogloh Posts: 5,122
    edited 2019-11-27 06:29
    It is this..
    R(8) : B(8) : G(8) : 0(8)

    Yes the sync DAC uses the lowest 8 pin data of the 32 pin data group.
  • evanhevanh Posts: 15,126
    rogloh wrote: »
    It is this..
    R(8) : B(8) : G(8) : 0(8)
    What happens to the sync DAC if the bottom byte contains data?

  • Bad things. But it only happens in the LUT modes. I think when read from HUB it will set the low byte zero by default.
  • evanhevanh Posts: 15,126
    edited 2019-11-27 06:36
    Okay, good, normally zero and unused group of eight pins then. DE, H-sync and V-sync can occupy three of those pins. No need to trying to find other nearby pins. EDIT: And CLK too. That's four of the eight consumed already.
  • evanhevanh Posts: 15,126
    edited 2019-11-27 07:25
    On the other hand, I you are keen to make the smartpins operate all the control lines, to get the assignable flexibility, then probably the best way to provide a sort of bit-bash effect is use smartpin mode %00101 = transition output. When toggling one step at a time the base-period can be treated as a delayed toggle. This conveniently allows for arranged coincidence. Hopefully this should help with precise timing.

    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.
  • roglohrogloh Posts: 5,122
    edited 2019-11-27 10:39
    Actually I just thought of something. If possible this will really help with my own personal customized setup using the LCD with the P2D2, but may not be a general LCD solution I'd necessarily put in for everything else, although it is another handy possibility for minimal pin use, while still keeping the remaining upper bits of a port free for other uses.

    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.



  • evanhevanh Posts: 15,126
    And the two syncs.
  • roglohrogloh Posts: 5,122
    edited 2019-11-27 13:15
    The two syncs may fit too, though if simple GPIO it may be harder to overlap them within the 24 pin streamer output pins unless you control the LSBs of data in memory and keep them as zero. Also it may be difficult to have the DAC sync used for DE instead as well as its natural use as an hsync, unless somehow a smartpin mode could read/share its state from this DAC hsync pin and somehow output that or'd with some other value perhaps (not sure if any smartpin mode is useful/capable of doing that).

    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.
  • roglohrogloh Posts: 5,122
    edited 2019-11-27 12:16
    Pity that on the latest P2D2 Peter seems to have skipped P18 which rules out 18-24 bit parallel LCDs over that connector with the streamer in all colour modes (you could remap some pins via the LUT). He has these port A P2 pins below mapped to header pins...unfortunately P18 in the middle gets skipped. I guess you can always still use real port A to get an LCD attached (which is what my board did anyway so no drama for me there), but it could have been nice to have a way to attach a custom/board or cable to the RasPi header for LCD use. You still can do it if you skip an extra red bit on P18. You could do 5:6:6 for R:G:B on an 18 bit panel instead of 6:6:6. Might be nicer if he skipped P16 or P17 instead, though I prefer to keep the full lowest 28 pins available in a contiguous block of signals.

    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]
  • evanhevanh Posts: 15,126
    Looking at an example VGA H-sync code, all three XCONTs are immediate mode, with output data in the #S field.
    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,#0
    
    The 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.

  • evanhevanh Posts: 15,126
    edited 2019-11-27 12:42
    rogloh wrote: »
    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]
    To be honest, 18 bits is enough for most LCDs. Its not a particularly great tech.

  • roglohrogloh Posts: 5,122
    edited 2019-11-27 13:00
    evanh wrote: »
    Looking at an example VGA H-sync code, all three XCONTs are immediate mode, with output data in the #S field.
    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,#0
    
    The 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.

  • evanhevanh Posts: 15,126
    edited 2019-11-27 13:22
    I think SETCMOD only works with DAC and TDMS channels. So it won't be available for plain parallel data. The pin output can be inverted in the pin config bits 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.
  • We are very lucky this P2 chip is so flexible and that Chip designed it really well that it allows methods for all these special video combinations. It's already proven itself so versatile to me in what I've learned as I've put things together and some of us have only just begun even taxing it really. I'm still waiting to find its limits!
  • evanhevanh Posts: 15,126
    rogloh wrote: »
    I'm still waiting to find its limits!
    Yeah, that'll be pushed again and again me thinks. For example, I don't think I'm up to designing a hyperRAM board layout to suit operating at sysclock/1. But someone will do it eventually I suspect. It looks like the prop could handle it if the timing was carefully matched up.

Sign In or Register to comment.