Recent Posts

Pages: 1 ... 5 6 [7] 8 9 10
TFTs / Re: Raspberry Pi driver for 1.8" and 2.4" TFT models
« Last post by Ted_M on June 14, 2018, 08:28:33 AM »
Thanks for posting the drivers for the Rasberry Pi!  They will be very useful for many users. 
We look forward to seeing more of your postings in the future.

Best Regards,
TFTs / Raspberry Pi driver for 1.8" and 2.4" TFT models
« Last post by joaBaur on June 14, 2018, 01:55:15 AM »
So after the FPGA drivers I went for something easier, and connected the TFTs to the Raspberry Pi's GPIOs.

Repo for the NHD-1.8-128160EF TFTs:

Repo for the NHD-2.4-240320CF TFTs:

Both drivers are native C, they map the main display's internal framebuffer (/dev/fb0) to memory, read the pixels' RGB values and bit bang them to TFT via the GPIOs.

The frame rates are ok, about 20 fps on the 2.4" and 34 fps on the 1.8" display.
TFTs / NHDev board and NHD-1.8-128160EF-CTXI#-FT
« Last post by SteveK on June 13, 2018, 05:40:05 PM »
I would like to use the NHDev module to evaluate a NHD-1.8-128160EF-CTXI#-FT display.

However, in the list of displays that the NHDev supports, it lists only NHD-1.8-128160TF-CTXL#, which appears to be a bogus number, ie it shows no results if we search for it on the Newhaven site.

Can anyone confirm if the NHD-1.8-128160EF-CTXI#-FT will work with the NHDev module?

TFTs / Re: FPGA driver for NHD-1.8-128160EF TFTs
« Last post by joaBaur on June 13, 2018, 11:58:31 AM »
Alright, the MADCTL issue is resolved - I connected the other 1.8" TFT I have here (a NHD-1.8-128160EF-CSXN#) and MADCTL is working as it should, so I removed the workarounds from my code.
I'm trying to send commands and characters to the LCD Screen, and instead of recognizing any of the data coming through via SPI, the screen just prints out the same character that doesn't match any form in the datasheet. This printout happens for every byte that is sent from the Pi to the LCD.

On the oscilloscope and other signal analysis tools, the data looks fine. Our clock speed is under 10kHz, there is definitely data being sent from MOSI, and the chip enable matches up.

I suspect this is some kind of timing issue but we can't seem to figure it out. We're currently using the bcm2835 library for SPI. This problem persists for both a Raspberry Pi Zero W and a Raspberry Pi 3B.

Here is a picture of the LCD Screen characters:
Graphic LCDs / NHD-C12864LZ-FSW-FBW-3V3 correct Vout voltage
« Last post by Spero on June 12, 2018, 11:53:22 PM »

I'm using a NHD-C12864LZ-FSW-FBW-3V3 LCD with the following configuration:
  1uF caps on the CAPxx and Vx pins (4 x voltage booster circuit)
  SPI mode
  /WR, /RD and C86 = Vdd
  PS = 0V

After initialization, the Vout pin = 1.44V whilst the Vx pins are all lower than this (~1.3V)

What should the Vout pin voltage be - 1.44V seems too low?
The display is completely blank after setting the all points on command (0xA5)


TFTs / FPGA driver for NHD-1.8-128160EF TFTs
« Last post by joaBaur on June 12, 2018, 08:45:03 AM »
This is the FPGA driver for the NHD-1.8-128160EF TFTs with the ILI9163 driver IC using the 8 bit parallel interface. The basic design is the same as for the NHD-2.4-240320CF project last week

The driver runs on an Arty Z7-20 FPGA board, reads the HDMI IN video signals and outputs a 160x128 pixel area to the connected TFT via IO. So you can connect a HDMI source to the board and the NHD TFT will display a 160x128 chunk of the picture (or a crudely downscaled 320x256 chunk) on the TFT with a frame rate of 200 fps.

Here's the link to the Github repo:

One strange issue I came across with my test setup (using a NHD-1.8-128160EF-CTXI#-T):
The MADCTL function of the driver (Memory Access Control, determines the orientation/mirroring of the image and the RGB order of the pixels) doesn't work for me. When the init sequence sends the 0x36 MADCTL-command, no matter what data value I send after that, the orientation of the image is always the same and the pixel order is always BGR, like the default 0x00 value that MADCTL is set to after a reset is not updated.

No idea why, maybe an electronic fault of my driver IC's MADCTL register? Other commands work fine, when I send a 0x21 (Display Inversion On) command after the MADCTL cmd+data, the display is inverted as expected, for example.
TFTs / Re: SPI problem with NHD-3.5-320240FT-CSXN-CTP
« Last post by Ted_M on June 12, 2018, 08:35:50 AM »
Hi Rainer,

Please email me the source code you are using with the FTDI MPSSE adapter as well as the wiring diagram for the display interface and we will review them to see if we can help determine what is causing the stability issue you are seeing.

Best Regards,

TFTs / Re: SPI problem with NHD-3.5-320240FT-CSXN-CTP
« Last post by Wiggum on June 11, 2018, 11:33:25 AM »
... hard to get through.

My problem is not the software layer on the Tiva. That's already working. As I explained before: with an evaluation board from FTDI, this is working perfectly.

I would like to see if _you_ can get the display to work with the MPSSE adapter with the sources _you_ provided.
I adapted your sources from gitbub to have the appropriate parameters for the NHD board. Here, at my place (and at our customer's), this is not working well.
Again, I have to say that the FTDI evaluation boards work perfectly with MPSSE. The complete demo application is running through all stages

Sorry for nagging, but this is quite an important issue.

Best regards,


TFTs / Re: SPI problem with NHD-3.5-320240FT-CSXN-CTP
« Last post by Ted_M on June 11, 2018, 11:22:44 AM »
Hi Rainer,

Please take a look at the Github libraries posted on this forum by lightcalamar using our EVE2 boards and running with other hardware platforms.,8447.0.html
These may be of help as a reference to get the SPI working with the Tiva micro. Please let us know if this library is helpful to get you going.

Pages: 1 ... 5 6 [7] 8 9 10