tft display interface microcontroller quotation

The display is a critical component in every project, impacting the case, firmware, electrical design, user interface, and even battery life. For these reasons, and because it is the most visible component of your product, it must be approved by the mechanical design team, management and marketing.Before these teams can approve, they need to see it in action. But it can take days or weeks to connect a display to your platform, initialize it and build a code library able to create believable demonstrations. Meanwhile, the whole project is on hold.Our 8051 development kit / demonstration board can solve this problem. Use it to get the display seen, demonstrated and approved for your project.

ER-DBT032-3 is a microcontroller 8051(80C51) demonstration and development kit for ER-TFT032-3.1 product that is 3.2 inch tft lcd display with ILI9341 controller.The kit includes MCU board controlled by STC12LE5A60S2,ISP(In System Programming) with USB port and cable to customize the demonstration that includes your own bitmap images,personalized fonts,symbols,icons and burn sketches,microSD card that is written graphic and text into it,the power adaptor,the adaptor board with various pitch dimension used to connect MCU board and display.Optional for 8080 8-bit,8080 16-bit parallel interface and 3-wire,4-wire serial interface.

For a digital picture frame i would like to use the MSP430 to connect a 20" TFT LCD display (Resolution 1600 X 1200) via SPI. Do you think this is doable? Is there a LCD controller that can support such a high resolution with SPI? In my research so far i have found some projects for small displays such as this:

This graphic display module is a 2.4" diagonal, full color TFT. Suitable for embedded applications, it is low-power, uses a white LED backlight, and has an integrated touch panel which has its connection brought out to the main TAB connector for the display.

It has an on-board controller and 3v single voltage for supply and logic (backlight not included), so you can easily use any modern microcontroller to interface with this display. It uses an 8 or 16 bit parallel interface, specified via connections to the display.

The connector on the CFAF240320K-024T-TS is a flex tail mated with a "COG" (chip on glass) display construction. This style of connector is designed to be soldered directly to corresponding pads on your PCB by using a hot-bar soldering machine. High volume contract manufacturers will be familiar with this type of construction and its assembly methods. There are hot-bar soldering machines made that are designed for prototype, rework or repair work of TAB connections.

We are changing our TFT part numbers to have them better describe the parts being ordered. The change should be complete for all TFT modules shipping within the next six months.

Displays have over time, emerged as one of the best ways to drive user interactions on any device. They make it easy to collect inputs and present information (outputs) to users in a graphical, easy to understand format. This usefulness has led to improvements in their quality, with improved resolution and low power features, but almost little has changed when it comes to the complexity of creating beautiful user interfaces for them. This is why the team at STONE Tech created the STVC035WT-01 intelligent Smart display which we will explore for today’s tutorial.

The STONE STVC035WT-01 display is a 16-bit, 3.5″ display with a 320×480 (RGB) resolution, has a 49.0 x 73.4mm viewing area, and pixel spacing of 0.1905mm×0.0635mm (H×V). The display is a Class A industry Panel with an Industry level 4 wire resistance based touch screen, all layered on an integrated CPU, driver, and flash memory with several communication interfaces to enable it to connect to data sources like microcontrollers. For communication with a microcontroller, the display supports serial communication protocols likeUART/TTL, RS232, and RS485, ensuring it can communicate with any kind of microcontroller or industrial computers. The UART/TTL pin on the Display supports both 3.3v/5v logic level which adds another layer of ease to the use of the display as users need not worry about the need for logic level shifters when building using a microcontroller that operates on either of the voltage level mentioned.

One of the major benefits of using this display is its compatibility with the STONE TOOL GUI Designer which allows the development of User Interfaces in a fast and easy manner.

To demonstrate the capabilities of the display, we will build a heart rate monitor using an Arduino Uno with the MAX30100 pulse oximetry and heart rate sensor. The Arduino will serve as the brain of the project and perform the simple task of obtaining the heart rate and blood oxygen data from the MAX30100, displaying it on the screen.

At the end of this tutorial, you would know how to interface Arduino boards with the STONETech displays, and also how to interface sensors like the MAX30100 with the Arduino.

Our development process for today’s project will follow this outline. We will first create the GUI for the project after which we will proceed to write the firmware to interface the microcontroller with the display.

As mentioned during the introduction, today’s tutorial will focus on creating a heart rate and Oxygen-level monitoring system using the display and to get things started, we create the GUI image (shown below) using Photoshop.

The design is quite simple, we illustrate label elements to hold the date, the project title, and the values from the microcontroller. The values from the microcontroller include; the status of the connection between the microcontroller and the display, the heart rate, and the oxygen levels.

1. With the software downloaded on your computer, launch it and go to File>New Project. This will launch the “New Project dialog box ” where you will be expected to fill in the details of your display, set the storage path, and the name of your project. Since we will use the STVC035WT-01 display which has a  resolution of 320*480 and a default flash space size of 128Mbyte (expandable to 1024MByte), I have entered its details as shown in the image below. If you are using any of the other StoneTech displays, you will need to enter the details of that display instead.

4. Next, we add fonts to the project’s assets to determine how texts appear on the display. Right-click the “Font” file, and select the appropriate font to add to the project. For this tutorial, we will use the ASCII 24 by 48 font. With that done we are now ready to begin adding the GUI elements.

5. We will only use the “Text Display” GUI element since the display is only meant to display data from the MAX30100. The text display elements are capable of holding texts that can be changed programmatically by updating the data stored in their memory addresses. Add text displays on the lines as highlighted in the image below. Also, create a text display for the day-time section at the top of the display image to help users note the date/time each reading was observed.

6. Next, we set the properties of the text displays especially their memory addresses. The properties of each GUI element will be available on the right-hand side of your PC screen after clicking on the element. Note the memory address down as it will play an important role later.

