tft lcd frame buffer factory

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.

Good old interlacing is added into the mix: if the amount of pixels that needs updating is detected to be too much that the SPI bus cannot handle it, the driver adaptively resorts to doing an interlaced update, uploading even and odd scanlines at subsequent frames. Once the number of pending pixels to write returns to manageable amounts, progressive updating is resumed. This effectively doubles the maximum display update rate. (If you do not like the visual appearance that interlacing causes, it is easy to disable this by uncommenting the line #define NO_INTERLACING in file config.h)

The result is that the SPI bus can be kept close to 100% saturation, ~94-97% usual, to maximize the utilization rate of the bus, while only transmitting practically the minimum number of bytes needed to describe each new frame.

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.

-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.

-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_CROPPED_INSTEAD_OF_SCALING=ON: If set, and source video frame is larger than the SPI display video resolution, the source video is presented on the SPI display by cropping out parts of it in all directions, instead of scaling to fit.

-DSTATISTICS=number: Specifies the level of overlay statistics to show on screen. 0: disabled, 1: enabled, 2: enabled, and show frame rate interval graph as well. Default value is 1 (enabled).

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 size of the default HDMI output /dev/fb0 framebuffer differs from the resolution of the display, the source video size will by default be rescaled to fit to the size of the SPI display. fbcp-ili9341 will manage setting up this rescaling if needed, and it will be done by the GPU, so performance should not be impacted too much. However if the resolutions do not match, small text will probably appear illegible. The resizing will be done in aspect ratio preserving manner, so if the aspect ratios do not match, either horizontal or vertical black borders will appear on the display. If you do not use the HDMI output at all, it is probably best to configure the HDMI output to match the SPI display size so that rescaling will not be needed. This can be done by setting the following lines in /boot/config.txt:

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.

Ensure turbo speed. This is critical for good frame rates. On the Raspberry Pi 3 Model B, the BCM2835 core runs by default at 400MHz (resulting in 400/CDIV MHz SPI speed) if there is enough power provided to the Pi, and if the CPU temperature does not exceed thermal limits. If the CPU is idle, or voltage is low, the BCM2835 core will instead revert to non-turbo 250MHz state, resulting in 250/CDIV MHz SPI speed. This effect of turbo speed on performance is significant, since 400MHz vs non-turbo 250MHz comes out to +60% of more bandwidth. Getting 60fps in Quake, Sonic or Tyrian often requires this turbo frequency, but e.g. NES and C64 emulated games can often reach 60fps even with the stock 250MHz. If for some reason under-voltage protection is kicking in even when enough power should be fed, you can force-enable turbo when low voltage is present by setting the value avoid_warnings=2 in the file /boot/config.txt.

The option #define SELF_SYNCHRONIZE_TO_GPU_VSYNC_PRODUCED_NEW_FRAMES can be used in conjunction with #define USE_GPU_VSYNC to try to find a middle ground between raspberrypi/userland#440 issues - moderate to little stuttering while not trying to consume too much CPU. Try experimenting with enabling or disabling this setting.

If your SPI display bus is able to run really fast in comparison to the size of the display and the amount of content changing on the screen, you can try enabling #define UPDATE_FRAMES_IN_SINGLE_RECTANGULAR_DIFF option in config.h to reduce CPU usage at the expense of increasing the number of bytes sent over the bus. This has been observed to have a big effect on Pi Zero, so is worth checking out especially there.

If the SPI display bus is able to run really really really fast (or you don"t care about frame rate, but just about low CPU usage), you can try enabling #define UPDATE_FRAMES_WITHOUT_DIFFING option in config.h to forgo the adaptive delta diffing option altogether. This will revert to naive full frame updates for absolutely minimum overall CPU usage.

In display.h there is an option #define TARGET_FRAME_RATE . Setting this to a smaller value, such as 30, will trade refresh rate to reduce CPU consumption.

This does not mean that overall input to display latency in games would be so immediate. Briefly testing a NES emulated game in Retropie suggests a total latency of about 60-80 msecs. This latency is caused by the NES game emulator overhead and extra latency added by Linux, DispmanX and GPU rendering, and GPU framebuffer snapshotting. (If you ran fbcp-ili9341 as a static library bypassing DispmanX and the GPU stack, directly linking your GPIO input and application logic into fbcp-ili9341, you would be able to get down to this few msecs of overall latency, like shown in the above GPIO input video)

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)

Another option that is known to affect how the tearing artifact looks like is the internal panel refresh rate. For ILI9341 displays this refresh rate can be adjusted in ili9341.h, and this can be set to range between ILI9341_FRAMERATE_61_HZ and ILI9341_FRAMERATE_119_HZ (default). Slower refresh rates produce less tearing, but have higher input-to-display latency, whereas higher refresh rates will result in the opposite. Again visually the resulting effect is a bit subjective.

The main option that affects smoothness of display updates is the #define USE_GPU_VSYNC line in config.h. If this is enabled, then the internal Pi GPU HDMI vsync clock is used to drive frames onto the display. The Pi GPU clock runs at a fixed rate that is independent of the content. This rate can be discovered by running tvservice -s on the Pi console, and is usually 59Hz or 60Hz. If your application renders at this rate, animation will look smooth, but if not, there will be stuttering. For example playing a PAL NES game that updates at 50Hz with HDMI clock set at 60Hz will cause bad microstuttering in video output if #define USE_GPU_VSYNC is enabled.

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.

There are two other main options that affect frame delivery timings, #define SELF_SYNCHRONIZE_TO_GPU_VSYNC_PRODUCED_NEW_FRAMES and #define SAVE_BATTERY_BY_PREDICTING_FRAME_ARRIVAL_TIMES. Check out the video fbcp-ili9341 frame delivery smoothness test on Pi 3B and Adafruit ILI9341 at 119Hz for a detailed side by side comparison of these different modes. The conclusions drawn from the four tested scenarios in the video are:

2. vc_dispmanx_vsync_callback() + self synchronization (top right), set #define USE_GPU_VSYNC and #define SELF_SYNCHRONIZE_TO_GPU_VSYNC_PRODUCED_NEW_FRAMES:

This mode uses the GPU vsync signal, but also aims to find and synchronize to the edge trigger when content is producing frames. This is the default build mode on Pi Zero.

The codebase captures screen framebuffers by snapshotting via the VideoCore vc_dispmanx_snapshot() API, and the obtained pixels are then routed on to the SPI-based display. This kind of polling is performed, since there does not exist an event-based mechanism to get new frames from the GPU as they are produced. The result is inefficient and can easily cause stuttering, since different applications produce frames at different paces. Ideally the code would ask the VideoCore API to receive finished frames in callback notifications immediately after they are rendered, but this kind of functionality does not exist in the current GPU driver stack. In the absence of such event delivery mechanism, the code has to resort to polling snapshots of the display framebuffer using carefully timed heuristics to balance between keeping latency and stuttering low, while not causing excessive power consumption. These heuristics keep continuously guessing the update rate of the animation on screen, and they have been tuned to ensure that CPU usage goes down to 0% when there is no detected activity on screen, but it is certainly not perfect. This GPU limitation is discussed at raspberrypi/userland#440. If you"d like to see fbcp-ili9341 operation reduce latency, stuttering and power consumption, please throw a (kind!) comment or a thumbs up emoji in that bug thread to share that you care about this, and perhaps Raspberry Pi engineers might pick the improvement up on the development roadmap. If this issue is resolved, all of the #define USE_GPU_VSYNC, #define SAVE_BATTERY_BY_PREDICTING_FRAME_ARRIVAL_TIMES and #define SELF_SYNCHRONIZE_TO_GPU_VSYNC_PRODUCED_NEW_FRAMES hacks from the previous section could be deleted from the driver, hopefully leading to a best of all worlds scenario without drawbacks.

Currently if one resizes the video frame size at runtime, this causes DispmanX API to go sideways. See raspberrypi/userland#461 for more information. Best workaround is to set the desired screen resolution in /boot/config.txt and configure all applications to never change that at runtime.

By default fbcp-ili9341 builds with a statistics overlay enabled. See the video fbcp-ili9341 ported to ILI9486 WaveShare 3.5" (B) SpotPear 320x480 SPI display to find details on what each field means. Build with CMake option -DSTATISTICS=0 to disable displaying the statistics. You can also try building with CMake option -DSTATISTICS=2 to show a more detailed frame delivery timings histogram view, see screenshot and video above.

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.

Yes, both work fine. For linux command line terminal, the /dev/tty1 console should be set to output to Linux framebuffer 0 (/dev/fb0). This is the default mode of operation and there do not exist other framebuffers in a default distribution of Raspbian, but if you have manually messed with the con2fbmap command in your installation, you may have inadvertently changed this configuration. Run con2fbmap 1 to see which framebuffer the /dev/tty1 console is outputting to, it should print console 1 is mapped to framebuffer 0. Type con2fbmap 1 0 to reset console 1 back to outputting to framebuffer 0.

Likewise, the X windowing system should be configured to render to framebuffer 0. This is by default the case. The target framebuffer for X windowing service is usually configured via the FRAMEBUFFER environment variable before launching X. If X is not working by default, you can try overriding the framebuffer by launching X with FRAMEBUFFER=/dev/fb0 startx instead of just running startx.

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 fbcp-ili9341 has been developed to only display the contents of the main DispmanX GPU framebuffer over to the SPI display. That is, the SPI display will show the same picture as the HDMI output does. There is no technical restriction that requires this though, so if you know C/C++ well, it should be a manageable project to turn fbcp-ili9341 to operate as an offscreen display library to show a completely separate (non-GPU-accelerated) image than what the main HDMI display outputs. For example you could have two different outputs, e.g. a HUD overlay, a dashboard for network statistics, weather, temps, etc. showing on the SPI while having the main Raspberry Pi desktop on the HDMI.

In this kind of mode, you would probably strip the DispmanX bits out of fbcp-ili9341, and recast it as a static library that you would link to in your drawing application, and instead of snapshotting frames, you can then programmatically write to a framebuffer in memory from your C/C++ code.

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= in CMake command line or config.h, and edit config.h to enable #define BACKLIGHT_CONTROL.

The Frame Rate column shows the worst case frame rate when full screen updates are being performed. This occurs for example when watching fullscreen video (that is not a flat colored cartoon). Because fbcp-ili9341 only sends over the pixels that have changed, displays such as HX8357D and ILI9486 can still be used to play many games at 60fps. Retro games work especially well.

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.

Search around, or ask the manufacturer of the display what the maximum SPI bus speed is for the device. This is the most important aspect to getting good frame rates, but unfortunately most web links never state the SPI speed rating, or they state it ridiculously low like in the spec sheets. Try and buy to see, or ask in some community forums from people who already have a particular display to find out what SPI bus speed it can achieve.

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.

Ultimately, it should be noted that parallel displays (DPI) are the proper method for getting fast framerates easily. SPI displays should only be preferred if display form factor is important and a desired product might only exist as SPI and not as DPI, or the number of GPIO pins that are available on the Pi is scarce that sacrificing dozens of pins to RGB data is not feasible.

INT070ATFT and INT070ATFT-TS are embedded display driver boards based on the Displaytech 7 inch 800 x 480 RGB resolution TFT display module. This embedded driver board includes a 7" standard or resistive touchscreen display. Mounted on the embedded board is the Solomon Systech SSD1963 LCD controller that supports common RAM-less LCD drivers and offers the following features and benefits:

I have initialized two layers in an STM32F429. In layer 1, my frame buffer address is set to 0xC0000000 (external SD-RAM). In this layer, I drew some vertical and horizontal lines (to make a grid).

Next, I want to draw a full rectangle in resolution (0,0,200,100,RED) in the second layer of which the current buffer layer address is set to 0xC1000000, somewhere after the first layer in SD-RAM (Make virtual buffers in external SD-RAM).

How can I show two layers simultaneously and just show the second layer in the rectangle resolution, and when the alpha constant is changed, just have the rectangle"s alpha be adjusted, not the whole LCD resolution?

With the continual development of LCD technologies, TFTs have become widely available at a lower price point. The manufacturing process of TFTs has been standardized which has changed the industry for display applications, making TFTs a feasible replacement option for graphic LCDs. This application note will discuss the options for replacing a graphic LCD with a TFT LCD. Considerations of price, size, features and functions will be analyzed to evaluate the options for TFT displays in place of a graphic LCD.

Graphic LCDs are common for industrial applications where the features of TFTs are not justified by price. In recent years, TFT manufacturing has broadened its standard manufacturing process, making TFTs a competitor in typical graphic LCD applications.

TFTs offer additional features that graphic LCDs cannot provide. Such features consist of high color and resolution. TFTs also have the benefit of integrating capacitive and resistive touch functions to the display. If you are considering replacing a current graphic LCD, it may be time to switch to a TFT.

Graphic LCDs are a common display for industrial applications where vivid and high-resolution graphics are not essential to the application. Graphic displays typically have an 8-bit parallel interface which does not require a high frequency clock to communicate with the display. The graphic display in this example has 128 x 64 dots of resolution. This means the memory requirement of the frame buffer for this display is small and is provided by the IC on the display. Graphic LCDs do not offer RGB pixel color and display pixels as either on or off.

Significant limiting factors for graphic LCDs include the resolution and color depth of the display. The options for what can be displayed is restricted to a small area, in this example 128x64 pixels. This means that the image must be very low resolution and text must be very small. Typical graphic LCD applications display text or small user interface option.

The dimensions of G12864B-BW-LW63 are reviewed below. This graphic LCD is close in size to E30RA-FW400-N, the main differences being the mounting of the backlight and the depth of the displays. This graphic LCD is transmissive, STN blue, with a white LED backlight. The demo images will be displayed with white pixels and a blue background.

An example application for this graphic LCD will be reviewed in comparison with the TFT. The graphic LCD is interfaced over an 8-bit parallel connection. The display controller IC, ST7565, provides 8 pages of display RAM, an internal oscillator, and power regulation functions. This makes it easy to control a graphic LCD with a simple 8-bit controller because the main functions are provided internally.

The graphic LCD will display a menu followed by a temperature measurement screen. This is to provide an example of a typical graphic LCD application. Below is an example of the menu and the temperature measurement screen before they are uploaded onto the display.

Pixel size is limited for graphic LCDs. The full page consists of 128x64 pixels so the images must be low resolution and small. The amount of RAM provided by the embedded IC of the display will support 8 full pages of display data. The images must be black and white but will appear as white and blue once uploaded to the display. Below are the images of the display with these example applications uploaded.

The individual pixels can be seen on the graphic LCD and can be altered to project a monochrome image. STN blue graphic LCDs will display white pixels over a blue background. The amount that can be displayed in one page is restricted to 128x64 pixels. Simple icons and characters are common options for graphic display applications.

The design for graphic displays must be simplified to low resolution texts and icons. When you get down to a low resolution, such as 128x64 pixels, every pixel counts in creating a coherent image. This is why there is a standard set of icons used, and you will see them across graphic display applications. These icons are reminiscent of an early Windows computer era, 1980’s/1990’s. Most of these applications have already transferred to higher resolution and colored TFTs.

TFTs have begun to replace graphic LCDs in many applications. This is largely due to the price decrease of the displays and the electronics required to support them. The price of microprocessors and memory chips has substantially decreased, making TFTs a competitive alternative to graphic LCDs. TFT displays have the benefit of higher graphics quality, color, and speed for no extra cost.

The TFT used in this application is close in size to the graphic display. The display can be used both vertically and horizontally by changing the scan direction register. This can also be done by changing the page and column addresses before writing to RAM. The dimensions of the TFT are reviewed below from a vertical reference.

TFT displays offer a higher resolution and color depth. The TFT in this application has a resolution of 480x854 and can display up to 16.7 million colors. The combinations of color and the number of available pixels drastically increases the options for what can be displayed.

The TFT’s size is similar to the graphic LCD, but the resolution area is over six times larger. This makes a significant difference in image quality and available area. Below are the two graphic LCD demos displayed on the TFT.

Both graphic LCD demos can fit in the TFT display resolution and only take up a fraction of the total area available. The resolution of the TFT is highlighted by the amount of data that can be stored in one frame of the display area. Each pixel makes up only a small part of the image which means high resolution images can be portrayed. The same image is uploaded on both the graphic LCD and the TFT below.

TFTs also differ from graphic LCDs because they can display colors. This display supports 24-bits of color data for each pixel. This mean there are 16.7 million colors to select from. The graphic LCD writes to each pixel as on or off. The TFT assigns each pixel 24-bits of color data which means there are 16.7M unique colors that can be displayed.

TFTs have become increasingly standard for most display applications. Even if the application does not require high definition for its intended function, the comparable price for each display type makes the graphics quality an added bonus.

E30RA-FW400-N uses a 24-bit parallel interface and renders 24-bpp of color data for each pixel. This interface is fast enough to support this resolution and color depth to maintain a frame rate of 60 Hz. The only draw-back to this interface is the number of data pins that must be connected to a controller. TFTs come with many different interfaces depending on the resolution.

The graphic LCD demo can be recreated for the TFT to display more complex elements and colors. The addition of color and an increased pixel area gives the display more flexibility on what can be displayed and the quality of the image. TFT displays also have the benefit of touch interface options which can incorporate the user interface on the screen. Below is the example displayed on the TFT.

Some considerations should be made when switching from a graphic LCD to a TFT. A higher resolution means more pixels per frame. An increase in color depth means there is more data assigned to each of the pixels. The memory cost for one page of data can add up quickly depending on size and color depth chosen. The TFT in this example needs a minimum of 1.23MB if using the 24-bpp color depth. A lower color depth can be chosen through commands if you want to reduce memory costs.

The display also requires a higher speed interface to support its resolution and color depth. This display can be interfaced over a 16, 18 or 24-bit parallel interface with a clock cycle of 24.5MHz. This is the minimum speed required to maintain a frame rate of 60Hz. A high-speed controller is also required for this. Since high-speed controllers are becoming more affordable, these constraints are not as significant of a factor as they used to be.

Buyers and others who are developing systems that incorporate FocusLCDs products (collectively, “Designers”) understand and agree that Designers remain responsible for using their independent analysis, evaluation and judgment in designing their applications and that Designers have full and exclusive responsibility to assure the safety of Designers" applications and compliance of their applications (and of all FocusLCDs products used in or for Designers’ applications) with all applicable regulations, laws and other applicable requirements.

Designer agrees that prior to using or distributing any applications that include FocusLCDs products, Designer will thoroughly test such applications and the functionality of such FocusLCDs products as used in such applications.

I"m talking about some nxp mcu like lpc1788 with the lcd controller integrated into the chip so you don"t need to use an external lcd controller. The models you are listing don"t have the lcd controller integrated,.

The main advantage of having it external is that the lcd controller has got its own memory for the frame buffer and it"s easing the load on the cpu because once you load the data it will keep refreshing the screen without calling the cpu and it doesn"t use the cpu ram memory.

In the other case if the lcd controller is integrated in the mcu you can do some nice "tricks" like using a colour look up table or palette so that your graphics takes less memory and because the framebuffer is in your internal memory it is even easier to manipulate.

Also consider that in case of lcd controller not integrated in the panel (so by using the one integrated in the mcu or another one on board as a separate chip) you can exchange panel quite easily so you are not tied to a single manufacturer as long on the lcd side you find the same interface like the 24 bit or the 18 bit.

Now, I"m considering the case of an lcd panel of 640x480 and 8 bit per colour which leads us to 640x480x8 = 2457600 bit / 8 = 307200 / 1024 = 300 KByte of ram needed for the framebuffer.

The integrated lcd controller has got a dma which will take care of transferring the data from external ram used for the frambuffer to the lcd controller which will then translate it and send to lcd but the problem is that the external bus and also the internal bus of the mcu(difficult to draw this here :-) ) is then shared by the lcd controller, which keeps accessing the memory to continuously refresh the screen, and the mcu which is fetching instructions or variables.

