ST7789Vi and Linux
-
I'm running the initialization as listed in the manual and I still have no activity. The SPI output is shown below. Earlier in the trace I set RESET low for 250ms and back high before sending the SPI data.
0 -
Hi Steven,
Please refer to our example code on Github for the NHD-2.4-240320CF-BSXV-FT
https://github.com/NewhavenDisplay/NHD-2.4-240320CF-BSXV_Example/blob/main/NHD-2.4-240320CF-BSXV/NHD-2.4-240320CF-BSXV.ino
Regards,0 -
I recently got an ST7789Vi based display (NHD-2.4-240320CF) working on a Raspberry Pi as a framebuffer. Sample device tree overlay here if it helps:
https://github.com/docsteer/nhd-2.4-240320CF-raspberry0 -
Hi folks!
I have an NHD-2.4-240320CF-CSXN#-F and would like to learn how to drive it from my Raspberry Pi. I am hoping for about 30 fps performance.
https://newhavendisplay.com/2-4-inch-sunlight-readable-tft-without-touchscreen/
1. If I use a serial interface (e.g. SPI), what frame rates should I expect?
2. Is there example code or guidelines for using the parallel (MCU) interface? What frame rates would that produce?
Ihab
0 -
Hello Ihab,
NHD-2.4-240320CF-CSXN#-F only uses parallel interface. When pushing the parallel interface to its limit (pixel clock cycle of 66ns), you can theoretically achieve approximately 197fps. (Not taking blanking and other overhead into account) However, since the display only has a 60Hz refresh rate, it is recommended to lock your interface timing to achieve either 30 or 60fps.
NHD-2.4-240320CF-BSXV-F uses SPI. When pushing the SPI interface to its limit (serial clock cycle of 16ns), you can theoretically achieve approximately 100fps. (Not taking blanking and other overhead into account) However, the same limitations apply from the parallel display noted above.
You will need to check the maximum clock speed available on your Raspberry Pi and related interfaces.
If you have any questions, don't hesitate to ask.
Best Regards,
Cody J.
0 -
Thank you Cody! That's very helpful and encouraging! Is there example code that uses the parallel interface that I can learn from? It can be just a simple piece of "C" code. I don't need a framebuffer or X11 driver since my application draws directly to an in-memory buffer, which I can easily copy to the display.
Ihab
0 -
Hello Ihab,
We have some some Arduino example code on our GitHub page: NHD-2.4-240320CF-Cxxx_Example.
Some older example code is available on our website as well: 2.4" TFT - ST7789 Controller
Best Regards,
Cody J.
0 -
Great thank you!!
0 -
Greetings folks. I am using your example code:
https://github.com/NewhavenDisplay/NHD-2.4-240320CF-Cxxx_ExampleI have wired up my NHD-2.4-240320CF-CSXN#-F display as per the following:
https://docs.google.com/document/d/19uVzLAgJj0jGkHMyoQxAFoSPemK3wM3PW2JKhrLxPq0/editThis is a photo of my setup:
https://photos.app.goo.gl/KCWxWHpHr7wW1eo38
I am using a 40-pin FPC breakout and using an NHD-TFT40 to generate the backlight current, via LEDK and LEDA.
When I run the program, it does ... nothing.
https://photos.app.goo.gl/5fyzBKKNiJR4co3z6I have built two different versions of my wiring and used two different Arduino boards. Is there something obvious I am doing wrong?
Ihab
0 -
Hi Ihab,
The NHD-2.4-240320CF-CSXN#-F display requires a 3.3V I/O logic level to drive the command and data lines. You may need to use logic level shifters from the Uno to the display, or change the 5V regulator on the Uno to a 3.3V regulator.
Best Regards,
Ted
0 -
Oh you're kidding. :( I'm so sorry for making such a fundamental mistake! I have been using an ESP32 for years, with 3.3V logic levels. Thank you so much for the tip!!!!
Ihab
0 -
Thank you very much for the support so far. I can report success! First, this is the display driven by an ESP32 development board. The Newhaven demo code is working well:
https://photos.app.goo.gl/FSzsNZdYoLoC9o4r7
Next, this is the same code adapted to a Raspberry Pi, using the pigpio (https://abyz.me.uk/rpi/pigpio/) library. I had to insert busy-waits in the code to avoid glitches, and even then the results are not perfect. I expect this is due to signal integrity issues with my hacky wiring, because the spec for the display itself indicates T_WC (write cycle) of 66 ns, or (theoretically) 98 frames per second.
https://photos.app.goo.gl/bKichDnmigQKJnf19
Ihab
0 -
Greetings folks!
I am using a Raspberry Pi and the 16-bit interface mode. For now, I am using plain GPIO operations to toggle the pinouts. My observation is: I cannot paint a frame faster than what would yield approximately 8.5 fps before the display starts getting flakey.
As I dig more into this, I'd really like to know: What is the maximum speed that Newhaven knows of, or has attempted, in driving this display?
Kind regards,
Ihab
0 -
My test code is here:
https://drive.google.com/file/d/12DP3WwnvoRKivdJ4pV5Kp8ve7FpO3dgs/view?usp=sharing
At WRITE_CYCLE_BUSY_WAIT_COUNT=250, I get 8.5 fps, and the display is stable:https://photos.app.goo.gl/iTrVBYjVExkgezrn9
At WRITE_CYCLE_BUSY_WAIT_COUNT=125, I get 14.5 fps, and the display is visibly jittery:
https://photos.app.goo.gl/zR7WbZqg9rpcXS5t5
Ihab
0 -
Hi Ihab,
This display we drive it at a frame rate of 60Hz since that is the default settings. Please refer to ST7789V IC datasheet table Frame Rate Control in Normal Mode(page284) for more information.
Could you explain how you obtained the 8.5 and 14.5 fps?
I also noticed in your code attached that your setup function doesn't have all the initialization sequence.
Is there a reason why it got commented?0 -
Thank you for the reply!
Initialization sequence: I was fiddling with the functions to get them to work and this is how I left the code. I can indeed un-comment the extra initializations. I apologize for this omission.
Frame rate: When I say "a frame rate of X fps", I mean, I measure the time of my entire GPIO write cycle for a whole 320 x 240 x 16bpp frame, and then determine how many such write cycles I can do in one second.
The interesting point here is that, as illustrated by this additional video:
https://photos.app.goo.gl/bQ7eeVr4sTorKVg87
When I paint a solid color (the same 16-bit value over and over again, strobing the /WR pin), I get a good signal. When I paint a pattern where the values vary from one pixel to the next, I get flicker. So my assumption is that I am making an error in my timing of my write cycle.
If there are obvious errors in the sequence of operations in my code, I would appreciate knowing them. Otherwise, I will measure and provide oscilloscope traces for your reference as soon as I have access to the equipment!
Thank you again,
Ihab
0 -
Hi Ihab,
Could you please uncomment the code as it is part of the proper initialization.
Also, in the following function:
void loop(){
std::cout << "loop()" << std::endl;
pixel(0xffff);
delay(500);
pixel(0x0000);
delay(500);
for (int i = 0; i < 100; i++) {
gradient();
}
delay(500);
}you have gradient() in a loop, can you remove it from the loop. You might be overwriting your image over and over again causing a to look like its "flickering/moving"
0 -
Hi folks. I finally figured out the problem. I hope this is of use to others on this forum!
Writes to the GPIOs of the Raspberry Pi do not necessarily complete "immediately" -- they are subject to the same delays as writing regular memory. To make my program wait till the write is complete, I needed to read the values back. Once I did that, my display works very reliably!
I am sure this would be a common pitfall for anyone doing what I did -- porting the NHD code "blindly" from an Arduino to an application microprocessor like that in the Raspberry Pi!
https://forums.raspberrypi.com/viewtopic.php?t=341861
Ihab
0 -
Hi Ihab,
I am glad you were able to figure it out. Thank you for your input.
0
Please sign in to leave a comment.
Comments
19 comments