stm32 tft lcd controller factory
Our team through qualified training. Skilled professional knowledge, powerful sense of support, to satisfy the support desires of consumers for Stm32 Tft Lcd Tutorial, Lcd Frame, Tft Information Display, Tft Display For Car,Touch Screen Monitor For Pc. We are anticipating to cooperate with you around the basis of mutual added benefits and common development. We are going to never disappoint you. The product will supply to all over the world, such as Europe, America, Australia,Romania, Danish,New Zealand, Denver.We are in continuous service to our growing local and international clients. We aim to be worldwide leader in this industry and with this mind; it is our great pleasure to serve and bringing the highest satisfaction rates among the growing market.
In order to control the TFT-LCD,a design method of TFT-LCD controller is introduced,with the STM32 and the CPLD as the core controller,along with an external SRAM as the display cache.Firstly,the overall architecture of the design is analyzed.The communication protocol between STM32 and CPLD is drawn up inside of STM32.The drive of LCD timing,the parsing of communication protocol and the reading and writing of the SRAM are implemented by the CPLD.At last,the LCD timing and the reading and…Expand
STM32 is a family of 32-bit microcontroller integrated circuits by STMicroelectronics. The STM32 chips are grouped into related series that are based around the same 32-bit ARM processor core, such as the Cortex-M33F, Cortex-M7F, Cortex-M4F, Cortex-M3, Cortex-M0+, or Cortex-M0. Internally, each microcontroller consists of the processor core, static RAM, flash memory, debugging interface, and various peripherals.
The STM32 is a family of microcontroller ICs based on the 32-bit RISC ARM Cortex-M33F, Cortex-M7F, Cortex-M4F, Cortex-M3, Cortex-M0+, and Cortex-M0 cores.STMicroelectronics licenses the ARM Processor IP from ARM Holdings. The ARM core designs have numerous configurable options, and ST chooses the individual configuration to use for each design. ST attaches its own peripherals to the core before converting the design into a silicon die. The following tables summarize the STM32 microcontroller families.
In November 2010, ST announced the STM32 F2-series chips based on the ARM Cortex-M3 core, and future development of chips based on the ARM Cortex-M4 and ARM Cortex-M3 cores.
In September 2012, ST announced full-production of STM32 F3-series chips and STM32F3DISCOVERY board. The STM32 F050-series will also be available in a TSSOP20 package.
In October 2018, ST announced the STM32L5 series, ultra-low-power MCUs based on the ARM Cortex-M33 core with a variety of security features, such as TrustZone, Secure Boot, active IO tamper detection, Secure Firmware Install loader, certified cryptolib etc.
In February 2021, ST announced the STM32U5 series, ultra-low-power MCUs based on the ARM Cortex-M33 core with a variety of low power and security features, such as TrustZone, Secure Boot, active IO tamper detection, hardware-based protection targeting PSA and SESIP assurance level 3, etc.
The STM32 family consists of 17 series of microcontrollers: H7, F7, F4, F3, F2, F1, F0, G4, G0, L5, L4, L4+ L1, L0, U5, WL, WB.Cortex-M7F, Cortex-M4F, Cortex-M33, Cortex-M3, Cortex-M0+, or Cortex-M0 ARM processor core. The Cortex-M4F is conceptually a Cortex-M3DSP and single-precision floating-point instructions.
The STM32 H7-series is a group of high performance STM32 microcontrollers based on the ARM Cortex-M7F core with double-precision floating point unit and optional second Cortex-M4F core with single-precision floating point. Cortex-M7F core can reach working frequency up to 480 MHz, while Cortex-M4F - up to 240 MHz. Each of these cores can work independently or as master/slave core.
The STM32H7 Series is the first series of STM32 microcontrollers in 40 nm process technology and the first series of ARM Cortex-M7-based microcontrollers which is able to run up to 480 MHz, allowing a performance boost versus previous series of Cortex-M microcontrollers, reaching new performance records of 1027 DMIPS and 2400 CoreMark.
The STM32 F7-series is a group of STM32 microcontrollers based on the ARM Cortex-M7F core. Many of the F7 series are pin-to-pin compatible with the STM32 F4-series.
The STM32 F4-series is the first group of STM32 microcontrollers based on the ARM Cortex-M4F core. The F4-series is also the first STM32 series to have DSP and floating-point instructions. The F4 is pin-to-pin compatible with the STM32 F2-series and adds higher clock speed, 64 KB CCM static RAM, full-duplex I²S, improved real-time clock, and faster ADCs. The summary for this series is:
The STM32 F3-series is the second group of STM32 microcontrollers based on the ARM Cortex-M4F core. The F3 is almost pin-to-pin compatible with the STM32 F1-series. The summary for this series is:
The STM32 F2-series of STM32 microcontrollers based on the ARM Cortex-M3 core. It is the most recent and fastest Cortex-M3 series. The F2 is pin-to-pin compatible with the STM32 F4-series. The summary for this series is:
The STM32 F1-series was the first group of STM32 microcontrollers based on the ARM Cortex-M3 core and considered their mainstream ARM microcontrollers. The F1-series has evolved over time by increasing CPU speed, size of internal memory, variety of peripherals. There are five F1 lines: Connectivity (STM32F105/107), Performance (STM32F103), USB Access (STM32F102), Access (STM32F101), Value (STM32F100). The summary for this series is:
The STM32 G4-series is a next generation of Cortex-M4F microcontrollers aiming to replace F3 series, offering the golden mean in productivity and power efficiency, e.g. better power efficiency and performance compared to the older F3/F4 series and higher performance compared to ultra low power L4 series, integrated several hardware accelerators.
The STM32 G0-series is a next generation of Cortex-M0/M0+ microcontrollers for budget market segment, offering the golden mean in productivity and power efficiency, e.g. better power efficiency and performance compared to the older F0 series and higher performance compared to ultra low power L0 series
The STM32 L4+-series is expansion of STM32L4-series of ultra-low power microcontrollers, providing more performance, more embedded memory and richer graphics and connectivity features while keeping ultra-low-power capability.
The STM32 L4-series is an evolution of STM32L1-series of ultra-low power microcontrollers. An example of L4 MCU is STM32L432KC in UFQFPN32 package, that has:
The STM32 L1-series was the first group of STM32 microcontrollers with a primary goal of ultra-low power usage for battery-powered applications. The summary for this series is:
Common peripherals included in all IC packages are USB 2.0 FS, two SPI, two I²C, three USART, eight 16-bit timers, two watchdog timers, temperature sensor, 16 to 24 channels into one ADC, two DACs, 37 to 83 GPIOs, seven DMA, real-time clock (RTC), cyclic redundancy check (CRC) engine. The STM32FL152 line adds a LCD controller.
The STM32 L0-series is the first group of STM32 microcontrollers based on the ARM Cortex-M0+ core. This series targets low power applications. The summary for this series is:
capacitive touch sense and 32-bit random number generator (only L0x2 and L0x3 chips), LCD controller (only L0x3 chips), 128-bit AES engine (only L06x chips).
NUCLEO-G431KB board for STM32G431KB6U MCU with 170 MHz Cortex-M4F core, 128 KB flash (HW ECC), 16 KB SRAM (HW parity), 6 KB SRAM, 10 KB CCM SRAM, STLINK-V3E.
NUCLEO-L412KB board for STM32L412KBU6 MCU with 80 MHz Cortex-M4F core, 128 KB flash (HW ECC), 32 KB SRAM, 8 KB SRAM (HW parity), external quad-SPI memory interface.
NUCLEO-L432KC board for STM32L432KCU6 MCU with 80 MHz Cortex-M4F core, 256 KB flash (HW ECC), 48 KB SRAM, 16 KB SRAM (HW parity), external quad-SPI memory interface.
NUCLEO-F303RE board for STM32F303RET6 MCU with 72 MHz Cortex-M4F core, 512 KB flash, 32 KB SRAM, 48 KB SRAM (HW parity), external static memory interface.
NUCLEO-F446RE board for STM32F446RET6 MCU with 180 MHz Cortex-M4F core, 512 KB flash, 128 KB SRAM, external quad-SPI memory interface, external flexible memory interface.
NUCLEO-L433RC-P board for STM32L433RCT6P MCU with 80 MHz Cortex-M4F core, 256 KB flash (HW ECC), 48 KB SRAM, 16 KB SRAM (HW parity), external quad-SPI memory interface, SMPS power.
NUCLEO-L452RE-P board for STM32L452RET6P MCU with 80 MHz Cortex-M4F core, 512 KB flash (HW ECC), 128 KB SRAM, 32 KB SRAM (HW parity), external quad-SPI memory interface, SMPS power.
NUCLEO-L452RE board for STM32L452RET6 MCU with 80 MHz Cortex-M4F core, 512 KB flash (HW ECC), 128 KB SRAM, 32 KB SRAM (HW parity), external quad-SPI memory interface.
NUCLEO-L476RG board for STM32L476RGT6 MCU with 80 MHz Cortex-M4F core, 1024 KB flash (HW ECC), 96 KB SRAM, 32 KB SRAM (HW parity), external quad-SPI memory interface, external static memory interface.
This family has 144-pin STM32 ICs, Arduino Uno Rev3 female headers, ST Zio female headers, ST Morpho male pin headers (two 19x2), second Micro-AB USB connector, and RJ45 Ethernet connector (some boards).
NUCLEO-F207ZG board for STM32F207ZGT6 MCU with 120 MHz Cortex-M3 core, 1024 KB flash (HW ECC), 128 KB SRAM, 4 KB battery-back SRAM, external static memory interface, ethernet.
NUCLEO-F303ZE board for STM32F303ZET6 MCU with 72 MHz Cortex-M4F core, 512 KB flash (HW ECC), 32 KB SRAM, 48 KB SRAM (HW parity), external static memory interface.
NUCLEO-F412ZG board for STM32F412ZGT6 MCU with 100 MHz Cortex-M4F core, 1024 KB flash, 256 KB SRAM, external quad-SPI memory interface, external static memory interface.
NUCLEO-F429ZI board for STM32F429ZIT6 MCU with 180 MHz Cortex-M4F core, 2048 KB flash, 256 KB SRAM, 4 KB battery-back SRAM, external flexible memory interface, ethernet.
NUCLEO-F439ZI board for STM32F439ZIT6 MCU with 180 MHz Cortex-M4F core, 2048 KB flash, 256 KB SRAM, 4 KB battery-back SRAM, external flexible memory interface, ethernet, cryptographic acceleration.
NUCLEO-F446ZE board for STM32F446ZET6 MCU with 180 MHz Cortex-M4F core, 512 KB flash, 128 KB SRAM, 4 KB battery-back SRAM, external quad-SPI memory interface, external flexible memory interface.
NUCLEO-F746ZG board for STM32F746ZGT6 MCU with 216 MHz Cortex-M7F core (4 KB data cache, 4 KB instruction cache), 1024 KB flash, 336 KB SRAM, 4 KB battery-back SRAM, 1 KB OTP, external quad-SPI memory interface, external flexible memory interface, ethernet.
NUCLEO-F767ZI board for STM32F767ZIT6 MCU with 216 MHz Cortex-M7F-DP core (16 KB data cache, 16 KB instruction cache), 2048 KB flash, 528 KB SRAM, 4 KB battery-back SRAM, external quad-SPI memory interface, external flexible memory interface, ethernet.
The following Discovery evaluation boards are sold by STMicroelectronics to provide a quick and easy way for engineers to evaluate their microcontroller chips. These kits are available from various distributors for less than US$20. The STMicroelectronics evaluation product licence agreement forbids their use in any production system or any product that is offered for sale.
A discovery board for STM32F429ZIT6 microcontroller with 180 MHz ARM Cortex-M4F core, 2048 KB flash, 256 KB RAM, 4 KB battery-backed RAM in LQFP144 package.
This board includes an integrated ST-LINK/V2 debugger via Mini-B USB connector, 8 MB SDRAM (IS42S16400J), 2.4-inch 320x200 TFT LCD color display (SF-TC240T), touchscreen controller (STMPE811), gyroscope (L3GD20), 2 user LEDs, user button, reset button, Full-Speed USB OTG to second Micro-AB USB connector, and two 32x2 male pin headers.
A discovery board for STM32F407VGT6 microcontroller with 168 MHz ARM Cortex-M4F core, 1024 KB flash, 192 KB RAM, 4 KB battery-backed RAM in LQFP100 package.
A discovery board for STM32L152RBT6 microcontroller with 32 MHz ARM Cortex-M3 core, 128 KB flash (with ECC), 16 KB RAM, 4 KB EEPROM (with ECC) in LQFP64 package.
This board includes an integrated ST-LINK/V2 debugger via Mini-B USB connector, 24-segment LCD, touch sensors, 2 user LEDs, user button, reset button, and two 28x1 male pin headers.
A discovery board for STM32L152RCT6 microcontroller with 32 MHz ARM Cortex-M3 core, 256 KB flash (with ECC), 32 KB RAM, 8 KB EEPROM (with ECC) in LQFP64 package.
This board includes an integrated ST-LINK/V2 debugger via Mini-B USB connector, 24-segment LCD, touch sensors, 2 user LEDs, user button, reset button, and two 28x1 male pin headers.
A discovery board for STM32L100RCT6 microcontroller with 32 MHz ARM Cortex-M3 core, 256 KB flash (with ECC), 16 KB RAM, 4 KB EEPROM (with ECC) in LQFP64 package.
A ready-to-use Java development kits for its STM32 microcontrollers. The STM3220G-JAVA Starter Kit combines an evaluation version of IS2T"s MicroEJ® Software Development Kit (SDK) and the STM32F2 series microcontroller evaluation board providing everything engineers need to start their projects.
MicroEJ provides extended features to create, simulate, test and deploy Java applications in embedded systems. Support for Graphical User Interface (GUI) development includes a widget library, design tools including storyboarding, and tools for customizing fonts.STM32F205VGT6J.
A prototyping environment for a variety of STM32 variants, which allows users to create their applications using an application programming interface (API) to implement device peripherals and a range of evaluation features on the EvoPrimer base including TFT color touchscreen, graphical user interface, joy stick, codec-based audio, SD card, IrDA and standard peripherals such as USB, USART, SPI, I2C, CAN, etc.
Simulink, by MathWorks provides model-based design solutions to design embedded systems. The Embedded Coder Support Package for STMicroelectronics Discovery Boards and the Simulink Coder Support Package for STMicroelectronics Nucleo Boards provide parameter tuning, signal monitoring and one-click deployment of Simulink algorithms to STM32 boards with access to peripherals like ADC, PWM, GPIOs, I²C, SPI, SCI, TCP/IP, UDP, etc.
All STM32 microcontrollers have a ROM"ed bootloader that supports loading a binary image into its flash memory using one or more peripherals (varies by STM32 family). Since all STM32 bootloaders support loading from the USART peripheral and most boards connect the USART to RS-232 or a USB-to-UART adapter IC, thus it"s a universal method to program the STM32 microcontroller. This method requires the target to have a way to enable/disable booting from the ROM"ed bootloader (i.e. jumper / switch / button).
STMicroelectronics has additional documents, such as: evaluation board user manuals, application notes, getting started guides, software library documents, errata, and more. See External Links section for links to official STM32 and ARM documents.
The Insider"s Guide To The STM32 ARM Based Microcontroller; 2nd Edition (v1.8); Trevor Martin; Hitex; 96 pages; 2009; ISBN 0-9549988-8-X. (Download) (Other Guides)
µC/TCP-IP: The Embedded Protocol Stack for the STMicroelectronics STM32F107; 1st Edition; Christian Légaré; Micrium; 824 pages; 2010; ISBN 978-0-9823375-0-9.
In these videos, the SPI (GPIO) bus is referred to being the bottleneck. SPI based displays update over a serial data bus, transmitting one bit per clock cycle on the bus. A 320x240x16bpp display hence requires a SPI bus clock rate of 73.728MHz to achieve a full 60fps refresh frequency. Not many SPI LCD controllers can communicate this fast in practice, but are constrained to e.g. a 16-50MHz SPI bus clock speed, capping the maximum update rate significantly. Can we do anything about this?
The fbcp-ili9341 project started out as a display driver for the Adafruit 2.8" 320x240 TFT w/ Touch screen for Raspberry Pi display that utilizes the ILI9341 controller. On that display, fbcp-ili9341 can achieve a 60fps update rate, depending on the content that is being displayed. Check out these videos for examples of the driver in action:
Given that the SPI bus can be so constrained on bandwidth, how come fbcp-ili9341 seems to be able to update at up to 60fps? The way this is achieved is by what could be called adaptive display stream updates. Instead of uploading each pixel at each display refresh cycle, only the actually changed pixels on screen are submitted to the display. This is doable because the ILI9341 controller, as many other popular controllers, have communication interface functions that allow specifying partial screen updates, down to subrectangles or even individual pixel levels. This allows beating the bandwidth limit: for example in Quake, even though it is a fast pacing game, on average only about 46% of all pixels on screen change each rendered frame. Some parts, such as the UI stay practically constant across multiple frames.
This driver does not utilize the notro/fbtft framebuffer driver, so that needs to be disabled if active. That is, if your /boot/config.txt file has lines that look something like dtoverlay=pitft28r, ..., dtoverlay=waveshare32b, ... or dtoverlay=flexfb, ..., those should be removed.
Likewise, if you have any touch controller related dtoverlays active, such as dtoverlay=ads7846,... or anything that has a penirq= directive, those should be removed as well to avoid conflicts. It would be possible to add touch support to fbcp-ili9341 if someone wants to take a stab at it.
-DPIRATE_AUDIO_ST7789_HAT=ON: If specified, targets a Pirate Audio 240x240, 1.3inch IPS LCD display HAT for Raspberry Pi with ST7789 display controller
-DKEDEI_V63_MPI3501=ON: If specified, targets a KeDei 3.5 inch SPI TFTLCD 480*320 16bit/18bit version 6.3 2018/4/9 display with MPI3501 display controller.
If you connected wires directly on the Pi instead of using a Hat from the above list, you will need to use the configuration directives below. In addition to specifying the display, you will also need to tell fbcp-ili9341 which GPIO pins you wired the connections to. To configure the display controller, pass one of:
-DILI9486L=ON: If you have a ILI9486L display, pass this directive. Note that ILI9486 and ILI9486L are quite different, mutually incompatible controller chips, so be careful here identifying which one you have. (or just try both, should not break if you misidentified)
-DGPIO_TFT_DATA_CONTROL=number: Specifies/overrides which GPIO pin to use for the Data/Control (DC) line on the 4-wire SPI communication. This pin number is specified in BCM pin numbers. If you have a 3-wire SPI display that does not have a Data/Control line, set this value to -1, i.e. -DGPIO_TFT_DATA_CONTROL=-1 to tell fbcp-ili9341 to target 3-wire ("9-bit") SPI communication.
-DGPIO_TFT_RESET_PIN=number: Specifies/overrides which GPIO pin to use for the display Reset line. This pin number is specified in BCM pin numbers. If omitted, it is assumed that the display does not have a Reset pin, and is always on.
-DGPIO_TFT_BACKLIGHT=number: Specifies/overrides which GPIO pin to use for the display backlight line. This pin number is specified in BCM pin numbers. If omitted, it is assumed that the display does not have a GPIO-controlled backlight pin, and is always on. If setting this, also see the #define BACKLIGHT_CONTROL option in config.h.
-DDISPLAY_SWAP_BGR=ON: If this option is passed, red and blue color channels are reversed (RGB<->BGR) swap. Some displays have an opposite color panel subpixel layout that the display controller does not automatically account for, so define this if blue and red are mixed up.
Here is a full example of what to type to build and run, if you have the Adafruit 2.8" 320x240 TFT w/ Touch screen for Raspberry Pi with ILI9341 controller:
If the above does not work, try specifying -DSPI_BUS_CLOCK_DIVISOR=8 or =10 to make the display run a little slower, or try with -DUSE_DMA_TRANSFERS=OFF to troubleshoot if DMA might be the issue. If you are using another display controller than ILI9341, using a much higher value, like 30 or 40 may be needed. When changing CMake options, you can reissue the CMake directive line without having to reclone or recreate the build directory. However you may need to manually delete file CMakeCache.txt between changing options to avoid CMake remembering old settings.
These lines hint native applications about the default display mode, and let them render to the native resolution of the TFT display. This can however prevent the use of the HDMI connector, if the HDMI connected display does not support such a small resolution. As a compromise, if both HDMI and SPI displays want to be used at the same time, some other compatible resolution such as 640x480 can be used. See Raspberry Pi HDMI documentation for the available options to do this.
Perhaps a bit counterintuitively, underclock the core. Setting a smaller core frequency than the default turbo 400MHz can enable using a smaller clock divider to get a higher resulting SPI bus speed. For example, if with default core_freq=400 SPI CDIV=8 works (resulting in SPI bus speed 400MHz/8=50MHz), but CDIV=6 does not (400MHz/6=66.67MHz was too much), you can try lowering core_freq=360 and set CDIV=6 to get an effective SPI bus speed of 360MHz/6=60MHz, a middle ground between the two that might perhaps work. Balancing core_freq= and CDIV options allows one to find the maximum SPI bus speed up to the last few kHz that the display controller can tolerate. One can also try the opposite direction and overclock, but that does then of course have all the issues that come along when overclocking. Underclocking does have the drawback that it makes the Pi run slower overall, so this is certainly a tradeoff.
Unfortunately a limitation of SPI connected displays is that the VSYNC line signal is not available on the display controllers when they are running in SPI mode, so it is not possible to do vsync locked updates even if the SPI bus bandwidth on the display was fast enough. For example, the 4 ILI9341 displays I have can all be run faster than 75MHz so SPI bus bandwidth-wise all of them would be able to update a full frame in less than a vsync interval, but it is not possible to synchronize the updates to vsync since the display controllers do not report it. (If you do know of a display that does actually expose a vsync clock signal even in SPI mode, you can try implementing support to locking on to it)
If USE_GPU_VSYNC is disabled, then a busy spinning GPU frame snapshotting thread is used to drive the updates. This will produce smoother animation in content that does not maintain a fixed 60Hz rate. Especially in OpenTyrian, a game that renders at a fixed 36fps and has slowly scrolling scenery, the stuttering caused by USE_GPU_VSYNC is particularly visible. Running on Pi 3B without USE_GPU_VSYNC enabled produces visually smoother looking scrolling on an Adafruit 2.8" ILI9341 PiTFT set to update at 119Hz, compared to enabling USE_GPU_VSYNC on the same setup. Without USE_GPU_VSYNC, the dedicated frame polling loop thread "finds" the 36Hz update rate of the game, and then pushes pixels to the display at this exact rate. This works nicely since SPI displays disregard vsync - the result is that frames are pushed out to the SPI display immediately as they become available, instead of pulling them at a fixed 60Hz rate like HDMI does.
The fbcp part in the name means framebuffer copy; specifically for the ILI9341 controller. fbcp-ili9341 is not actually a framebuffer copying driver, it does not create a secondary framebuffer that it would copy bytes across to from the primary framebuffer. It is also no longer a driver only for the ILI9341 controller. A more appropriate name might be userland-raspi-spi-display-driver or something like that, but the original name stuck.
If the display controller is one of the currently tested ones (see the list above), and it is wired up to run using 4-line SPI, then it should work. Pay attention to configure the Data/Control GPIO pin number correctly, and also specify the Reset GPIO pin number if the device has one.
If the display controller is not one of the tested ones, it may still work if it is similar to one of the existing ones. For example, ILI9340 and ILI9341 are practically the same controller. You can just try with a specific one to see how it goes.
If fbcp-ili9341 does not support your display controller, you will have to write support for it. fbcp-ili9341 does not have a "generic SPI TFT driver routine" that might work across multiple devices, but needs specific code for each. If you have the spec sheet available, you can ask for advice, but please do not request to add support to a display controller "blind", that is not possible.
Perhaps. This is a more recent experimental feature that may not be as stable, and there are some limitations, but 3-wire ("9-bit") SPI display support is now available. If you have a 3-wire SPI display, i.e. one that does not have a Data/Control (DC) GPIO pin to connect, configure it via CMake with directive -DGPIO_TFT_DATA_CONTROL=-1 to tell fbcp-ili9341 that it should be driving the display with 3-wire protocol.
At the moment one cannot utilize the XPT2046/ADS7846 touch controllers while running fbcp-ili9341, so touch is mutually incompatible with this driver. In order for fbcp-ili9341 to function, you will need to remove all dtoverlays in /boot/config.txt related to touch.
double check that the display controller is really what you expected. Trying to drive with the display with wrong initialization code usually results in the display not reacting, and the screen stays white,
This suggests that the power line or the backlight line might not be properly connected. Or if the backlight connects to a GPIO pin on the Pi (and not a voltage pin), then it may be that the pin is not in correct state for the backlight to turn on. Most of the LCD TFT displays I have immediately light up their backlight when they receive power. The Tontec one has a backlight GPIO pin that boots up high but must be pulled low to activate the backlight. OLED displays on the other hand seem to stay all black even after they do get power, while waiting for their initialization to be performed, so for OLEDs it may be normal for nothing to show up on the screen immediately after boot.
If the backlight connects to a GPIO pin, you may need to define -DGPIO_TFT_BACKLIGHT=
This suggests same as above, increase SPI bus divisor or troubleshoot disabling DMA. If DMA is detected to be the culprit, try changing up the DMA channels. Double check that /boot/config.txt does not have any dtoverlays regarding other SPI display drivers or touch screen controllers, and that it does NOT have a dtparam=spi=on line in it - fbcp-ili9341 does not use the Linux kernel SPI driver.
Second is the consideration about display speed. Below is a performance chart of the different displays I have tested. Note that these are sample sizes of one, I don"t know how much sample variance there exists. Also I don"t know if it is likely that there exists big differences between displays with same controller from different manufacturers. At least the different ILI9341 displays that I have are all quite consistent on performance, whether they are from Adafruit or WaveShare or from BuyDisplay.com.
In this list, Rated SPI Bus Speed is the maximum clock speed that the display controller is rated to run at. The Obtained Bus Speed column lists the fastest SPI bus speed that was achieved in practice, and the core_freq BCM Core speed and SPI Clock Divider CDIV setting that was used to achieve that rate. Note how most display controllers can generally be driven much faster than what they are officially rated at in their spec sheets.
All the ILI9341 displays work nice and super fast at ~70-80MHz. My WaveShare 3.5" 320x480 ILI9486 display runs really slow compared to its pixel resolution, ~32MHz only. See fbcp-ili9341 ported to ILI9486 WaveShare 3.5" (B) SpotPear 320x480 SPI display for a video of this display in action. Adafruit"s 320x480 3.5" HX8357D PiTFTs is ~64% faster in comparison.
The ILI9486L controller based maithoga display runs a bit faster than ILI9486 WaveShare, 50MHz versus 31.88MHz, i.e. +56.8% bandwidth increase. However fps-wise maithoga reaches only 13.56 vs WaveShare 12.97 fps, because the bandwidth advantage is fully lost in pixel format differences: ILI9486L requires transmitting 24 bits per each pixel (R6G6B6 mode), whereas ILI9486 supports 16 bits per pixel R5G6B5 mode. This is reflected in the above chart refresh rate for the maithoga display (marked with a star).
The KeDei v6.3 display with MPI3501 controller takes the crown of being horrible, in all aspects imaginable. It is able to run at 33.33 MHz, but due to technical design limitations of the display (see #40), effective bus speed is halved, and only about 72% utilization of the remaining bus rate is achieved. DMA cannot be used, so CPU usage will be off the charts. Even though fbcp-ili9341 supports this display, level of support is expected to be poor, because the hardware design is a closed secret without open documentation publicly available from the manufacturer. Stay clear of KeDei or MPI3501 displays.
The Tontec MZ61581 controller based 320x480 3.5" display on the other hand can be driven insanely fast at up to 140MHz! These seem to be quite hard to come by though and they are expensive. Tontec seems to have gone out of business and for example the domain itontec.com from which the supplied instructions sheet asks to download original drivers from is no longer registered. I was able to find one from eBay for testing.
One might think that since Pi Zero is slower than a Pi 3, the SPI bus speed might not matter as much when running on a Pi Zero, but the effect is rather the opposite. To get good framerates on a Pi Zero, it should be paired with a display with as high SPI bus speed capability as possible. This is because the higher the SPI bus speed is, the more autonomously a DMA controller can drive it without CPU intervention. For the same reason, the interlacing technique does not (currently at least) perform well on a Pi Zero, so it is disabled there by default. ILI9341s run well on Pi Zero, ILI9486 on the other hand is quite difficult to combine with a Pi Zero.
Do you have a display with an unlisted or unknown display controller? Post close up photos of it to an issue in the tracker, and report if you were able to make it work with fbcp-ili9341?
Improve existing display initialization routines with options to control e.g. gamma curves, color saturation, driving voltages, refresh rates or other potentially useful features that the display controller protocols expose.