minimum clock speed needed for lcd tft display price
Since the display includes the Ilitek ILI9320 controller, then your interface requirements are much lower, as the microcontroller no longer has to interface directly with the TFT and instead only talks to the controller chip via a simple interface: either SPI, which takes six wires: RS, CS, CLK, MOSI, MISO and RESET. Or you can use an 8080-compatible parallel interface which takes 13 wires: an 8-bit data bus, and RS, CS, WR, RD and RESET. (There are options to use larger data-buses, up to 18 bits, but I don"t recommend that for a low end microcontroller.)
There are two optional interfaces in which the microcontroller generates all of the clock signals (VSYNC, HSYNC and DOTCLK); you don"t want to do that since it would require a high-end controller.
So just about any microcontroller will do, however you need to have enough flash memory to hold whatever static items you want to display; for example if you are going to be displaying text then you will need to allocate arrays to store bitmaps for whatever fonts you will use. Even a small font can take 60KB.
I"m using an ILI9341-based LCD module, and the 4-wire SPI interface to communicate with it. According to the datasheet"s spec for this interface, I should be able to write at up to 1s/100ns(twc)=10Mhz, and read at up to 1s/150ns(trc)=6.66Mhz.
However, I am successfully writing and reading at 24Mhz! Not just for a simple test case, either. I"m doing complex graphics, mixed reads/writes for alpha blends, both 16-bit and 24-bit pixel writes, and so on - yet haven"t seen a single glitch. (Except those caused when I bump my dodgy old breadboard or jumper wires. That I"m using such poor connections, and it"s still working at this speed when not physically disturbed, make this even more amazing. The signal integrity must be horrible.)
In the past I"ve tried communicating with other complex SPI devices at speeds past their ratings, just to see what would happen. All started showing issues with modest increases, even when run at max Vdd. Yet I"m reading from this at 360% of its max rated speed! And I know of cases of others doing the same with their ILI9341-based LCD, as well.
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.
The two displays that will be reviewed in this application are described in the table below. These displays are similar in size and cost but vary in features and technical specifications.
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.
This website is using a security service to protect itself from online attacks. The action you just performed triggered the security solution. There are several actions that could trigger this block including submitting a certain word or phrase, a SQL command or malformed data.
Low voltage differential signaling (LVDS, also known as OpenLDI) thin-film transistor (TFT) liquid crystal (LCD) displays typically have a specified resolution and minimum required clock frequency to meet desired resolution. Normally, you will find this information listed in the display data sheet and won’t need to perform any calculations.
However, if you do not yet have access to your display data sheet and only know what resolution you want your system to support, you can estimate what clock frequency you need and determine which serializer/deserializer (SerDes) is appropriate for your application.
%Blanking: The blanking period, or the percentage of time when active video is not being displayed. As shown in Figure 1, it is represented horizontally as horizontal pulse width (HPW), horizontal back porch (HBP) and horizontal front porch (HFP). It is also represented vertically as vertical pulse width (VPW), vertical back porch (VBP) and vertical front porch (VFP).
The values for these blanking parameters are listed in display data sheets. The total blanking period varies from 3% to 39%. If your system uses reduced blanking, then you can estimate %Blanking at 10%. If you are not sure what blanking period your system uses, estimate around 20% and above to be conservative.
Frame rate (or refresh rate):the frequency at which consecutive images (frames) are displayed, and is measured in hertz or frames per second (fps). 60Hz is the most common frame rate, but this value can vary from 24Hz to 70Hz.
Throughput is another metric that you can use to determine whether or not a device will support your desired display resolution. The throughput is the effective payload of video data, and is derived from the required pixel clock frequency and color depth of your system, as shown in Equation 2:
Color depth: For a first-generation SerDes like the SN65LVDS93A, color depth is typically 24-bit red-green-blue (RGB) or 18-bit RGB for single pixel in, single pixel out (SISO) applications, and 48-bit RGB or 36-bit RGB for dual pixel in, dual pixel out (DIDO) applications.
The color depth will determine how many LVDS data lanes your display requires. SerDes serialize data at a rate of 7x the pixel clock frequency on each LVDS data lane. If the color depth is 24-bit RGB, then you will need four LVDS data lanes (there are an additional four bits used for control, which brings the total bit count to 28 bits) and can use a SerDes like the SN65LVDS93A. If the color depth is 18-bit RGB, then you will need three LVDS data lanes (there are an additional 3 bits used for control, which brings the total bit count to 21 bits) and can use a SerDes like the SN74LVDS84A or the SN65LVDS93A.
If the color depth is 48-bit RGB, then you will need eight LVDS data lanes (there are an additional 8 bits used for control, which brings the total bit count to 56 bits) and will need to use a device like the DS90C387 or DS90C189-Q1, which can output as many as eight LVDS data lanes.
When calculating the throughput for DIDO applications, you need to calculate the throughput for the odd pixels and even pixels separately and then add them together. For example, for a 48-bit DIDO application, the total required throughput would be 2 x Pixel Clock x 24.
Since the color depth is 24-bit RGB, you will need four LVDS data lanes. The SN65LVDS93A is a good fit for this application, since it has a pixel clock frequency range of 10MHz to 135MHz. Additionally, the maximum throughput for each LVDS data lane on this device is 135 x 7 = 945Mbps. Because this device has four LVDS data lanes, the total maximum throughput is 945 x 4 = 3780Mbps, which is higher than the minimum required throughput.
So the minimum pixel clock frequency to support a 2048 x 1536 resolution display is 208MHz. However, since this is a 48-bit DIDO application, there are actually two clocks: the frequency is split between them. Each clock must have a frequency of at least 104MHz.
Since the color depth is 48-bit RGB, you will need eight LVDS data lanes. The DS90C387 and DS90C187 are a good fit for this application, since they have a pixel clock frequency range of 32.5MHz to 112MHz (the DS90C387) and 25MHz to 105MHz (the DS90C187) for each channel in DIDO applications. Thus, if you don’t have access to the display data sheet yet, you can still estimate the required pixel clock frequency and throughput to support your desired resolution. If the SerDes does not meet these parameters, data on the display may display incorrectly, or not display at all.
Let us start with the basics first; refresh the knowledge about TN and LCD displays in general, later we will talk about TFTs (Thin Film Transistors), how they differ from regular monochrome LCD displays. Then we will go on to the ghosting effect, so we will not only discuss the technology behind the construction of the TFT, but also some phenomena, like the ghosting effect, or grayscale inversion, that are important to understand when using an LCD TFT display.
Next, we will look at different technologies of the TFT LCD displays like TN, IPS, VA, and of course about transmissive and transflective LCD displays, because TFT displays also can be transmissive and transflective. In the last part we will talk about backlight.
Let us start with a short review of the most basic liquid crystal cell, which is the TN (twisted nematic) display. On the picture above, we can see that the light can be transmit through the cell or blocked by the liquid crystal cell using voltage. If you want to learn more about monochrome LCD displays and the basics of LCD displays, follow this link.
What is a TFT LCD display and how it is different from a monochrome LCD display? TFT is called an active display. Active, means we have one or more transistors in every cell, in every pixel and in every subpixel. TFT stands for Thin Film Transistor, transistors that are very small and very thin and are built into the pixel, so they are not somewhere outside in a controller, but they are in the pixel itself. For example, in a 55-inch TV set, the TFT display contains millions of transistors in the pixels. We do not see them, because they are very small and hidden, if we zoom in, however, we can see them in every corner of each pixel, like on the picture below.
On the picture above we can see subpixels, that are basic RGB (Red, Green, Blue) colors and a black part, with the transistors and electronic circuits. We just need to know that we have pixels, and subpixels, and each subpixel has transistors. This makes the display active, and thus is called the TFT display. TFT displays are usually color displays, but there are also monochrome TFT displays, that are active, and have transistors, but have no colors. The colors in the TFT LCD display are typically added by color filters on each subpixel. Usually the filters are RGB, but we also have RGBW (Red, Green, Blue, White) LCD displays with added subpixels without the filter (White) to make the display brighter.
Going a little bit deeper, into the TFT cell, there is a part inside well known to us from the monochrome LCD display Riverdi University lecture. We have a cell, liquid crystal, polarizers, an ITO (Indium Tin Oxide) layer for the electrodes, and additionally an electronic circuit. Usually, the electronic circuit consists of one transistor and some capacitors to sustain the pixel state when we switch the pixel OFF and ON. In a TFT LCD display the pixels are much more complicated because apart from building the liquid crystal part, we also need to build an electronic part.
That is why TFT LCD display technologies are very expensive to manufacture. If you are familiar with electronics, you know that the transistor is a kind of switch, and it allows us to switch the pixel ON and OFF. Because it is built into the pixel itself, it can be done very quickly and be very well controlled. We can control the exact state of every pixel not only the ON and OFF states, but also all the states in between. We can switch the light of the cells ON and OFF in several steps. Usually for TFT LCD displays it will be 8-bit steps per color, so we have 256 steps of brightness for every color, and every subpixel. Because we have three subpixels, we have a 24-bit color range, that means over 16 million combinations, we can, at least theoretically, show on our TFT LCD display over 16 million distinct colors using RGB pixels.
Now that we know how the TFT LCD display works, we can now learn some practical things one of which is LCD TFT ghosting. We know how the image is created, but what happens when we have the image on the screen for a prolonged time, and how to prevent it. In LCD displays we have something called LCD ghosting. We do not see it very often, but in some displays this phenomenon still exists.
If some elements of the picture i.e., your company logo is in the same place of the screen for a long period of time, for couple of weeks, months or a year, the crystals will memorize the state and later, when we change the image, we may see some ghosting of those elements. It really depends on many conditions like temperature and even the screen image that we display on the screen for longer periods of time. When you build your application, you can use some techniques to avoid it, like very rapid contrast change and of course to avoid the positioning the same image in the same position for a longer time.
You may have seen this phenomenon already as it is common in every display technology, and even companies like Apple put information on their websites, that users may encounter this phenomenon and how to fix it. It is called image ghosting or image persistence, and even Retina displays are not free of it.
Another issue present in TFT displays, especially TN LCD displays, is grayscale inversion. This is a phenomenon that changes the colors of the screen according to the viewing angle, and it is only one-sided. When buying a TFT LCD display, first we need to check what kind of technology it is. If it is an IPS display, like the Riverdi IPS display line, then we do not need to worry about the grayscale inversion because all the viewing angles will be the same and all of them will be very high, like 80, 85, or 89 degrees. But if you buy a more common or older display technology type, like the TN (twisted nematic) display, you need to think where it will be used, because one viewing angle will be out. It may be sometimes confusing, and you need to be careful as most factories define viewing direction of the screen and mistake this with the greyscale inversion side.
On the picture above, you can see further explanation of the grayscale inversion from Wikipedia. It says that some early panels and also nowadays TN displays, have grayscale inversion not necessary up-down, but it can be any angle, you need to check in the datasheet. The reason technologies like IPS (In-Plane Switching), used in the latest Riverdi displays, or VA, were developed, was to avoid this phenomenon. Also, we do not want to brag, but the Wikipedia definition references our website.
We know already that TN (twisted nematic) displays, suffer from grayscale inversion, which means the display has one viewing side, where the image color suddenly changes. It is tricky, and you need to be careful. On the picture above there is a part of the LCD TFT specification of a TN (twisted nematic) display, that has grayscale inversion, and if we go to this table, we can see the viewing angles. They are defined at 70, 70, 60 and 70 degrees, that is the maximum viewing angle, at which the user can see the image. Normally we may think that 70 degrees is better, so we will choose left and right side to be 70 degrees, and then up and down, and if we do not know the grayscale inversion phenomena, we may put our user on the bottom side which is also 70 degrees. The viewing direction will be then like a 6 o’clock direction, so we call it a 6 o’clock display. But you need to be careful! Looking at the specification, we can see that this display was defined as a 12 o’clock display, so it is best for it to be seen from a 12 o’clock direction. But we can find that the 12 o’clock has a lower viewing angle – 60 degrees. What does it mean? It means that on this side there will be no grayscale inversion. If we go to 40, 50, 60 degrees and even a little bit more, probably we will still see the image properly. Maybe with lower contrast, but the colors will not change. If we go from the bottom, from a 6 o’clock direction where we have the grayscale inversion, after 70 degrees or lower we will see a sudden color change, and of course this is something we want to avoid.
To summarize, when you buy older technology like TN and displays, which are still very popular, and Riverdi is selling them as well, you need to be careful where you put your display. If it is a handheld device, you will see the display from the bottom, but if you put it on a wall, you will see the display from the top, so you need to define it during the design phase, because later it is usually impossible or expensive to change the direction.
We will talk now about the other TFT technologies, that allow us to have wider viewing angles and more vivid colors. The most basic technology for monochrome and TFT LCD displays is twisted nematic (TN). As we already know, this kind of displays have a problem with grayscale inversion. On one side we have a higher retardation and will not get a clear image. That is why we have other technologies like VA (Vertical Alignment), where the liquid crystal is differently organized, and another variation of the TFT technology – IPS which is In-Plane Switching. The VA and IPS LCD displays do not have a problem with the viewing angles, you can see a clear image from all sides.
Nowadays all TV sets, tablets and of course mobile phones are IPS or VA. You can turn them around and see the image clear from all sides. But, for monitor applications the TN technology is still widely used, because the monitor usually is in front of you and most of the time you look directly at it, from top, left or right side, but very rarely from the bottom, so the grayscale inversion viewing angle can be placed there. This technology still is very practical because it is affordable and has some advantages for gamers because it is very fast.
Apart from the different organization of the liquid crystals, we also organize subpixels a little bit differently in a VA and IPS LCD displays. When we look closer at the TN display, we will just see the subpixels with color filters. If we look at the VA or IPS display they will have subpixels of subpixels. The subpixels are divided into smaller parts. In this way we can achieve even wider viewing angles and better colors for the user, but of course, it is more complicated and more expensive to do.
The picture above presents the TN display and grayscale inversion. For IPS or VA technology there is no such effect. The picture will be the same from all the sides we look so these technologies are popular where we need wide viewing angles, and TN is popular where we don’t need that, like in monitors. Other advantages of IPS LCD displays are they give accurate colors, and wide viewing angles. What is also important in practice, in our projects, is that the IPS LCD displays are less susceptible to mechanical force. When we apply mechanical force to the screen, and have an optically bonded touch screen, we push the display as well as squeeze the cells. When we have a TN display, every push on the cell changes the image suddenly, with the IPS LCD displays with in-plane switching, different liquid crystals organization, this effect is lesser. It is not completely removed but it is much less distinct. That is another reason IPS displays are very popular for smartphones, tablets, when we have the touchscreens usually optically bonded.
If we wanted to talk about disadvantages, there is a question mark over it, as some of them may be true, some of them do not rely on real cases, what kind of display, what kind of technology is it. Sometimes the IPS displays can have higher power consumption than others, in many cases however, not. They can be more expensive, but not necessarily. The new IPS panels can cost like TN panels, but IPS panels definitely have a longer response time. Again, it is not a rule, you can make IPS panels that are very fast, faster than TN panels, but if you want the fastest possible display, probably the TN panel will be the fastest. That is why the TN technology is still popular on the gaming market. Of course, you can find a lot of discussions on the internet, which technology is better, but it really depends on what you want to achieve.
Now, let us look at the backlight types. As we see here, on the picture above, we have four distinct types of backlight possible. The most common, 95 or 99 per cent of the TFT LCD displays on the market are the transmissive LCD display type, where we need the backlight from the back. If you remember from our Monochrome LCD Displays lecture, for transmissive LCD displays you need the backlight to be always on. If you switch the backlight off, you will not see anything. The same as for monochrome LCD displays, but less popular for TFT displays, we have the transflective LCD display type. They are not popular because usually for transflective TFT displays, the colors lack in brightness, and the displays are not very practical to use. You can see the screen, but the application is limited. Some transflective LCD displays are used by military, in applications where power consumption is paramount; where you can switch the backlight off and you agree to have lower image quality but still see the image. Power consumption and saving energy is most important in some kind of applications and you can use transflective LCD displays there. The reflective type of LCD displays are almost never used in TFT. There is one technology called Low Power Reflective Displays (LPRD) that is used in TFT but it is not popular. Lastly, we have a variation of reflective displays with frontlight, where we add frontlight to the reflective display and have the image even without external light.
Just a few words about Low Power Reflective Displays (LPRD). This kind of display uses environmental light, ambient light to reflect, and produce some colors. The colors are not perfect, not perfectly clear, but this technology is becoming increasingly popular because it allows to have color displays in battery powered applications. For example, a smartwatch would be a case for that technology, or an electrical bike or scooter, where we can not only have a standard monochrome LCD display but also a TFT LCD color display without the backlight; we can see the image even in
You have app. 15% of the article left. That content is exclusive for our Riverdi University members only. Please fill out the Riverdi University Membership form below and join our community!
strong sunlight and not need backlight at all. So, this kind of TFL LCD display technology is getting more and more popular when we have outdoor LCD displays and need a low power consumption.
On the picture above, we have some examples of how transmissive and reflective LCD displays work in the sunlight. If we have a simple image, like a black and white pattern, then on a transmissive LCD display, even with 1000 candela brightness, the image probably will be lower quality than for a reflective LCD display; if we have sunlight, we have very strong light reflections on the surface of the screen. We have talked about contrast in more detail in the lecture Sunlight Readable Displays. So, reflective LCD displays are a better solution for outdoor applications than transmissive LCD displays, where you need a really strong backlight, 1000 candela or more, to be really seen outdoors.
To show you how the backlight of LCD displays is built, we took the picture above. You can see the edge backlight there, where we have LEDs here on the small PCB on the edge, and we have a diffuser that distributes the light to the whole surface of LCD screen.
In addition to the backlight, we have something that is called a frontlight. It is similar to backlight, it also uses the LEDs to put the light into it, but the frontlight needs to be transparent as we have the display behind. On the example on the picture above we can see an e-paper display. The e-paper display is also a TFT display variation, but it is not LCD (liquid crystal), it is a different technology, but the back of the display is the same and it is reflective. The example you see is the Kindle 4 eBook reader. It uses an e-paper display and a frontlight as well, so you can read eBooks even during the night.
Please remember to SUBSCRIBE to our YouTube channel and fill out the MEMBERSHIP FORM, to be informed about our Riverdi University materials and live events!
P10768MS150P_T01 is an industrial level Android LCM based on Rockchip RK3288 ARM. It is equipped with Quad-core Coretex-A17, supports most decoding solutions under 1080p@60fps, H.265/H.264/MVC/VP8 solutions under 1080p@60fps and many other great features of Rockchip RK3288. Meanwhile, with good jpeg picture processing performance and 3D GPU, it supports OpenGL ES2.0 and 1.1 OpenVG1.1.
RK3288 has high-performance external memory interface (DDR3/DDR3L/LPDDR2) capable of sustaining demanding memory bandwidths, also provides a complete set of peripheral interface to support very flexible applications.
P10768MS150P_T01 is an industrial level Android LCM based on Rockchip RK3288 ARM. It is equipped with Quad-core Coretex-A17, supports most decoding solutions under 1080p@60fps, H.265/H.264/MVC/VP8 solutions under 1080p@60fps and many other great features of Rockchip RK3288. Meanwhile, with good jpeg picture processing performance and 3D GPU, it supports OpenGL ES2.0 and 1.1 OpenVG1.1.
RK3288 has high-performance external memory interface (DDR3/DDR3L/LPDDR2) capable of sustaining demanding memory bandwidths, also provides a complete set of peripheral interface to support very flexible applications.
This is a small graphics library, specifically aimed at ATtiny microcontrollers, for the variety of small colour TFT displays available at low cost from suppliers like Adafruit, AliExpress, or Banggood:
It"s an updated version of my Tiny TFT Graphics Library. This latest version of the library supports both the classic ATtiny processors, such as the ATtiny85, and the new 0-series, 1-series, and 2-series ATtiny processors, such as the ATtiny402. Like the original library it allows you to plot points, draw lines, draw filled rectangles, and plot characters and text with an optional scale factor, in 16-bit colour.
This version adds the ability to plot outline rectanges, and outline and filled circles. I"ve included demo curve-plotting and histogram-plotting programs that adjust to fit any display.
This library supports TFT displays that use an SPI interface and require four pins to drive the display. This leaves one pin free on an 8-pin chip such as the ATtiny85 or ATtiny402. If you need more pins choose a larger chip, such as the ATtiny84 or ATtiny404.
Unlike my Compact TFT Graphics Library which uses standard Arduino SPI calls, this library uses direct I/O pin manipulations. This means that you can use any assignment of pins to the four I/O lines needed by the display, and makes it about twice as fast as one using SPI calls. I"ve also added support for some additional displays, so it now supports 16 different TFT displays.
On the classic ATtiny processors, such as the ATtiny85, the library uses the feature that you can toggle one or more bits in a port by writing to the PINB register; for example, to enable or disable the chip-select signal:
So provided you set all the pins to their disabled state at startup, the display routines can simply toggle the appropriate pins to enable or disable them.
The differences between each family of processors are handled by constants to define the pin assignments, and preprocessor macros to define the bit manipulations. If you use the circuits given below you won"t need to change anything, apart from specifying which display you"re using.
The ClearDisplay() routine has been optimised further by realising that we don"t need to keep setting the mosi bit, since to clear the display it is always zero, so the routine only needs to toggle the sck bit the appropriate number of times. I"m grateful to Thomas Scherer for suggesting this.
This library will work with displays based on the ST7735 which supports a maximum display size of 162x132, or the ST7789 and ILI9340/1 which support a maximum display size of 320x240. It includes parameters for the following colour TFT displays:
* These Adafruit displays conveniently all have the same edge-connector layout, so you can make a prototyping board or PCB that will take any of them, such as my Universal TFT Display Backpack.
Some of the AliExpress displays include a LDO 3.3V regulator, but not logic-level translation, so I recommend only interfacing them to a processor running from 3.3V.
The Adafruit displays all include an LDO 3.3V regulator and logic-level translation, so can be safely interfaced to processors powered from either 5V or 3.3V.
On the AliExpress red 160x128 display you need to connect the backlight pin to Vcc to turn it on. This doesn"t seem to be necessary with the other displays.
The library will probably support other TFT displays that use the same ST7735, ST7789, ILI9340/1 driver chips, but you may need to experiment with the parameters to get the image scaled and centered correctly.
The display needs to be connected to the microcontroller via four I/O lines: MOSI, SCK, CS, and DC. You can use any pins for these, but they should all be in the same port. You need to specify the port pin numbers of the pins you are using at the start of the Tiny TFT Graphics Library listing.
The 33kΩ pullup resistor from the display"s CS pin is optional; it is only needed on the AliExpress displays, and holds the chip select high to prevent the display from flickering while programming the ATtiny85.
The different displays are catered for by seven constants which specify the size of the display, the offsets relative to the area supported by the display driver, whether the display is inverted, the rotation value, and the order of the colours; for example:
By default the parameters give the correct orientation assuming you"re using the display with the header pins along the top, except in the case of the larger displays which have the header pins along the shorter edge, in which case the header pins are assumed to be on the left.
To check or adjust the values for each display you can run the TestChart() program, which draws a one-pixel border around the display area, and plots a red "F" to show the orientation:
The library will probably support other TFT displays that use the same driver chips, but you may need to experiment with the parameters to get the image scaled and centered correctly.
The foreground and background colours are defined by the two global variables fore and back. Initially these are set to White (0xFFFF) and Black (0) respectively:
The library includes basic graphics routines for plotting points and drawing lines. These work on a conventional coordinate system with the origin at lower left. For example, on the 80x160 display:
DrawRect() draws an outline rectangle andFillRect() draws a filled rectangle in the foreground colour with width w and height h, and the bottom left corner at the current drawing position:
DrawCircle() draws an outline circle andFillCircle() draws a filled circle in the foreground colour with radius radius, and the centre at the current drawing position:
By default the ATtiny85 runs at 1MHz. Choose Burn Bootloader to set the fuses for 8MHz operation, or your graphics will run rather slowly, then upload the program using an ISP (in-system programming) programmer such as Sparkfun"s Tiny AVR Programmer Board
It"s based on an RGB TFT display controlled by an ATtiny814. It uses a crystal-controlled oscillator to keep accurate time, and takes advantage of the routines for reading from a TFT display described in my earlier article Reading from a TFT Display.
This started as a demo program for my TFT Graphics Library with support for reading from the display, but it grew in complexity, so I decided to write it up as a stand-alone project.
Without the ability to read back from the display you would have to redraw the whole display every time the hands move, which will be once a second if the clock has a seconds hand. This would require a fast processor.
This clock avoids the need to do this by using the ability to read from the TFT display to exclusive-OR the colour of each hand onto the image of the clock face. When the hand moves, you can remove it from its last position by drawing it again, which will restore the background to its previous state. This ensures that features under the hands, such as the hour numbers, aren"t wiped out when the hands pass over them.
The clock is designed to work with a 240x240 or 320x240 RGB TFT display available from AliExpress. I"ve also made a lower-resolution version that will work on a 128x128 or 160x128 display; see Lower resolution version. The following displays are suitable:
Unfortunately Adafruit displays aren"t compatible with this application, because they don"t support reading from the display; there"s more information about this in my article Reading from a TFT Display.
The clock uses the ATtiny814 Real-Time Clock to generate an interrupt every second, with the timing controlled by a 32.768kHz crystal. For the crystal I used a low-cost cylindrical clock crystal L - CS), where CL is the load capacitance, and CS is the stray capacitance which is usually estimated to be 2.5pF on a PCB. This gives C=20pF.
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.
A hybrid of both Polled Mode SPI and DMA based transfers are utilized. Long sequential transfer bursts are performed using DMA, and when DMA would have too much latency, Polled Mode SPI is applied instead.
Undocumented BCM2835 features are used to squeeze out maximum bandwidth: SPI CDIV is driven at even numbers (and not just powers of two), and the SPI DLEN register is forced in non-DMA mode to avoid an idle 9th clock cycle for each transferred byte.
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)
A number of other micro-optimization techniques are used, such as batch updating rectangular spans of pixels, merging disjoint-but-close spans of pixels on the same scanline, and latching Column and Page End Addresses to bottom-right corner of the display to be able to cut CASET and PASET messages in mid-communication.
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.
If you have been running existing fbcp driver, make sure to remove that e.g. via a sudo pkill fbcp first (while running in SSH prompt or connected to a HDMI display), these two cannot run at the same time. If /etc/rc.local or /etc/init.d contains an entry to start up fbcp at boot, that directive should be deleted.
When using one of the displays that stack on top of the Pi that are already recognized by fbcp-ili9341, you don"t need to specify the GPIO pin assignments, but fbcp-ili9341 code already has those. Pass one of the following CMake directives for the hats:
-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:
-DILI9341=ON: If you are running on any other generic ILI9341 display, or on Waveshare32b display that is standalone and not on the FreeplayTech CM3/Zero device, pass this flag.
-DILI9340=ON: If you have a ILI9340 display, pass this directive. ILI9340 and ILI9341 chipsets are very similar, but ILI9340 doesn"t support all of the features on ILI9341 and they will be disabled or downgraded.
-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.
fbcp-ili9341 always uses the hardware SPI0 port, so the MISO, MOSI, CLK and CE0 pins are always the same and cannot be changed. The MISO pin is actually not used (at the moment at least), so you can just skip connecting that one. If your display is a rogue one that ignores the chip enable line, you can omit connecting that as well, or might also be able to get away by connecting that to ground if you are hard pressed to simplify wiring (depending on the display).
To get good performance out of the displays, you will drive the displays far out above the rated speed specs (the rated specs yield about ~10fps depending on display). Due to this, you will need to explicitly configure the target speed you want to drive the display at, because due to manufacturing variances each display copy reaches a different maximum speed. There is no "default speed" that fbcp-ili9341 would use. Setting the speed is done via the option
-DSPI_BUS_CLOCK_DIVISOR=even_number: Sets the clock divisor number which along with the Pi core_freq= option in /boot/config.txt specifies the overall speed that the display SPI communication bus is driven at. SPI_frequency = core_freq/divisor. SPI_BUS_CLOCK_DIVISOR must be an even number. Default Pi 3B and Zero W core_freq is 400MHz, and generally a value -DSPI_BUS_CLOCK_DIVISOR=6 seems to be the best that a ILI9341 display can do. Try a larger value if the display shows corrupt output, or a smaller value to get higher bandwidth. See ili9341.h and waveshare35b.h for data points on tuning the maximum SPI performance. Safe initial value could be something like -DSPI_BUS_CLOCK_DIVISOR=30.
There are a couple of options to explicitly say which Pi board you want to target. These should be autodetected for you and generally are not needed, but e.g. if you are cross compiling for another Pi board from another system, or want to be explicit, you can try:
-DARMV8A=ON: Pass this option to specifically optimize for ARMv8-A instruction set (Pi 2B >= rev. 1.2, 3B, 3B+, CM3, CM3 lite, 4B, CM4, Pi400). If not present, autodetected.
-DBACKLIGHT_CONTROL=ON: If set, enables fbcp-ili9341 to control the display backlight in the given backlight pin. The display will go to sleep after a period of inactivity on the screen. If not, backlight is not touched.
-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.
-DDISPLAY_BREAK_ASPECT_RATIO_WHEN_SCALING=ON: When scaling source video to SPI display, scaling is performed by default following aspect ratio, adding letterboxes/pillarboxes as needed. If this is set, the stretching is performed breaking aspect ratio.
-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.
-DDISPLAY_INVERT_COLORS=ON: If this option is passed, pixel color value interpretation is reversed (white=0, black=31/63). Default: black=0, white=31/63. Pass this option if the display image looks like a color negative of the actual colors.
-DLOW_BATTERY_PIN=
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.
If you want to do a full rebuild from scratch, you can rm -rf build to delete the build directory and recreate it for a clean rebuild from scratch. There is nothing special about the name or location of this directory, it is just my usual convention. You can also do the build in some other directory relative to the fbcp-ili9341 directory if you please.
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.
The refresh speed of the display is dictated by the clock speed of the SPI bus that the display is connected to. Due to the way the BCM2835 chip on Raspberry Pi works, there does not exist a simple speed=xxx Mhz option that could be set to define the bus speed. Instead, the SPI bus speed is derived from two separate parameters: the core frequency of the BCM2835 SoC in general (core_freq in /boot/config.txt), and the SPI peripheral CDIV (Clock DIVider) setting. Together, the resulting SPI bus speed is then calculated with the formula SPI_speed=core_freq/CDIV.
Adjust the CDIV value by passing the directive -DSPI_BUS_CLOCK_DIVISOR=number in CMake command line. Possible values are even numbers 2, 4, 6, 8, .... Note that since CDIV appears in the denominator in the formula for SPI_speed, smaller values result in higher bus speeds, whereas higher values make the display go slower. Initially when you don"t know how fast your display can run, try starting with a safe high setting, such as -DSPI_BUS_CLOCK_DIVISOR=30, and work your way to smaller numbers to find the maximum speed the display can cope with. See the table at the end of the README for specific observed maximum bus speeds for different displays.
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.
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.
On the other hand, it is desirable to control how much CPU time fbcp-ili9341 is allowed to use. The default build settings are tuned to maximize the display refresh rate at the expense of power consumption on Pi 3B. On Pi Zero, the opposite is done, i.e. by default the driver optimizes for battery saving instead of maximal display update speed. The following options can be controlled to balance between these two:
The main option to control CPU usage vs performance aspect is the option #define ALL_TASKS_SHOULD_DMA in config.h. Enabling this option will greatly reduce CPU usage. If this option is disabled, SPI bus utilization is maximized but CPU usage can be up to 80%-120%. When this option is enabled, CPU usage is generally up to around 15%-30%. Maximal CPU usage occurs when watching a video, or playing a fast moving game. If nothing is changing on the screen, CPU consumption of the driver should go down very close to 0-5%. By default #define ALL_TASKS_SHOULD_DMA is enabled for Pi Zero, but disabled for Pi 3B.
The CMake option -DUSE_DMA_TRANSFERS=ON should always be enabled for good low CPU usage. If DMA transfers are disabled, the driver will run in Polled SPI mode, which generally utilizes a full dedicated single core of CPU time. If DMA transfers are causing issues, try adjusting the DMA send and receive channels to use for SPI communication with -DDMA_TX_CHANNEL=
The statistics overlay prints out quite detailed information about execution state. Disabling the overlay with -DSTATISTICS=0 option to CMake improves performance and reduces CPU usage. If you want to keep printing statistics, you can try increasing the interval with the #define STATISTICS_REFRESH_INTERVAL
There are a number of #define SAVE_BATTERY_BY_x options in config.h, which all default to being enabled. These should be safe to use always without tradeoffs. If you are experiencing latency or performance related issues, you can try to toggle these to troubleshoot.
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.
The option #define RUN_WITH_REALTIME_THREAD_PRIORITY can be enabled to make the driver run at realtime process priority. This can lock up the system however, but still made available for advanced experimentation.
In display.h there is an option #define TARGET_FRAME_RATE
A pleasing aspect of fbcp-ili9341 is that it introduces very little latency overhead: on a 119Hz refreshing ILI9341 display, fbcp-ili9341 gets pixels as response from GPIO input to screen in well less than 16.66 msecs time. I only have a 120fps recording camera, so can"t easily measure delays shorter than that, but rough statistical estimate of slow motion video footage suggests this delay could be as low as 2-3 msecs, dominated by the ~8.4msecs panel refresh rate of the ILI9341.
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)
Interestingly, fbcp-ili9341 is about ~33msecs faster than a cheap 3.5" KeDei HDMI display. I do not know if this is a result of the KeDei HDMI display specifically introducing extra latency, or if all HDMI displays connected to the Pi would have similar latency overhead. An interesting question is also how SPI would compare with DPI connected displays on the Pi.
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)
You can however choose between two distinct types of tearing artifacts: straight line tearing and diagonal tearing. Whichever looks better is a bit subjective, which is why both options exist. I prefer t
Ms.Josey 
Ms.Josey