Because the internal bus gives priority to the mcu it means that probably you will see tearing effect on the lcd like reported by some people on the nxp question and answer (pasting the link here takes you to the general support page and not to the answer I found) because the mcu gain priority when accessing bus and memory and lcd refresh is delayed.

In the answer I found on Nxp support, they say you can actually change priority so that lcd screen has an higher priority then the cpu, problem is that in doing so the cpu and then your software will be slowed down by the lcd controller continuously refreshing and accessing memories.

The S1D13L01 is a simple, multi-purpose graphics LCD controller with 384 KB embedded SRAM display buffer which supports TFT panels. The S1D13L01 supports most popular CPU interfaces in both 8/16-bit and direct/indirect variations. The embedded display buffer allows WQVGA up to 480x272 at 24bpp or 800x480 8bpp for single layer display, or 480x272 at 16bpp (Main layer) and 480x272 at 8bpp (PIP layer) for two layer display.

The S1D13L04 is a simple, multi-purpose graphics LCD controller which supports color TFT LCD panels with up to XGA resolution. With an external SDRAM memory controller, it allows up to 16Mbyte as a display frame buffer. The S1D13L04 supports most popular CPU interfaces in both 16-bit and direct/indirect variations.

The S1D13L04 is a flexible, low cost, low power solution that meets the demands of embedded markets such as medical, office automation, factory automation, home automation and measuring instruments, where total system cost concerns can still be met when using TFT panels up to XGA resolution. Additionally, it’s impartiality to CPU type or operating system also makes it an ideal display solution for a wide variety of other applications.