7. With all of these done, we compile the GUI and upload it to the screen. To do this, click on button 1 in the image below to Compile the GUI design and click on button 2 to upload the GUI to your display.

Uploading the GUI display requires you either connect the display directly to your computer or you put the GUI on a flash drive and plug the flash drive into the USB port of the display. Because of the little complexity associated with the second option, we will be going with it.

Plug the USB flash drive into the computer then click the “Download to u-disk” button on the STONE GUI TOOL.With the “download to u-disk” process complete, pull out the USB flash disk, insert it into the USB interface of the display module and wait for the completion of the upgrade. When the upgrade is completed, there will be a prompt sound.

The model of the STONE display being used for this tutorial communicates via RS232, as such, to be able to interface the display with the Arduino, we have to connect it through a MAX3232 chip. This extra requirement can be avoided by using one of the STONE displays with a TTL interface.

Due to the simplicity embedded in the design of STONETECH displays, the microcontroller’s interaction with any of the GUI components is usually via the “memory address” of each component. for instance, to send a message to the display from the microcontroller (the Arduino in this case), the message has to be published to the memory address of the GUI Component (in this case, the text-display component). The same holds for GUI Components that are meant to send data to the microcontroller, as the microcontroller has to poll their memory address to obtain information from them. As a result of these, we need to obtain the memory address of all the GUI components before proceeding. For each GUI component, the memory address is usually listed among the properties of the component, under the property toolbar, at the right-hand side of the STONE TOOL interface.

With this obtained, we can now proceed to write the code for the project. One of the good things about using the STONETech displays is the fact that you don’t need a library to write code for them because of their simplicity, but since we will use serial communication, we will use the software serial library to avoid having to use the hardware serial port on the Arduino Uno. To interface with the MAX30100, we will also need to install the MAX30100 library. The Max30100 library can be installed using the Arduino Library Manager or by downloading it from the attached link and installing manually by extracting the file, copying its content and pasting it in the Arduino libraries folder. The software serial library comes pre-installed with the Arduino IDE.

We start the function by initializing serial communications between the screen and the microcontroller setting the baud rate to 115200. We also initialize hardware serial communication so we can use the serial monitor on the Arduino IDE for debugging purposes.

Next, we initialize the MAX30100 and send the status of the initialization to the display. If the initialization fails, 0x00 meaning 0 is sent to the display, but if successful, 0x01 meaning 1 is sent to it.

We start the void loop() function by calling for updated readings, after which we check if the reporting period has elapsed. If the reporting period has elapsed, it means we need to take new measurements, so we call the pox.getHeartRate and pox.getSp02 commands to get new heart rate and oxygen levels. These new readings are displayed on the serial monitor and also sent to the display.

With the code complete, connect your Arduino board to your computer and upload the code to your setup. Place a finger on the Max30100 and after a while, you should see the live pulse rate and oxygen levels appear on the display as shown in the image below.

While this project only demonstrates less than 35% of the capabilities of the STONE TECH display, it provides a good foundation for you to build amazing projects. As an engineer, the key benefit of the display to me is the ease of use both in the creation of the GUI and also the development of the code to tie it together with a microcontroller. The fact that the display doesn’t require any library makes it perfect for use with any language and any microcontroller with serial port access.

The quality, size ανδ variety of the STONE TECH displays makes them perfect for HMI Applications and one of my next projects will be a Home Automation Panel using one of the STONETECH displays.

first thanks for your response..i am new for TFT lcd.I attached my details.If u got any idea tell me.i am facing problem in 10" TFT lcd interfacing.problem is lcd back light is flikering.i attached a file see that.

1)my TFT pannel WY101ML308HS18A is a Active matrix TFT panels and it can support up to 24-bit bus.my controller is lpc1788 so it has inbuild lcd controller and it can support .

2)the controller has a parallel bit interface, the panel has a LVDS interface.But here i am using a SN75LVDS83B to convert the 24 bit parallel data into LVDS format..and sending to TFT lcd pannel via 4 bus.

lcd_14arial_writestr(a,b,"WELCOME","B",RED,WHITE);// Its a function for displaying 14 Arial font character. a=horizontal location,b=vertical location,welcome =character should display in TFT lcd(accessing from ASCII Library), red=character color,white=screen border color.

For the last 4 days been hunkering down to understand the world of TFT and IC drivers, trying to make sense in all the beautiful wonder of screens. Following are some of my findings that want to share and hope this can help others too.

TFT screens that are sold as is mostly does not have a driver that can drive the TFT. The driver is IC that will communicate with the MCU to drive the TFT, doing things such as drawing a pixel, setting columns and widths, refresh rate, PLL, etc. The IC driver is a full graphics processor that you can send command in to do all these activities.

8 and 16bits processors such as Arduino does not have graphics processors so they rely on these IC to drive TFTs, however, 32bits MCUs normally have a built-in TFT driver that can be used to drive the TFT such as the ARM Cortex family. There are a number of TFT screens that comes equipped with graphics processor that can be bought from eBay, Taobao, etc, most of these screens are 1.8”, 2.8”, 3.2”, 3.5”, 4.3” and 7”. Most of them come with a IC processor from Salomon (SSD families) or ILITEK and there are *LOTS* of open source schematics and code that can be downloaded.

There are lots of TFT that you can buy off the shelf and most of the TFTs are sold having few things in commons such as PINs configuration, refresh rate, screen size, etc, which is a good thing also. One thing to remember though there are no screens that are the same, each screen are different than the the next. Buying a screen off-the-shelf means that you probably don’t have a graphics processor that can drive it, or if you are lucky by searching Google you would see some blog or forum post of someone that have managed to build the driver. A lot of times I found posts that talk about driving a graphics processor using Cortex-M3 or FPGA but that mostly for big screens of 3” and above as normally these kind of screen need faster processor, more faster than current 16bit processors available.

