Newhaven + Matrix Orbital Display with On-board FTDI FT81X Embedded Video Engine



  • RaymanRayman Posts: 10,053
    edited 2018-07-04 - 14:53:02
    With some quick changes, can now control two 7" LCDs from one SPI bus.
    Getting really close to being done now...

    Prop Info and Apps:
  • What’s an example of needing to LCDs at the same time. I assume since you’re putting this much effort into it that you have an application where you need controls on one screen graphics on another right
  • RaymanRayman Posts: 10,053
    edited 2018-07-04 - 15:40:03
    I'm making a box with 4 touchscreens… Two 7", one 4.3" and one 3.5".

    Box will control two High Voltage Power Supplies. The 7" screens will show details for each supply. 4.3" will show overview. 3.5" will have some buttons (TBD).

    Going to have two SPI busses with 2 screens on each...
    Prop Info and Apps:
  • Nice job I'd like to tryout one of these New Haven's but they are a little pricey 7" $80-$90 range
  • Are you going to take a crack at LVDS
  • How are you using the same SPI bus for multiple EVE2. Are they ID’d?
  • RaymanRayman Posts: 10,053
    edited 2018-07-04 - 17:17:57
    Currently, each display has it's own chip select and power down pins.
    They have interrupt pins too, but I'm not using them because polling looks to be just fine...
    It's the individual CS pins that lets them share the SPI bus.
    I could actually put all 4 displays on one SPI bus...

    LVDS? Maybe when Prop2 comes out...
    I don't have to worry about budget for this particular project...

    Prop Info and Apps:
  • jmgjmg Posts: 14,175
    Rayman wrote: »
    Currently, each display has it's own chip select and power down pins.
    They have interrupt pins too, but I'm not using them because polling looks to be just fine...
    It's the individual CS pins that lets them share the SPI bus.
    I could actually put all 4 displays on one SPI bus...

    I'm not clear here - The picture appears to show one board, and 2 ribbon cables (parallel RGB ?) to LCDs , or are there 2 x EVE2s on that board ?
    Is this one EVE2 per display, or can you work 2 displays from one EVE2 ?
  • An EVE2 is built on the back of each LCD.
  • RaymanRayman Posts: 10,053
    edited 2018-07-04 - 20:52:39
    Think I have it now :) This version demonstrates controls on two independent screens on a single SPI bus.

    I've also made it so that image upload can go to both screens at the same time.
    Want to make it fast to get a splash screen on both screens...

    Prop Info and Apps:
  • Just got this working on a Matrix Orbital 5" LCD (kindly donated to the cause).
    Only had to give it the pixel timings for this particular display. No changes to the driver itself.

    I did have to make a little adapter to go from my IDC header to the FFC connector on the Matrix Orbital display.
    At first, I thought I had the pinout reversed on my FFC connector. Well, I did for regular ffc cable with exposed metal on the same sides.
    But then I noticed that the Matrix Orbital FFC cable has exposed metal on opposite sides on opposite ends of the cable.
    That lets you use the same connector and pinout.
    If I was a little smarter, I would have realized this before spending 3 hours making a 18-pin ffc connector with top contacts work...

    Anyway, this 5" display is kinda nice as it has the full 800x480 resolution.

    The attached example is meant for a single display, not the dual display test from last time...

    Prop Info and Apps:
  • Looks really cool, Ray. Once you start refining code you'd probably do this, anyway -- just a reminder to save a few lines.
    pub start(pSettings, sck, miso, mosi, csn, intn, pdn) | i, j
      longmove(@DispWidth, pSettings, 15)
      longmove(@pin_sck, @sck, 6)
      { other start code }
    Jon McPhalen
    Hollywood, CA
    It's Jon or JonnyMac -- please do not call me Jonny.
  • RaymanRayman Posts: 10,053
    edited 2018-07-15 - 14:12:51
    That's a good idea. This driver is not particularly optimized yet...

    I think I just got the Matrix Orbital 3.8" display working.
    This one is interesting, it's an extra-widescreen format.
    It's 480 pixels wide but only 116 or 117 pixels tall.

    The visible screen spans y locations from about 10 to 125, i.e., top left corner is (0,10) instead of (0,0).
    Maybe I could tweak the display settings to fix that, it might be VSync0 that sets the offset...

    This screen format is interesting...
    Prop Info and Apps:
  • Are you seeing any advantage/differences from the NH and MO products.
  • RaymanRayman Posts: 10,053
    edited 2018-07-17 - 14:59:05
    Well, it's good to have options!

    I haven't done a complete comparison.
    But, the main differences seem to be in the connecting cable and how the screens attach.

    If space is a huge concern then the 0.5mm pitch ffc cable on MO screens is small.
    Otherwise, NH has a IDC and larger pitch FFC cable option.
    I'm using IDC in my big project because they are in a giant box with lots of space and I can make my own IDC cables.

    The MO screens have sticky tape on the back to attach whereas NH has mounting holes.
    Sticky tape is probably easier but maybe mounting holes is more robust.
    MO has bezels but NH does not.

    Most MO screens don't need separate backlight power, they just get it from the 3.3 logic power whereas I think you need to connect backlight power on NH screens. Also, it's better to use 5V for backlight on NH screens as it's more efficient than 3.3 V. The MO efficiency at 3.3V is much better.

    NH is open source hardware, so maybe you could make your own version, perhaps with a prop onboard :)

    NH has several options for each size like daylight readable, premium, low cost. MO has some screen sizes that NH doesn't have.

    So, there are some differences...

    BTW: You can find settings for the other MO screens in their datasheet. Just add them to the display type list if you want to use one of their other displays... The settings in the code are in the same order as the table in the datasheet...
    Prop Info and Apps:
  • I tried to get 4 displays on one SPI bus, but it just won't do it... 3 displays is fine, 4th one makes bus not work.
    I tried the command to increase drive current on output pins, but it doesn't help.
    I could have investigated further with a scope, but instead just gave up that plan.

    On the positive side, I think I've decided that can get by just fine without the interrupt pin connected.
    With four displays, that's a savings of four pins and so have enough for a second SPI bus with 2 displays on each.
    Prop Info and Apps:
  • I suppose with EVE as the interface you can get by without Irq. So you are polling SPi for a touch event vs waiting on a pin state change.
  • T ChapT Chap Posts: 4,013
    edited 2018-07-22 - 15:50:25
    You could use an i2c expander to watch the multiple Irq pins then read the expander to get the device number. The i2c device would have an Irq output you could watch for a state change from any lcd. This might make sense only if you have i2c pins already in use on other devices that can be used to read the expander as needed otherwise you don’t save pins(ie eeprom i2c)
  • RaymanRayman Posts: 10,053
    edited 2018-07-22 - 18:38:41
    Yes, just polling.

    I have used, I think it was a 1 MHz, I2C to SPI bridge chip. Was very nice. with just 2 Prop pins you get 3 or 4 (I forgot) SPI lanes. But, it's just an added complexity that I don't need for this particular application. Also, I may be getting a bit more that 1 MHz with the Prop Library SPI code...

    The next thing I want to try is video playback. Having a hard time getting video in proper format at the moment, but should have it soon. I don't need video for current project, but want to try it anyway. I did play a bit with audio output and that works as expected...
    Prop Info and Apps:
  • jmgjmg Posts: 14,175
    Rayman wrote: »
    I tried to get 4 displays on one SPI bus, but it just won't do it... 3 displays is fine, 4th one makes bus not work.
    I tried the command to increase drive current on output pins, but it doesn't help.
    I could have investigated further with a scope, but instead just gave up that plan.
    Did you try a Prop-end series R (~ 100R) on the clock line ?
    and in extreme cases of long cables, a far end terminator of a series R + small C ( 120R, 47pF) can help reduce clock ringing.
    It's usually the ringing getting large enough to be seen as a clock that causes 'was working' to 'now not working' cases as you add more cables...

  • T ChapT Chap Posts: 4,013
    edited 2018-07-22 - 20:41:14
    I use the termination on my devices. On the scope the benefit is significant. I leave the original input wiring as is but add 120 ohm and .1 in series to GND from near the input of the device.
  • Playing around with some EVE2 extras...
    Sound is pretty easy to make work.

    I spent some time trying to make mpeg video work, following the example software provided...

    It appears that it's not as easy as I hoped... First, I looked at their demo video again and I think there is actually no sound. Also, their sample code does not use the "PlayVideo" command. I have a feeling that that command does not actually work. Appears that on the PC side they are parsing the .avi video and extracting the video part and then sending that to the media fifo. Code is a bit hard for me to follow, but appears they just use the "LoadImage" function with the use "MediaFifo" option.

    I used handbrake to transcode the same video they used into mpeg2 video, but could not get that to work. They have the advantage of a .avi parser on the PC side to help extract just the video portion, I think.

    I don't actually need video, so I don't think I'll pursue this much more. But, the attached loads a jpg image into the Media Fifo and then uncompresses and shows it. It's a little different than last time only that the jpg data is first loaded into main memory (in an area designated to me the media fifo) before decompression. Before, I just sent the image data to the command buffer. The command buffer is only 4 kB, but I was probably sending the data slow enough that it didn't overflow.

    Looks like we can store several jpg or png images in main memory, call that area a mediafifo and then decompress to show. This can actually be useful, since I'm just on SPI and not QPI bus. So, can store all the images I need in GRAM until needed. This 7" screen has 800x480 resolution so it needs 750 kB of GRAM for the uncompressed image. But, my example jpg image is just 36 kB and looks OK. GRAM is 1 MB, so there is still ~250 kB left for images, so several full screen resolution jpg images can fit there...
    Prop Info and Apps:
  • Here's a test of bitmap overlay with transparency, rotation and scaling.
    This actually worked out as good as I hoped.

    See below for a png image with transparency (alpha channel) that was small enough to be embedded in code.
    It is drawn on top of a full screen jpg image that is pulled from micro-SD card and loaded to EVE main memory.

    I think this rotation and scaling opens up some very nice possibilities...

    Here's a video:

    code is posted below..
    2016 x 1512 - 1M
    200 x 200 - 2K
    800 x 480 - 35K
    Prop Info and Apps:
  • Very cool stuff. Now add a gesture sensor to the side of the lcd and when someone tries to push a button have the button move to a random location before they can get their finger on it.
  • RaymanRayman Posts: 10,053
    edited 2018-08-03 - 11:55:28
    I measured the update rate for that last demo to be 40.3 fps.

    The settings have the pixel clock at 30 MHz and the x and y clocks are 928x525 giving a screen update rate of 61.6 fps. So, it seems like the graphics update is close to the maximum possible, but not quite there...

    If this was all in assembly instead of Spin, maybe could get to that 61.6 fps...

    Prop Info and Apps:
  • Just noticed this cool looking applications of EVE2:

    Might have to port that to Propeller...
    Prop Info and Apps:
Sign In or Register to comment.