NOTE: The S5U13513R00C100 and S5U13513P00C100 evaluation boards can be used to evaluate both the S1D13513 and the S1D13L04 Simple LCD Controller which shares many features with the S1D13513. The following table offers a comparison of the controllers.

The present invention relates to a TFT-LCD (Thin Film Transistor—Liquid Crystal Display) driving method. More particularly, the present invention relates to a TFT-LCD driving method utilizing an over-drive technique.

When an appropriate gray level voltage is applied to a pixel in a TFT LCD panel, the angle of liquid crystal molecule in the pixel will change correspondingly. This angle change further alters transmittance of the TFT-LCD panel so a desired gray level can be achieved. However, due to the intrinsic property of liquid crystal molecule, if the gray level has to change dramatically during two successive refresh periods, the desired angle change may not be achieved in one refresh period. This results in a blurred display, and the situation is particularly bad for a motion picture display.

FIG. 3 is a block diagram showing a TFT-LCD driving system utilizing the over-drive technique. Timing controller 30 retrieves Gnframe image data from an image data source, and retrieves a previous Gn-1frame image data from a frame buffer 32. Timing controller 30 then compares the Gnand Gn-1frame image data and addresses the pixels that need to be updated. Subsequently, timing controller 30 retrieves the Look-Up Table 34 stored in a memory, and converts the image data in the updated pixels to a corresponding over-drive gray level voltage. The over-drive gray level voltage is then applied to the pixel via a source driver.