Buying off-the-shelf screen also means that you need to get a hold of the datasheet, as the datasheet contains important electrical (and mechanical) information that you will need to drive it. Power supply information is of the paramount information that you will be focusing on as you need to know how much power each part of the TFT will need such as – backlights, etc. The next step after buying off-the-shelf TFT is to build a PCB board to drive it, and this is where choosing the proper graphics processor is important.

Finding graphics processor are not as daunting as TFT as there are few companies that supply this kind of processor (you can count by fingers kind of few companies). One of thing that I was stunned during my finding to know that even Epson produced their own driver. The most developer friendly driver that I found so far is Salomon, their documentation and application notes really help a lot if you are building your own PCB driver, it contains quite a comprehensive explanation about the different things that you have to take into consideration on building your own PCB. There are also lots of open source schematics that you can leverage on for Salomon based drivers and one of the drivers that I’m looking keenly at is the SSD1963, which to my surprise has *LOTS* of sample schematics (Chinese or non-chinese based) that you can use.

During my time researching this what I find frustrating sometimes it understanding the TFT datasheets, but thanks to the help of the open source communities I was able to mapped out what the different value means back to the code that was written to it. This takes a bit of practice as you need to map out between the code, pin connection to the graphics driver and then to the TFT, but once you figure it out it is not that hard.

5-18-17: TODO: a very thoughtful email came informing me of a very interesting discovery. Apparently, a particular display uses500KHzpixel-clock during standby-mode, (as opposed to 54MHz during normal mode), to display a small "standby" box. Many thoughts on the matter to be added here!

NOTE: This This is mostly just a brain-dump of LCD concepts and vague ideas as to how to make use of them with a cheap 8-bit microcontroller. It"s probably not well organized, nor complete. Much of the useful implementation-information (schematics, timing diagrams) is well-documented in my code. See

The main point of this particular document is this: You (generally) don"t have to match, or even come close to, the documented timing specifications for a particular TFT... From experience, it"s definitely possible to put an image on a 1024x768 laptop display directly from an 8-bit microcontroller running at 16MHz (though maybe not *every* display matching these specs, best to have a couple to experiment with). Experiment!

Who"s my intended audience? I don"t really know... I hope someone can make use of it. I"m hoping my work won"t be stolen verbatim for a school project, but we all understand that there"s no such thing as any project that isn"t based on others" work, and, in this era, everyone"s work can be made available to everyone... I hope this doesn"t contain too much jargon to make it difficult for anyone with a basic understanding of digital electronics and microcontrollers (e.g. Arduino).

Was a time replacing that display would cost upwards of $200, even for a used one, but these days, I guess, there"re a lot of pho"d laptops. Also, we have the benefit that they"ve standardized things, and improved the technology, quite a bit since the last time I tried to use an old (386) laptop display in a project.

I won"t go into too much history here, except to say that life is significantly easier now that TFT"s are on the junk pile. Or at least, it"s significantly easier to give new life to that old TFT than it would be for a 486-era display.

A few things, before I begin with the technicalities: I have experimented with exactly *3* old TFT displays. Two worked with my methods described here, one didn"t. I still have some hope for that display, but not as much drive. (Maybe someone here can figure it out?). I"ve pieced together this "document" from experimentation, lots of experimentation, as well as piecing together quite a bit from data-sheets and other specifications as a starting-point. I have no training, nor professional experience, with LCDs, so take *everything* said here with that in mind. I will also throw in this IMPORTANT BIT: Apparently most of these displays are SIGNIFICANTLY more flexible than their documentation claims. One additional thing: If you just want to use your old laptop display as an additional DVI or VGA display for your desktop computer, then you"re in a tremendous amount of luck... these days that conversion circuitry can be purchased off ebay for less than $50 (and you needn"t read on).

TFT displays are pretty much the only ones discussed here, they are pretty much the standard for many years now. Each pixel is backed by a transistor (and capacitor?) that holds its value until the next refresh. Most of these displays have very similar timing requirements, signal inputs, and by now even similar pinouts.

STN displays are the old style (grayscale and color displays from before and during the 486 era). They couldn"t hold an image for long. So, to prevent noticeable flicker as best they could by increasing refresh-rate, they often split the screen in half and wrote to the top half and the bottom half at the same time. (Thus the "D" in DSTN). Realistically, I think they use roughly the same signals as TFT, and very similar timing (besides the split-screen thing), but they"re not particularly easy to interface in any standard way. Pinouts were as varying as the devices themselves. Compatibility between laptops of different models was almost ziltch.

Hsync - "Horizontal Sync" Tells the display it"s time to start a new row. Usually a very brief pulse (on the order of 20 pixel clocks) immediately before pixel data is drawn

DE - "Data Enable" When this is active, pixel data is drawn to the display one (or two) pixels per pixel clock. Thus, if the screen is 1024x768, this will be active for *exactly* 1024 pixel clocks. (See notes re DE below)

Color data - usually 6bits per color (Red, Green, and Blue). This data is completely neglected if DE is inactive (and the display is otherwise properly-synced). If all those wires are too daunting just tie them all together on a single uC pin! You"ll get black-and-white. Or break them apart by color and tie all of the same color bits together and you"ll only need three pins and get 8 colors.

Some displays may actually require this to be constantly-running as long as the display is powered-up. Some displays (especially LVDS) may not actually look at the pixel clock itself for drawing pixels... This should be a different note.

e.g. sometimes DEs that are active longer than the number of horizontal pixels appear to start a new row. Sometimes they seem to be gobbled up by the nonexistant pixels on the right side of the display (which is certainly easier to work with, since *exact* timing when dealing with CPU cycles is difficult).

