Recent Posts

Pages: 1 [2] 3 4 ... 10
Hello Brian.

This library GD23ZU supports the MCUs described in the repository; STM32F1x, STM32F4x and STM32F7x, Teensy 3.5 / 6 It hurts with your fabulous NHD screen then use an Arduino MEGA MCU.

If you want to playback video in Arduino MEGA, then you have to use the "sister" library called GD23Z from this repository;

After many frustrating moments, decide my friend (@TFTLCDCyg(MexSpa Team)) and I solve the main thing, use power MCU, Teensy is a very good option, its versions 3.5 and 3.6 have SDIO microSD reader on board and work very fine.

But other MCU's like the ST STM32F767ZI Nucleo is great for a project where up to 3 SPIs are needed and we have achieved it;

However, we have our forum where we can give support in 3 languages such as Spanish, English and French;

Bests regards! Tomas.
Graphic LCDs / Graphic LCD 128x64 LCD-00710 Doesn't Work
« Last post by robinsenny on July 12, 2018, 08:35:53 AM »

I then tried read-modify-write to set individual pixels. My program just set all the pixels one at a time from left to right, top to bottom. It mostly worked, but the reads of the first pixel strip in each bank weren't reliable.I then tried writing blocks of pixels, one pixel at a time, at random places, not at the beginning of a line for either controller. Any time I changed the line, the first read produced garbage, even if the new line was in the same pixel strip as the previous line (e.g., it was the same address in the controller). A curious thing is that if I did two consecutive reads for the first read on each controller after changing lines, without resetting the address between reads, the problem went away.As I tried to figure out what was wrong (playing with delays and such) it got worse and worse until now it won't set any pixels at all. Status reads from the controllers appear to be working (returning 0x20), but pixel writes and reads no longer work at all.I'm driving the display from an ATMEGA32 running on a combo Atmel Dragon / Dragon Rider, using code based on the driver from (I can't spell his name without special characters). I see that "radek"'s code does two reads for each read-modify-write operation. Does anybody understand why this is needed?

Please help.

I didn't find the right solution from the Internet.

Best explainer video companies


I am a new comer and is also using NHD-7.0-800480FT-CSXN-CTP to develop a system.  I downloaded both GD23ZU and SdFat library and put them under Arduino 1.8.5's library folder.   

I am using Arduino Mega2560 as the base board and had the following compiler error:

C:\Dev\Tools\arduino-1.8.5-windows\arduino-1.8.5\libraries\GD23ZU\GD23ZU.cpp: In member function 'byte GDClass::load(const char*, FUNC_POINTER)':

C:\Dev\Tools\arduino-1.8.5-windows\arduino-1.8.5\libraries\GD23ZU\GD23ZU.cpp:1685:13: error: 'SD' was not declared in this scope

   archivo =; 

Checked the code
#if defined(ARDUINO_ARCH_STM32)
   //SdFat SD(3);     // STM32F429
   SdFat SD(2);       // STM32F767

#if defined(TEENSYDUINO)
    SdFatSdioEX SD;   // Teensy 3.6-3.5

and found SD is only defined for ARDUINO_ARCH_STM32 and TEENSYDUINO platform. My problem is that I am not sure my atmega 2560 belongs to which platform.  Or should I use SD(2) or SD?

TFTs / Re: EVE2 Palette8 Pixels
« Last post by warriorofwire on July 07, 2018, 01:07:55 PM »
Oh goodness, hi Paul - thank you for your reply, I didn't have email notification set up for this thread!

I've reached out to FTDI for help.  I read that application note and the extensively.  It is very unclear what the "palette" schema is, and what a paletted bitmap should contain to reference that palette.

Here's the application, sorry for the poor video - I haven't implemented screen capture for video yet:

The tachometer needle is a subtle asset with a blue glow that fades off over the span of a few pixels.  I'd like to retain a very high quality color gradient and use transparency.  I tried using "rgb8888" 32 bit raw bitmap and was unable to get that to work.  Any alternative ideas?  32bpp is expensive, but totally tolerable for this small, high-value asset.

By the way, I thought it was kind of funny that the coprocessor uses "degrees" for rotation when it seems most natural to use "radians" with a transformation matrix  :D
TFTs / Re: Raspberry Pi driver for 1.8" and 2.4" TFT models
« Last post by deanflyer on July 06, 2018, 08:54:55 AM »
Just came across this post. Ive been messing around with theNH 2.4" sunlight readable TFT and the raspberry pi. Unfortunately I managed to short it out, so need to order another one :(

I'm more of a software guy. What im looking for is a small 2.4-3.5" TFT that I can drive at up to 60fps. It needs to be sunlight readable though i.e. ~1000CDM, hence looking at the Newhaven 2.4" displays.

Not 100% tied into Raspberry Pi, as long as I can develop c/c++ code on a SBC and interface it, I'd be happy.