However, the TFT-LCD driving system utilizing the over-drive technique still has some drawbacks. First, only the pixels where image data has to change during the two successive refresh periods will be updated. This requires several frame buffers to store the previous frame image data in order to compare the image data in the same pixel during the two successive refresh periods. However, frame buffers are expensive and dramatically increase the TFT-LCD manufacture cost. Besides, the Look-Up Table utilized in the over-drive technique is usually stored in EEPROM (Electrically Erasable Programmable Read-Only Memory). If the bits of the driving system were increased, the corresponding Look-Up Table would expand as well, and the memory capacity would also have to increase. This would further raise the manufacturing cost. SUMMARY

Still another objective of the present invention is to provide a TFT-LCD driving system where memory capacity required for storing the Look-Up Table can be minimized.

In accordance with the foregoing and other objectives of the present invention, a TFT-LCD driving method utilizing the over-drive technique is proposed. A bias voltage is first applied to the pixel so the gray level displayed by the pixel changes from an initial gray level to a baseline gray level. Then a target gray level voltage is converted to a corresponding over-drive gray level voltage. Subsequently, the over-drive gray level voltage is applied to the pixel so the gray level displayed by the pixel changes from the baseline gray level to the target gray level.

In accordance with another objective of the present invention, a TFT-LCD utilizing the over-drive technique is proposed. The TFT-LCD includes a panel, a bias source, a timing controller, and a source driver. The panel comprises pixel matrix. The bias source is used for providing a bias voltage so the gray level displayed by the pixel can change from the initial gray level to a baseline gray level. The timing controller converts a target gray level voltage to a corresponding over-drive gray level voltage. The over-drive gray level voltage is then applied to the pixel via the source driver, so the gray level displayed by the pixel changes from the baseline gray level to the required target gray level.

