Newhaven + Matrix Orbital Display with On-board FTDI FT81X Embedded Video Engine
Rayman
Posts: 14,755
Just figured out how to make this work with Propeller in Spin 
One trick is that you send addresses in big-endian format, but data in little-endian...
Anyway, here's code and photo showing one of the first examples in the programming guide with 7" LCD.
Note: This is work in progress, see end of thread for the latest, like this alpha channel overlay test with rotation and scaling thrown in:
Update: See post #84 in this thread for a better version of this code.
One trick is that you send addresses in big-endian format, but data in little-endian...
Anyway, here's code and photo showing one of the first examples in the programming guide with 7" LCD.
Note: This is work in progress, see end of thread for the latest, like this alpha channel overlay test with rotation and scaling thrown in:
Update: See post #84 in this thread for a better version of this code.
2016 x 1512 - 914K
Comments
-Phil
The P1 could struggle, but surely the P2 can compete head on with the FT813 etc ?
The FT813 is not cheap at $6.09/250 ?
http://www.newhavendisplay.com/tft-modules-eve2-tft-modules-c-1_990_992.html
Why bother rolling your own, when these are so reasonable?
-Phil
Yes, modules have their place, but if the P2 can compete with FT813 series, someone will make modules using that, surely ?
320x240 looks comfortable, but 800x480 is more a challenge for P2, but it could use the display-list approach ?
-Phil
Depends on how well-paced those video signals are, and if there is sync-timeslot-control.
LCDs are more tolerant of pauses in varying places - do you have one you can scope ?
More complex than I thought, but very powerful.
It can draw complex "widgets" for you. Things like buttons and dials and progress bars, etc.
Here's my first test, doing a button.
Before this, I was writing commands to the "Display List" directly.
When you use the co-processor it writes to the Display List for you.
It's just six 32-bit writes to generate this button with text!
J/C - Is that an eval board they make or are you working on something around it?
But, it happened to have a header with enough spare prop pins going to it...
Also, it has 5V power for the backlight...
The built in fonts look like they might be good enough.
I put the display update in a loop animate the gauge and it moves very fast now with SPI_ASM.
Maybe I don't have to make a custom driver after all...
Attached is code with new driver.
Well done - keep it coming! I love your interface development commentary and code examples on this emerging hardware.
This display seems to have a lot of potential for Prop projects.
I wish there was more of these sort of threads on the forum!
Looking at putting two displays on the same SPI bus...
Will also let me test mixing EVE2 and Prop audio.
Can also test out the GPIO...
The board was designed in Eagle, it was mostly copied from my Nibbler project...
Anyway, I'll post the Eagle files in case anybody else wants to try.
Great, thanks - I'll use those to test KiCad's Eagle Import.
Looks like PCB imports fine, it reports this for my PCB NET out :
#Comment KiCad NET export using PcbNew_Export_PcbNew_NET.py v1.03, from Kicad design: C:/KiCadFiles/Eagle/Eve2_Display1a_Eagle/Eve2_Display1a.kicad_pcb
#Comment: Parts:113, Nets:171, PinsConected:569, TotalPads:608, Ref Skipped:0, SheetPath:0
The SCH import has a couple of visual issues (maybe justify is lost on left facing net tags ?) - can you post a PDF if you get time, and I'll check again.
I think the netlist export from SCH is ok
thanks.
Looks like Eagle -> KiCad import has the nets all correctly tagged, but in some cases the tag-name is moved (sometimes jumps to another corner) or rotated from the original.
Small net tags are added, eg to Prop Xtal N$4 N$5 I think to preserve the net names (packages usually have varying auto/hidden net naming )
Some also look to be redundant.
Not sure I see any real bugs, and those labels may be insurance to ensure a netlist match - which is probably the more important design transfer priority. You want it right, before you want it pretty !
They are easy enough to move/spin to a better cosmetic location.
checking the messages on net-import, I do see one minor effect on the PCB.
On regulator IC5, there are two zones imported on copper layers, and not net tagged.
As a result, the fill is slightly different - to correctly connect to pin4, pin 4 should have a net name, and the traces/vias/zones all match that net name.
If I manually edit Pin4 to match the via's THERMAL net, and tag the fill zones as THERMAL net, set their priority to >GND, and add a trace IC5.4-Via, it all fills/connects as local-copper-cooling.
Maybe Eagle allows looser rules here ?
The attached makes it easy to create a display list using either direct or co-processor method.
The co-processor method is so much more powerful, that I don't think I'd actually use the direct method at this point...
Want the Gerbers?