LVDS - each pair of wires transmits 7 bits of data per pixel clock, pretty much the standard for laptop displays (in fact it"s more appropriately called FPD-Link). This data is usually transmitted at speeds nowhere near a microcontroller"s reach, but it can be fudged, and most of my experiments have been with an LVDS display.

Some displays seem to stretch their pixel data horizontally over multiple pixels if driven with a slow pixel-clock. They may be *really smart* and implement scaling for lower resolutions internally, but I"m not convinced. Especially since the cases where I"ve seen this still have the same vertical resolution.

Dual-Pixel displays use one pixel-clock to display two horizontally-adjacent pixels at a time. Why? Because it"s fun to make things complicated, of course! No, it increases frame-rate, makes it possible to send twice as much data at the same bit-frequency, at the cost of twice as many wires. It"s becoming increasingly common as display resolutions increase. Generally, if you have a laptop display larger than 1024x768 it"s most likely Dual-Pixel (this is a rough estimate). DVI also has a dual-pixel mode, but that doesn"t necessarily mean the display itself is as well, and vice-versa. For instance, I was surprised to discover that an old 1024x768 VGA screen had a dual-pixel interface at the LCD. That must have been fun for the VGA-to-TFT circuit designers.

What"s it mean for hackers? Well, actually, it"s kind of nice. With a microcontroller it"s darn-near impossible to use the full resolution. My latest is roughly 300 drawable pixels scaled across to 1024 physical. If this display was dual-pixel, it would equate to 300 drawable pixels scaled across 512, which would double the frame-rate... err... that"s not right, because the row-rate is determined by the processing time devoted to the number of pixels... Anyways, the only additional work it would require is a little soldering, and could in fact make your project easier.

Yeah, it"s a LOT of wires, and looks very daunting, but those "odd" pixels and "even" pixels could easily be wired directly together, in which case it"s literally no different to physically interface than a single-pixel display.

DE-Only displays don"t pay attention to Hsync or Vsync signals. They determine that information by the amount of time between active DE signals. I"m not certain, but they seem to be easier to work with. Though that seems backwards considering they"d have to do a lot more computation on the display itself... So it would seem their timing requirements would be a lot more sensitive to whatever computation methods they use (and don"t exactly document). All of my functional experiments with an LVDS display are with a DE-ONLY LVDS display, and it seems astoundingly tolerant. However, I don"t know that this has anything to do with its being DE-Only.

The main thing is this, TFT displays, inherently, have built-in memory. It"s the whole point of the "Thin-film transistors" to be able to store each pixel"s state until the next refresh. There"s a transistor at every pixel, used to hold its state. Thus, why TFT displays look so much better than the older non-TFT displays (which many of you may have never encountered), which literally flicker on when written and fade to off until they"re written again. For the most part, those non-TFT flickery-days are long-past. (Though, you"ll find out here that flickering TFT"s can be used to our advantage).

Take that main-point just a little further: LCDs of all sorts have this inherent issue... When the liquid crystals (pixels) are driven with a constant (DC) voltage they cannot retain their visible state forever. Gradually, they will revert to their original state (either black or clear, depending on the technology used in the particular display). At one time it was made very clear that driving a liquid crystal (segment, or pixel) with DC will eventually "ruin" that pixel. I have yet to encounter this effect, but it"s been made very clear in numerous places over the years. I don"t know what method they use for driving pixels at fractional-intensities (gray) without using DC. Maybe they read the pixel"s TFT during each refresh and write a new temporary DC value based on that...? I *highly* doubt they have an *additional* frame-buffer for the sake of remembering the previous DC value of each pixel and calculating a new one. I also *highly* doubt they refresh all the pixels *separately* from (and faster than) the regular refresh rate driven by a video-card, (otherwise there wouldn"t be the effect described below?). It could well be that I completely misunderstood those warnings I read over and over again all those years ago. It could also be that nowadays DC *won"t* damage the crystal, and it could be that they"re actually using DC values to drive these pixels to fractional-values. IF that"s the case, it"s likely those DC values are stored in a (leaky) capacitor which drives the TFT which holds the pixel state. Whatever the case, we have another issue causing the main point of this paragraph...

The point of the above diatribe is that, whatever the cause, the displays I"ve worked with *do* eventually fade if not refreshed regularly. However, nowhere near as regularly as stated in the documentation for these displays. An example: The LTN121X1 display I acquired from an old iBook specs the minimum refresh rate at ~50Hz. My current code refreshes at ~1/5Hz. There is visible fade between each refresh, and you also have the joy of *watching* as each pixel is redrawn (a horizontal black bar scrolls down the screen for about 5 seconds), BUT, this means that we can stretch our refresh rate down to *once per five seconds,* well within the abilities of a lowly 8-bit microcontroller.

So, if you have a relatively stationary image you wish to display, and don"t mind a visible update on the screen, we can stretch the screen"s capabilities quite a bit, and even drive it from an arduino-like device with only a couple TTL chips.

On to the capabilities (not all-inclusive, and likely mutually-exlusive). These are my accomplishments so far on two different 1024x768 TFT displays, using an Atmel AVR microcontroller (like those used in Arduinos) running at ~16MHz:

Using these specification-stretching techniques we can do quite a bit. With a higher-power 8-bit microcontroller (high-end arduino), low expectations for number of displayed colors, low pixel-count, etc. We can get 30Hz refresh, no problem. For most, the flicker at 30Hz isn"t even visible (old tube TV"s run at 30Hz, or 33?). And, with some clever coding, this could quite probably be an image that changes slightly in *every* frame, just like a low-resolution movie. The particular display I implemented this on was not an old laptop display, but an old desktop display with its innards removed, an ATmega644 connected directly to its Pixel-clock, Hsync, Vsync, Data-Enable inputs. The display itself was a "dual-pixel" display, which means for 1024x768 it required 512 pixel clocks per row, and had two sets of color inputs, one for each of the two pixels that were displayed. It"s quite daunting to look at 40+ wires, at first, but when realizing only four of them are necessary for timing, (the same four signals used by most displays), the rest can all be tied together to a few outputs to create an image. I initially chose to tie all the blues together, all the reds, and all the greens, then using a single output port I could write each "pixel" in a single "out" instruction (e.g. PORTA = 0x07; // Display white, PORTA=0x01; //Red)