The present invention is directed to a driving method for a TFT-LCD, which allows the pixel to achieve the desired target gray level more rapidly, and the frame buffer is no longer required in the driving system. Additionally, the memory capacity required for storing the Look-Up Table can be minimized. The overall manufacture cost can be further reduced. Moreover, the present invention can simplify the integrated circuit design and the chip size. The power consumption and the blurring effect can also be minimized. The present invention is particularly suitable for motion picture display. BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 4 demonstrates the TFT-LCD driving method according to one preferred embodiment of the present invention. A bias voltage is first applied to the pixel (step 402), so the gray level displayed by the pixel changes from an initial gray level in a previous frame image to a baseline gray level. Any gray level can be selected as the baseline gray level. For example, in an 8-bits driving system, the baseline gray level can be set to the lowest gray level L0or the highest gray level L255. Other appropriate gray level can be selected as the baseline gray level based upon the initial gray level, as long as all pixels return from their respective initial gray level to the same baseline gray level. A target gray level voltage is then retrieved from a image data source, and converted to a corresponding over-drive gray level voltage (step 404). The correlation between the target gray level voltage and the over-drive gray level voltage can be obtained by either a Look-Up Table or a transformation formula. Subsequently, the over-drive gray level voltage is applied to the pixel (step 406) so the gray level displayed by the pixel changes from the baseline gray level to the target gray level.

