A low-cost way to attach a small TFT display module over USB

I finally got some time to tinker again.

The following video shows a 320x240 TFT display module attached to a Cypress EZ-USB FX2LP development board:

The software and wiring instructions can be found at:

https://github.com/jboecker/fx2-usb-display

You can blame ArturDCS for this, this whole thing is the result of a discussion we had on Discord when he told me he could not get Saitek's Flight Information Panels to work with DCS.

The first idea was to use an Arduino Due, but that was too slow (mostly because while the Due has 32-bit I/O ports, the pin headers do not bring out one complete port, so the firmware needs to do a lot of bit shifts to put the right bits on the right pins).

Then I stumbled upon the Cypress FX2LP. This is the same chip that is found in the $10 logic analyzers from eBay. It has an 8-bit 8051 CPU that is a bit slower than an Arduino Uno, but it has a fast data path between USB and a 16-bit parallel interface that does not involve the CPU at all (it only sets things up and then gets out of the way).

If you search eBay for "CY7C68013A", you will find development boards with this chip for less than $5.

The current software can take a 320x240 rectancle from your screen and send it to a 320x240 TFT module that is attached to one of these dev boards and has an SSD1289 compatible controller chip.

There are 5 unused GPIO pins and an I2C bus on the board that could be used to attach a few push buttons or rotary encoders in the future. The board runs on 3.3V, but all inputs are 5V-tolerant.

Very cool!

I've had success using DisplayLink USB adapters driving small LCDs. I plan to use these for my MFDs when the time comes.

http://www.displaylink.com/products/usb-adapters

DisplayLink is definitely the way to go for high resolutions. This board could probably handle a 480x320 display (for the SSD1289 the EZ-USB has to slow down a bit to meet the timing requirements), but if you go higher than that the frame rate will drop (this is not such a problem for DisplayLink chips -- I have a 1600x900 DisplayLink monitor that works remarkably well on a USB 2.0 port, so their controllers must have enough computing power to implement compression algorithms).

The advantages of this approach are the low cost (for the price of one DisplayLink adapter, you can get all the parts you see in the video) and the ability to talk to displays in small and weird form factors that might not be available with an HDMI port.

Looking Nice Ian - wonder if this would be a goer for the Hornet Engine and Fuel indicator display?

Looking Nice Ian - wonder if this would be a goer for the Hornet Engine and Fuel indicator display?

Looks like it would, at least these guys use a 320x240 display.

http://www.driven-technologies.com/simulated-flat-panel-displays/simulated-military-displays/f-18-integrated-fuel-engine-indicator-ifei.html

I don't know how hard it is to find one in a 5.5 inch size though. You might be able to use two smaller displays in portrait mode instead.

I don't know the F-18 well, so I don't know where this display would be in relation to the pilot, but if you are not going to be looking straight at it you might want to find an IPS panel instead of a TFT -- on these cheap TFTs, the colors change drastically with viewing angle.

Very nice Ian. Thanks for sharing :thumbup:

Cheers

Hans

Ian;3364663']I finally got some time to tinker again.

 

The following video shows a 320x240 TFT display module attached to a Cypress EZ-USB FX2LP development board:

 

 

The software and wiring instructions can be found at:

https://github.com/jboecker/fx2-usb-display

 

 

You can blame ArturDCS for this, this whole thing is the result of a discussion we had on Discord when he told me he could not get Saitek's Flight Information Panels to work with DCS.

 

The first idea was to use an Arduino Due, but that was too slow (mostly because while the Due has 32-bit I/O ports, the pin headers do not bring out one complete port, so the firmware needs to do a lot of bit shifts to put the right bits on the right pins).

Then I stumbled upon the Cypress FX2LP. This is the same chip that is found in the $10 logic analyzers from eBay. It has an 8-bit 8051 CPU that is a bit slower than an Arduino Uno, but it has a fast data path between USB and a 16-bit parallel interface that does not involve the CPU at all (it only sets things up and then gets out of the way).

 

If you search eBay for "CY7C68013A", you will find development boards with this chip for less than $5.

 

The current software can take a 320x240 rectancle from your screen and send it to a 320x240 TFT module that is attached to one of these dev boards and has an SSD1289 compatible controller chip.

 

There are 5 unused GPIO pins and an I2C bus on the board that could be used to attach a few push buttons or rotary encoders in the future. The board runs on 3.3V, but all inputs are 5V-tolerant.

So...it sounds cool and all, but if it sends a 320x240 rectangle from the display, what happens when the display changes, like when I turn my head (I use TIR-style positioning)?

Would the little display move with the main screen, or is there a way for it to be locked on something that isn’t actually on the visible screen, like instrument gauges?

Looking Nice Ian - wonder if this would be a goer for the Hornet Engine and Fuel indicator display?

I have a display picked out for the F/A-18C IFEI. Single display behind panel, bezel over top with button module.

http://www.buydisplay.com/default/7-inch-arduino-touch-screen-shield-ssd1963-library-for-mega-due

Would the little display move with the main screen, or is there a way for it to be locked on something that isn’t actually on the visible screen, like instrument gauges?

You can configure DCS to put a copy of a display on a second monitor, so you can grab it from there. This works out of the box for the two MFCDs, and with some editing of Lua files for most of the other displays in a clickable cockpit (e.g. the RWR, CMSC, CMSP, or CDU in the A-10C -- anything that gets rendered as a flat texture instead of being a part of the 3D cockpit model).

I have a display picked out for the F/A-18C IFEI. Single display behind panel, bezel over top with button module.

 

http://www.buydisplay.com/default/7-inch-arduino-touch-screen-shield-ssd1963-library-for-mega-due

That should work. I took a quick look at the datasheet. With that display, the EZ-USB chip is no longer slowed down by the timing requirements of the display, so the data rate could increase up to 2.3x compared to the 320x240 TFT with the SSD1289 controller. On the other hand, it has 5x more pixels than a 320x240 display. I would expect about 14 fps. In practice, we could probably achieve ~30 fps again if the host software gets optimized to only send the parts of the frame that have changed, as large parts of the display will be static most of the time.

Ian;3367803']You can configure DCS to put a copy of a display on a second monitor, so you can grab it from there. This works out of the box for the two MFCDs, and with some editing of Lua files for most of the other displays in a clickable cockpit (e.g. the RWR, CMSC, CMSP, or CDU in the A-10C -- anything that gets rendered as a flat texture instead of being a part of the 3D cockpit model).

 

 

 

That should work. I took a quick look at the datasheet. With that display, the EZ-USB chip is no longer slowed down by the timing requirements of the display, so the data rate could increase up to 2.3x compared to the 320x240 TFT with the SSD1289 controller. On the other hand, it has 5x more pixels than a 320x240 display. I would expect about 14 fps. In practice, we could probably achieve ~30 fps again if the host software gets optimized to only send the parts of the frame that have changed, as large parts of the display will be static most of the time.

Sent from my SAMSUNG-SM-N910A using Tapatalk

Sorry to bring u an old thread. Looking for an economic screen solution for my F18 DDIs, what would be the latest best practice?

Thanks for any info.