I chose to implement this using an ATmega644 running at 15MHz with a clock-prescaler of 2 from an external crystal running at 30MHz (also used to directly drive the pixel-clock). Thus, each processor instruction was running 2 pixels wide, but each pixel-clock was displaying two pixels (dual-pixel display). Between loading from the frame-buffer and writing that value to the output port, I had control over 21 (stretched) pixels in each horizontal scan. Since I was working with a frame-buffer, this equated to each row being repeated numerous times. Though, later, I was able to improve this significantly. Also, repeating of rows isn"t necessary, so 21 (really wide) pixels by 768 pixels was entirely possible.

There is *plenty* of room for improvement on this design, as it was my first TFT experiment... Other considerations: Don"t use a prescaler for the ATmega"s clock... 30MHz is way out of specs, but maybe it"d work? Use assembly instead of C for the pixel-loading routines, those are just a few, and not even considering Other Effects...

And, since I"ve mentioned "Other effects" let"s talk about them... For one thing, though it seemed like a hassle while coding what I was intending, if timing is not quite right, there are some interesting effects. For instance, sometimes Hsync timing issues would cause *rows* to be repeated. No joke. I have no idea how it works on a fundamental level, but it did. That likely could be taken advantage of if explored. (e.g. If it could be determined how to intentionally cause it to repeat rows numerous times, then the frame-rate could be increased that much more, assuming those rows would have been duplicated anyhow via software... i.e. to create square pixels). Another timing effect that I haven"t yet discovered how to harness: somehow it"s possible to cause only partial refreshes... e.g. a partial refresh starts from the top and only refreshes the top portion of the screen, it could then be followed by a full refresh, to effectively double the refresh-rate in the top portion of the screen. (Things which change seldomly would be at the bottom portion). Another timing-related oddity is that some displays appear to do horizontal stretching on their own...

For instance, I did some heavy-testing of a display connected to my laptop, using "SwitchResX." I was bumping down its pixel clock as low as I possibly could, just to see if it was even plausible to run it off my AVR. What I found boggled my mind, as I bumped down its pixel clock, the image started to stretch horizontally... When I finally found a rate that *should* work with my AVR setup, my 1024x768 display was down to 680 (stretched) by 768. The lower horizontal resolution meant I could bump the frame-rate up with lower pixel-clocks, which was a blessing I looked forward to taking advantage of. But, ultimately, this was the display I haven"t yet been able to drive via the AVR... This particular display had a bold note stating that it would display black if an input signal did not match the timing specifications required. While the timing I"d gotten to work via SwitchResX was *way* outside the specified range, it never displayed anything but black when connected to my circuit. Ponderings as to why the image was stretched...? Maybe the pixel clock isn"t used directly... maybe the PLL that extracts the pixel clock saturates at a lower limit which is higher than the pixel clock I was supplying... Regardless, the settings which I was able to mimick with the AVR were *not* capapble of driving this display. I"m guessing it"s due to a poor LVDS implementation.