FIG. 5 is a block diagram illustrating the TFT-LCD driving method according to one preferred embodiment of the present invention. The bias voltage applied to the pixel (step 402) is supplied by an external bias buffer. The external bias buffer 50 is coupled to an output 54 of a source driver 52. When the pixel 56 needs to change from an initial gray level to a baseline gray level, the external bias buffer 50 provides a bias voltage to the output 54 of the source driver 52, so the gray level displayed by the pixel 56 changes from the initial gray level to the baseline gray level.

Moreover, the source driver 52 can provide the bias voltage required for the pixel 56 to return to the baseline gray level itself. By modifying the circuitry of the source driver 52, the bias voltage is supplied to the pixel 56 directly after the source driver 52 provides the initial gray level voltage to the pixel 56 in a previous frame image.

FIG. 6 shows the relation between time and the gray level voltage of the pixel in a Normally Black system according to one preferred embodiment of the present invention. During a bias period 60, the external bias buffer 50 provides the bias voltage to the output 54 of the source driver 52. The gray level voltage 62 of the pixel is then biased on the baseline gray level voltage.

The bias voltage supplied to the pixel can be equal to the baseline gray level voltage. Alternatively, by employing the over-drive technique again, a bias voltage that is higher or lower than the baseline gray level voltage can be supplied, so the pixel can change from the initial gray level to the baseline gray level more rapidly. FIG. 7 illustrates the relation between the gray level voltage and transmittance of the TFT-LCD in an 8-bits Normally Black system. If the lowest gray level L0is selected as the baseline gray level, all pixels are updated to a normally black state after the previous frame image data was written. The external bias buffer 50 provides a common voltage VCOMlower than the baseline gray level voltage V0, so the gray level displayed by the pixel can change more rapidly from the initial gray level to the baseline gray level L0.