Any thoughts before I order another TFT?
OLEDs / Re: NHD-3.12-25664UCY2 Drawing
« Last post by row_dev on July 05, 2018, 08:33:06 AM »
I ran some further tests. I thought the behaviour looked like the display was running out of power, so I connected the display circuit to an external variable power supply, isolated from the Arduino via an SN74LVC245 8-bit level shifter.

This time I was able to display 3 vertical bars, so I recorded the current taken to display differing numbers of vertical bars:
1 bar = 20 mA  [displayed]
2 bars = 25 mA [displayed]
3 bars = 30 mA [displayed]
4 bars = 14 mA [failed to display]

While the trying to display 4 vertical bars (columns) I decided to tweak the display voltage from 3.3V slowly up to about 4.0V. At 4.0V the display was suddenly able to show the 4 bars at full brightness!

I understood this to be a 3.3V display. Is it possible that I have a 5V version, or is there some other phenomenon at play here?

I attach a photo of the back of the display, showing the model and ID and await further advice before attempting any other work at higher voltages (I really don't want to burn out the display through improper use).
OLEDs / NHD-3.12-25664UCY2 Drawing
« Last post by row_dev on July 04, 2018, 11:35:27 AM »
I have been experimenting with the display on an Arduino Uno using the example code modified to use SPI without the port remapping. I have discovered the settings that allow drawing to the desired pixel:


This eliminates the need to draw to off-screen buffer.

The problem I'm having is that I can draw a small number of pixels anywhere on the screen, but if that number increases the display doesn't display the image properly and is usually too dim to see. In the example pics below I successfully draw two 4 pixel lines at each side of the display. When I draw an additional line in the middle, I can see the line being drawn brightly then very quickly becoming super dark, before drawing is complete. When I fill the entire screen with pixels, it is super dark, but just visible (not bright as in the pic in the post by bill titled "NHD-3.12-25664UCY2 display - inconsistent pixel brightness in same areas").

Any thoughts as to how to get a greater number of bright pixels?
Character LCDs / Re: NHD-0220D3Z-NSW-BBW-V3 using I2C dropping characters
« Last post by jimhogue on July 02, 2018, 03:20:27 PM »
We are using NHD-C0220BIZ-FSW-FBW-3V3M
It seems to have I2C speed issues and does not ack properly if the pull-up resistors are lower than 10K.  We are using an I2C bus, so we have a bit more capacitance than just the micro to the LCD.  It seems the LCD cannot pull the data line low enough to ack properly.  Is this going to be fixed?
Character LCDs / Re: NHD-0220D3Z-NSW-BBW-V3 using I2C dropping characters
« Last post by Paul_B on July 02, 2018, 09:57:10 AM »
Hi bwendin,

Iím sorry to hear about the trouble you are having with the NHD-0220D3Z-NSW-BBW-V3.

There is a known issue on our serial LCD modules which affects its operation when used in I2C mode.
When using the moduleís I2C interface at a clock rate of 100KHz NACKs/bit errors/hanging, may occur.
Therefore, if using the I2C interface of these serial LCD modules, a MAX clock rate of 50KHz should be used.

We have updated the I2C section of our datasheet to reflect this information, and the updated specs should be accessible on our website shortly.
If you have any questions or need any assistance getting these serial LCD modules working, please contact us by emailing our technical support email, or by calling our phone M-F, 8am - 5pm CST (number listed on our website in the contact us section), we're always happy to help!  :D
TFTs / Re: EVE2 Palette8 Pixels
« Last post by Paul_B on July 02, 2018, 09:32:20 AM »
Hi warriorofwire!

Iím sorry to hear about the trouble you are having with storing / displaying Paletted8 bitmaps.

FTDI has an application note for image file conversion (see page 14):

Code: [Select]
//The following code shows a PALETTED8 example for the FT81x. PALETTED8 format is supported
//indirectly in the FT81x and it is different from the PALETTED format in the FT80x. To render
//Alpha, Red, Green and Blue channels, multi-pass drawing action is required.

//addr_pal is the starting address of palette lookup table in RAM_G
//bitmap source(palette indices) is starting from address 0

dl(BITMAP_LAYOUT(PALETTED8, width, height))

dl(BITMAP_SOURCE(0)) //bitmap source(palette indices)


//Draw Alpha channel
dl(VERTEX2II(0, 0, 0, 0))

//Draw Red channel
dl(PALETTE_SOURCE (addr_pal+2))
dl(VERTEX2II (0, 0, 0, 0))

//Draw Green channel
dl(PALETTE_SOURCE(addr_pal + 1))
dl(VERTEX2II(0, 0, 0, 0))

//Draw Blue channel

Regarding the palette / index scheme of FTDI's image converter tool it may be beneficial to seek support from their support team directly.

Hope this helps!

Pages: 1 [2] 3 4 ... 10