There are two common interfaces, that I"ve run into, at the LCD panel"s connector, LVDS or (low-voltage) TTL. If you"ve got a desktop LCD display or LCD TV, there"s most likely a circuit which converts from VGA, HDMI, or DVI, or any number of other input signals to either LVDS or TTL which connects to the panel itself. (Interestingly, I"ve worked on a Plasma TV, which uses LVDS... the plasma display itself was busted, but I was lucky enough to be able to rewire it to connect *directly* to an LCD panel, it was even the right resolution, though I believe some of the bits were reversed, as high-brightness colors showed up as different colors... e.g. bright red appearing as bright blue).

So, at the connector of your LCD panel, you most likely have either TTL or LVDS. I"ll start with TTL, it"s simpler to understand. The terms TTL and LVDS have nothing to do with LCDs, specifically, and mostly just define the hardware-level interface.

e.g. a simple 640x480 TFT display running at 18bits-per-pixel will have 4 timing wires, and 6 wires for each color (red, green, blue), or 22 wires. It will also have a few wires for the power supply (+3.3V and GND). If you"re lucky, the wires will be colored based on their purpose. In most cases, those signals will be at or close to 3.3V = High (a "1" bit) and 0V = Low (a "0" bit). Each wire is "sampled" at either the falling (high-to-low) or rising (low-to-high) edge of the pixel-clock. (The pixel-clock is running constantly, regardless of whether actual pixels are being transmitted, for instance an H-Sync may be indicated by the H-Sync pin being held low for 20 pixel-clocks).

The simplest way to connect this to a microcontroller (AVR, Arduino, PIC, whatever) is to just wire each of the LCD"s timing pins to a microcontroller output, tie the color pins together on another pin, and run that microcontroller at 3.3V... from there it"s all software.

There"s a lot of detailed information out there as to how that data is formatted (and a lot in my code). For now I"ll say it"s as simple as this: during one pixel-clock on one wire, each other wire sends seven bits of color (or timing) data. Thus, the bit-transmission-rate of a single wire is seven times faster than the pixel-clock. We"re talking some fast data-rates here, especially for a lowly 8-bit microcontroller running at, say, 16MHz.

Well, if your microcontroller (rare) has four differential serial ports that can run at full speed and in 7-bit mode, then it"s just a matter of a few resistors (and those might not actually be necessary, more on that later). If you have four serial ports that *aren"t* differential, we can simulate that as described later.

So, before I get into the details of my configuration, I"ll throw this out there... I spent *quite a bit* of time experimenting with various methods to create electrical signals that the LVDS receiver in the display would interpret correctly. Though there"s plenty of room for improvement and experimentation with other methods, ultimately the simplest worked the best...

At the microcontroller-side, each of the four to-be-LVDSicized signals is output on a single pin. That pin, as described before, is at TTL levels; it will ideally be 0-3.3v depending on its value (low or high). Feed that signal into two separate XORs, and configure them such that the output on one will be high whenever the other is low, and vice-versa. (e.g. tie the unused input on one XOR high, and the other unused input on the other XOR low, we"ve made a buffer and an inverter with TTL-level outputs). Now just tie these directly to the differential LVDS signals connected to the LCD. (I"ll add a note that this is based entirely on experiment, if your chips don"t match, I"d highly recommend doing some additional testing *before* connecting directly to your LCD and possibly killing it. I"ll try to explain how, later.)

But wait! This TTL chip is driving TTL levels, not low-voltage! And Why do we need a buffer, since the output of the microcontroller is already at the same levels it"ll output? And, further, my TTL chip isn"t rated for those speeds, nor supply voltages! Or, what about using separate Buffer and Inverter chips?

One note, here: At full-speed (128MHz bit-rate) it *is* somewhat important to use matching TTL chips. When I tried the AHC"s for clock and Blue/Timing and the LS"s for Green and Red, there was a noticeable bit-shift. E.G. Displaying black would come through as a dark shade of green. Replacing the faster AHC"s with *all* LS"s cleared that up quite a bit. LIKEWISE, at these high-speeds, and *especially* when using under-spec"d chips like the LS"s, I recommend using pairs of XORs from a single XOR chip for each differential pair.

I have since purchased 74AHC86 chips (four-gang) and have found that they are capable of driving a 100ohm load at nearly full output-swing. This isn"t good for the LVDS inputs, and actually the display wouldn"t sync up. One method to handle this might be to insert 100ohm series resistors on each LVDS signal wire... 3.3/3 = 1.1V, which is pretty close to the LVDS limit. I have not attempted this.

I have one LVDS-based non-DE-Only display which has yet to display anything but black. Its documentation explicitly states that if a signal is received that doesn"t match its timing requirements it will display black, so it"s possible it was just a coding error. HOWEVER: I did *match* the timing (as best I could with early-code experiments and no feedback) to a timing I tried with it *in my computer.* If that timing was programmed into the microcontroller correctly, and the LVDS was working properly, it should have worked. Which leads me to this: It"s *quite likely* the reason I haven"t gotten this one working is due to my hokey LVDS simulation method... maybe the bits aren"t aligned appropriately with the pixel-clock; the DE signal is active-high while the others are active-low, thus DE may be readable as true as long any bits surrounding DE are also high... Also: With my earlier attempts at LVDS it was found that skinny-bits (e.g. H-sync only = low, the rest of the bits are high) aren"t necessarily active long-enough for the bit to cross the thresholds... (In other words, it the skinny bit may be lost, which is *pretty important* for Hsync). The circuitry has changed since then, and another quick test didn"t work, but I haven"t looked into the skinny-bit-issue since the latest circuitry. There are *many* other theories regarding the LVDS implementation... (e.g. at high-speed with the LS"s, bits may not be aligning correctly, some of the colors are slightly off, dark red shows as slightly green, etc.)

I think a lot of people don"t know how to use it properly, and they are paying too much for displays with a driver chip and even reinforcing the use of modular Nextion-type displays.

From what I understand from this AN, care must be taken to choose the correct clock to match the display clock, and it must also be necessary to use an external RAM memory as a buffer for the display frame.

Therefore, it may be more advantageous to use a driver chip, to avoid a lot of setup with external memory. Since it"s not just a software issue, but also the hardware doesn"t have all the support to perform the direct operation with the TFT display (it doesn"t accept STN either).

The traditional mechanical instrument lacks the ability to satisfy the market with characters of favorable compatibility, easy upgrading, and fashion. Thus the design of a TFT-LCD (thin film transistor-liquid crystal display) based automobile instrument is carried out. With a 7-inch TFT-LCD and the 32-bit microcontroller MB91F599, the instrument could process various information generated by other electronic control units (ECUs) of a vehicle and display valuable driving parameters on the 7-inch TFT-LCD. The function of aided parking is also provided by the instrument. Basic principles to be obeyed in circuits designing under on-board environment are first pointed out. Then the paper analyzes the signals processed in the automobile

instrument and gives an introduction to the sampling circuits and interfaces related to these signals. Following this is the functional categorizing of the circuit modules, such as video buffer circuit, CAN bus interface circuit, and TFT-LCD drive circuit. Additionally, the external EEPROM stores information of the vehicle for history data query, and the external FLASH enables the display of high quality figures. On the whole, the accomplished automobile instrument meets the requirements of automobile instrument markets with its characters of low cost, favorable compatibility, friendly interfaces, and easy upgrading.

As an essential human-machine interface, the automobile instrument provides the drivers with important information of the vehicle. It is supposed to process various information generated by other ECUs and display important driving parameters in time, only in which way can driving safety be secured. However, the traditional mechanical automobile instrument is incompetent to provide all important information of the vehicle. Besides, the traditional instrument meets great challenge with the development of microelectronic technology, advanced materials, and the transformation of drivers’ aesthetics [1, 2]. Moreover, the parking of the vehicle is also a problem puzzling many new drivers. Given this, traditional instruments should be upgraded in terms of driving safety, cost, and fashion.

The digital instrument has functions of vehicle information displaying, chord alarming, rear video aided parking, LED indicating, step-motor based pointing, and data storage. The instrument adopts dedicated microcontroller MB91F599, a 7-inch LCD, and two step-motors to substitute for the traditional instrument. All the information generated by other ECUs can be acquired via not only the sample circuits but also the CAN bus.

The instrument provides interfaces for different types of signals and the CAN bus. All types of signals (such as square wave signal, switching signal, resistance signal, analog voltage signal, etc.) coming from other ECUs can be acquired either from different types of sampling circuits or from the CAN bus. This makes it suitable for both the outdated application where the information from other ECUs can only be acquired via the sampling circuits and the modern application where the information from other ECUs are transmitted via the CAN bus.

The CAN bus interface and the 7-inch TFT-LCD make it more convenient to upgrade the instrument without changing the hardware. If the software needs to be upgraded, we need not bother to take the instrument down and program the MCU. Instead, we can upgrade the instrument via the vehicle’s CAN network without taking the instrument down, which makes the upgrading more convenient. Most of the information from other ECUs can be transmitted via the CAN bus; so, we do not have to change the hardware circuits if some of the ECUs’ signals are changed in different applications. Besides, since most of the driving parameters are displayed on the TFT-LCD, and the graphical user interface can be designed with great flexibility by programming, only the software needs to be revised to meet different requirements of what kind of driving parameters to display and so forth. These characters, together with the reserved interfaces, enhance the instrument’s compatibility in different applications.

It is a trend to incorporate the instrument into the vehicle information system via the CAN bus. The CAN bus interface gives the instrument access to the vehicle CAN network which enables easier fault diagnosing [3, 4] and information sharing. The fault diagnosing could be realized by accomplishing the fault diagnosing protocol above the low-speed CAN bus.

On the one hand, there are some automobile instruments which adopt 8-bit MCUs or 16-bit MCUs which have limited peripherals, so it is difficult for them to meet some requirements such as rearview video and high real-time data processing performance. And many extra components are needed if the designer wants to accomplish some functions such as video input. On the other hand, there are some advanced automobile instruments which adopt high performance MCUs (such as i.MX 53, MPC5121e, and MPC5123) and run Linux on them. They even use larger TFT-LCDs (such as the 12.3-inch TFT-LCD with a resolution of 1280 × 480 pixels) to display driving parameters. These automobile instruments show higher performances than the instrument in this paper. However, they are more expensive than this automobile. This instrument is able to provide almost all the functions of the advanced automobile instrument with a lower cost.

The instrument receives signals from other ECUs via the sampling circuits or the CAN bus interface. It can also receive commands from the driver via the button interface. The signals are then processed by the MCU, after which the MCU may send the vehicle information to the LCD or light the LEDs and so forth, according to the results. Therefore, the automobile instrument can be viewed as a carrier of the information flow. And the design of the system can be viewed from two aspects: the hardware system and the information flow based on it.

Overvoltage protection circuits should be placed at the interfaces of power supply and important signals (such as the CAN bus interface) in case of voltage overshoots.3.1.3. Generality

Reserved interfaces should be taken into consideration to shorten the development cycle of subsequent similar instruments and optimize the instrument for general use.3.1.4. Inventories

The automobile instrument receives and processes information from other ECUs such as the tachometer, the speedometer, the cooling water temperature gauge, the oil pressure gauge, and the fuel gauge. The signals coming from these ECUs are of different types, according to which different kinds of sampling circuits and interfaces should be designed. Accordingly, a classification of the input signals is first carried out, as shown in Table 1.

The microcontroller is essential to the performance of the instrument cluster. Therefore, the microcontroller that suits the system should have rich peripherals to reduce extra components, thus saving the space of the cluster and enhancing the stability of the system. Meanwhile, the operating frequency should be high and the memory size should be large for the demand of speed and accuracy in real-time processing. Besides, various operation modes are needed to lower down the power consumption.

Respecting the above mentioned factors, we finally chose the MB91F599 produced by Fujitsu as the microcontroller. The MB91F599 is particularly well-suited for use in automotive instrument clusters using color displays to generate flexible driver interfaces. It integrates a high performance FR81S CPU core which offers the highest CPU performance level in the industry. Besides, it has a graphics display controller with strong sprite functionality, rendering engine, and external video capture capabilities. These greatly reduce the need for extra components and enhance the stability of the system. The rendering engine can operate in combination with the video capture to enable image manipulation. Overlaid graphics such as needles or parking guidelines can be rendered in conjunction with captured video, which helps to accomplish the aided parking. What is more, multiple built-in regulators and a flexible standby mode enable the MB91F599 to operate with low power consumption.

Square wave signal is the signal that comes from the tachometer. The engine speed, the velocity of the vehicle, and the mileage are proportional to the frequency of the square wave signal. However, the square wave is not “standard” because it is often corrupted by interferences. Besides, the peak voltage of the square wave is +12 V while the I/O voltage of the microcontroller is . The main task for the circuits is to remove the interferences and convert the +12 V voltage to . As shown in Figure 3, the square wave signal is input from node ②; node ① is connected to one pin of the microcontroller.

After the preprocessing of the square wave, the microcontroller detects the positive edge of the “standard” square wave and calculates its frequency. The engine speed, the velocity of the vehicle, and the mileage can be calculated based on the frequency.

The switching signal acts as a trigger signal to trigger some events such as lighting up the backlight and waking up the MCU. It can be categorized into active high and active low according to the ECUs that generate it. Figure 4 offers a complete picture of the sampling circuit of active high signal. The switching signal is input from node ②; node ① is connected to one pin of the microcontroller. Diode clamps the peak voltage of the switching signal (usually +12 V) to the standard I/O voltage of the microcontroller () after resistive subdivision. The sampling circuit of active low signal is similar to Figure 4.

The resistance signal is generated by the fuel gauge and the air volume gauge. As shown in Figure 5, the resistance signal is input from node ①; node ② is connected to one pin of the microcontroller. , , , and have the same value of and they form a series-parallel network to cut down the power consumption of each resistor to one forth that of a one-resistor solution.

The analog voltage signal reflects the battery voltage and the air pressure. The corresponding circuit adopts the resistive subdivision so as to adjust the ratio of the resistors for putting voltage of the signal below the microcontroller’s maximum I/O voltage. The value of the resistors should be a little larger to lower down the static power consumption of the resistors. It is unnecessary to go into detail of the circuit.

The rearview video contributes a lot to vehicle backing and parking. The signal coming from the rear camera must be regulated before being processed by the microcontroller. The rear camera outputs NTSC video. The MB91F599 integrates a video decoder which supports NTSC/PAL video input, which makes the design of the regulatory circuit simple.

The video buffer circuit consists of a clamping circuit (, , ) and an emitter follower (, , ), as shown in Figure 7. Node ① is connected to the NTSC input pin of the microcontroller; node ② is connected to the clamp level output pin of the microcontroller; node ③ is connected to the camera’s signal output. is the coupling capacitor; is the matching resistor to realize the 75 Ω back termination.

Here, the sync signal is not present, so the clamp level is controlled by the clamp level output pin of the microcontroller, which is called “keyed clamp” [5]. The graphics display controller of the microcontroller let the clamp level output occur in coincidence with the sync pulse; that is, the clamp level output occurs during the sync tip in Figure 6, thus we get the “sync tip clamp” [5].

Since the FLASH size of the microcontroller is only 1 MB which is limited for the storage of pictures displayed on the LCD, external FLASH is needed to store different kinds of meaningful pictures such as the background of the dial. Two S29GL256N chips with a memory capacity of 256 Mb are chosen for picture data storage for their high performance and low power consumption. The application circuits of the chips are provided in their datasheets, so it is unnecessary to go into the details of them here.

Controller Area Network (CAN) is widely deployed in automobile, industry, and aerospace domains. As a major trend of the technological development of in the automation industry, CAN is now reputed as a local area network in automation [6]. Its low cost and ability to integrate with most microcontroller silicon families have made it a standard for automobile applications [7–9].

The 7-inch TFT-LCD has a resolution of pixels and supports the 24-bit for three RGB colors. The interface of the 60-pin TFT-LCD can be categorized into data interface, control interface, bias voltage interface, and gamma correction interface.

The data interface supports the parallel data transmitting of 18-bit (6 bits per channel) for three RGB colors. Thus, a range of colors can be generated. The control interface consists of a “horizontal synchronization” which indicates the start of every scan line, a “vertical synchronization” which indicates the start of a new field, and a “pixel clock.” This part is controlled by the graphics display controller which is integrated in the MB91F599. We just need to connect the pins of the LCD to those of the microcontroller correspondingly.

Bias voltages are used to drive the liquid crystal molecules in an alternating form. The compact LCD bias IC TPS65150 provides all bias voltages required by the 7-inch TFT-LCD. The detailed circuit is also provided in the datasheet of TPS65150.

The greatest effect of gamma on the representations of colors is a change in overall brightness. Almost every LCD monitor has an intensity to voltage response curve which is not a linear function. So if the LCD receives a message that a certain pixel should have certain intensity, it will actually display a pixel which has intensity not equal to the certain one. Then the brightness of the picture will be affected. Therefore, gamma correction is needed. Several approaches to gamma correction are discussed in [20–22]. For this specific 7-inch LCD, only the producer knows the relationship between the voltage sent to the LCD and the intensity it produces. The signal can be corrected according to the datasheet of the LCD before it gets to the monitor. According to the datasheet, ten gamma correction voltages are needed. These voltages can be got from a resistive subdivision circuit.

For this instrument, the LED indicators, the backlight, and the chord alarm need to be supplied with a voltage of +12 V; the CAN transceiver, the EEPROM, and the buttons need to be supplied with a voltage of +5 V; the video buffer circuit, the external FLASH, and the data interface of the LCD need to be supplied with a voltage of +3.3 V. Besides, the microcontroller needs to be supplied with voltages of +5 V and +3.3 V simultaneously. Figure 8 offers a detailed block diagram of the power supply for the automobile instrument.

The main task for the program is to calculate the driving parameters of the vehicle and display them on the TFT-LCD. The calculation is triggered by the input signals via the sampling circuits or the CAN bus. The main program flow chart of the system is shown in Figure 10.

The design scheme of a TFT-LCD based automobile instrument is carried out form aspects of both the hardware and the main program flow chart. The MB91F599 simplifies the peripheral circuits with its rich on-chip resources and shows high performance in real-time data processing. The automobile instrument is capable of displaying the velocity of the vehicle, the engine speed, the cooling water temperature, the oil pressure, the fuel volume, the air pressure, and other information on the TFT-LCD, which contributes a lot to driving safety and satisfies drivers’ aesthetics. Besides, the rearview video makes the parking and backing easier and safer for the driver. Moreover, the CAN bus interface and TFT-LCD make it easier for the upgrading of the instrument without changing the hardware, thus saving the cost.

Firstly, depending on the board you are using (with resistive touch, capacitive touch, or no touch) you will have to uncomment the correct one. For example, if you are using the ESP32 TouchDown uncomment: "#define ENABLE_CAP_TOUCH". If you are using a DevKitC with separate TFT, uncomment "#define ENABLE_RES_TOUCH".

You can also set the scale of the y-axis of the graphs. This is done under "// The scale of the Y-axis per graph". If these are to big or to small, the data will not be displayed correctly on the graph. You might have to experiment with these.