Similarly, the over-drive technique can also be employed in a Normally White system so the pixel can return to the baseline gray level more rapidly. FIG. 8 shows the relation between the gray level voltage and transmittance of the TFT-LCD in an 8-bits Normally White system. If the lowest gray level L0is selected as the baseline gray level, in positive polarity, an analog voltage VDDA higher than the baseline gray level voltage V0is provided as the bias voltage. In negative polarity, a ground voltage VGNDlower than the baseline gray level voltage V0is provided as the bias voltage.

After the gray level displayed by the pixel returns from the initial gray level to the baseline gray level by the bias voltage provided by the external bias buffer 50, a target gray level voltage is retrieved from the image data source and converted to a corresponding over-drive gray level voltage. The over-drive gray level voltage is then applied to the pixel so the gray level displayed by the pixel changes from the baseline gray level to the target gray level.

FIG. 9 is a block diagram demonstrating the conversion of the target gray level voltage to the corresponding over-drive gray level voltage according to one preferred embodiment of the present invention. After the gray level voltage of the pixel changes from the initial gray level to the baseline gray level by the external bias buffer 50, timing controller 90 retrieves a target gray level voltage Vyof next frame image data form a image data source. The timing controller 90 then converts the target gray level voltage Vyto a corresponding over-drive gray level voltage Vy′.

