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
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...
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...
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 ?
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...
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...
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...
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.
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)
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...
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...
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...
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...
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.
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...
Comments
Getting really close to being done now...
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...
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...
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 ?
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...
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...
pub start(pSettings, sck, miso, mosi, csn, intn, pdn) | i, j longmove(@DispWidth, pSettings, 15) longmove(@pin_sck, @sck, 6) { other start code }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...
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...
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.
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...
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...
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...
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..
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...
https://excamera.com/sphinx/gameduino3/
Might have to port that to Propeller...
**** Happy New Year 2022 to all! ****
I am restoring a Bird 4431 RF wattmeter, the galvanometer is faulty and I am replacing it with a FT812 3.5 inch Newheaven display,
with the excellent work of Rayman I'm doing very well, but I got stuck in drawing the lines and points,
in particular I would like to draw the scale lines and points of the galvanometer,
I found an example in the programming manual :
dl( BEGIN(POINTS) );
dl( VERTEX2II(50, 5, 0, 0) );
dl( VERTEX2II(110, 15, 0, 0) );
dl( BEGIN(LINES) );
dl( VERTEX2II(50, 45, 0, 0) );
dl( VERTEX2II(110, 55, 0, 0) );
dl( BEGIN(BITMAPS) );
dl( VERTEX2II(50, 65, 31, 0x45) );
dl( VERTEX2II(110, 75, 31, 0x46) );
but i can't find how to write it with your libraries
kindly Rayman could you show me how to do it ?
I would be very grateful to you
FX
Rayman,
I tried with your latest posted version "Eve2_Test7a - Archive [Date 2018.08.02 Time 08.05]"
and I was also able to draw the lines,
you have to have a hard head, try and try again ... ...
FX
@"Francesco Santandrea" Glad you were able to make it work!
Guess I should make a note in the top post about using that version...