According to one preferred embodiment of the present invention, the driving method according to the present invention allows the pixel to achieve the desired target gray level more rapidly, and the frame buffer is no longer required in the driving system. Additionally, the memory capacity required for storing the Look-Up Table can be minimized. The overall manufacture cost can be further reduced. Moreover, the present invention can simplify the integrated circuit design and the chip size. The power consumption and the blurring effect can also be minimized. The present invention is particularly suitable for motion picture display.

3.5" LCD TFT Module LM035NQ09HS-DR02 LM035NQ09HS-DR02 is a 3.5 inch TFT LCD Display with resistive touch.The model is featured with SPI+18BIT RGB interface; This 3.5" TFT Touch Screen Module can be used in embedded systems, POS，industrial device, security and hand-held equipment which require display in high quality and colorful image.

Supplied in 176-pin QFP package, single-chip TX4964FG drives and manages TFT LCD panels found in instrument clusters in automobiles. SoC integrates 120 MHz MIPS-based(TM) TX49/L4 64-bit CPU core, TFT LCD panel controller, digital-camera interface, peripheral controllers, and frame-buffer memory. Its 4 MB embedded DRAM eliminates need for external RAM ICs, reducing system-level power. Also included, dedicated hardware engines for cluster graphics deliver up to 32-bit RGBA colors.

SAN JOSE, Calif., June 13 -- Toshiba America Electronic Components, Inc. (TAEC)*, a committed leader that collaborates with technology companies to create breakthrough designs, today announced the expansion of the Toshiba family of automotive graphics and display controllers with a new system-on-chip (SoC) targeted at instrument-cluster applications ranging from back-up camera displays to full-size, reconfigurable instrument clusters. Designated TX4964FG, the new single-chip solution drives and manages the small-size thin-film transistor (TFT) LCD panels increasingly found in instrument clusters in medium- to high-end automobiles. The highly integrated device integrates the CPU, hardware-graphics engine, TFT LCD panel controller, digital-camera interface and frame-buffer memory in a compact 176-pin QFP package. Its 4 Mbytes of embedded DRAM eliminate the need for external RAM ICs, thereby reducing system-level power and contributing to the small footprint.

"Toshiba took an innovative system approach and developed the new IC to support growing demand from vehicle manufacturers to reduce the system cost, complexity and component count of implementing TFT displays in sizes that typically range from 3-inch to 5-inch and with up to VGA resolution," said Shardul Kazi, vice president of the ASSP Business Unit at Toshiba America Electronic Components, Inc. He said that center-stack displays are gaining acceptance for navigation systems as drivers accustom themselves to using them and reap the benefits of having needed information inside the dashboard in the driver"s focus zone.

The TX4964FG replaces four ICs and reduces design complexity through the integration of a powerful processor, an advanced graphics display controller with dedicated accelerator functions, and a comprehensive range of on-board peripherals and interfaces. The new SoC features Toshiba"s low-power, high-performance MIPS-based(TM) TX49/L4 64-bit CPU core operating at 120 megahertz (MHz). An integrated graphics display controller together with specialized accelerator engines deliver graphics processing and display-control capabilities. Dedicated hardware engines for cluster graphics can deliver up to 32-bit RGBA colors. The graphic accelerator enhances the display output and offers high-quality anti-aliasing to ensure smooth graphics display. The frame grabber works with a wide variety of input data formats; it captures and processes video images and supports applications such as rear-view monitoring.