«The FTDI Chip EVE graphics controller: Sophisticated graphics using only a modest 8-bit MCU Chapter 1 Most electronics enthusiasts strive to make ...»
The FTDI Chip EVE graphics controller:
Sophisticated graphics using only a modest 8-bit MCU
Most electronics enthusiasts strive to make their projects as user-friendly and
commercial in appearance as possible. I'm no exception, and lately I have been
trying to use TFT colour displays with touch-screen capability whenever practical.
Although they are still somewhat expensive, you should also consider the savings
that you can obtain by eliminating many of the switches, potentiometers, etc. that the touch-screen can replace.
In late 2013, FTDI (the company that makes the USB-serial interface chips we all use) started advertising their new EVE display controller chips. Soon afterward, MikroElektronika started selling 4.3” TFT display boards based upon this new controller. I got quite intrigued at this point, and started to look into the EVE controllers more closely.
Basically, the EVE controller chip is a very intelligent TFT display controller which can handle TFT panels up to 512 x 512 pixels, in up to 18-bit colour depth, or resolution. They will interface to any MCU with an SPI port, which covers most all MCUs apart from a few low pin-count ones. The EVE SPI interface is high speed (up to 30 Mb/s). This, coupled with the fact that the EVE controller is an intelligent one, executing high-level graphics commands, means that you can achieve very impressive graphics displays, even if you are hosting it on a modest 8-bit MCU, as FTDI's advertisements claim. In my personal experience, it is possible to implement a very nice GUI using the EVE controller driven with the Atmel AVR Atmega328 (as found on the Arduino Uno board, for example.) The EVE controller provides a comprehensive variety of low-level graphics commands such as those needed to clear all/part of the screen, draw lines, rectangles, circles and other basic block figures. In addition, it also contains a co- processor engine, which adds a whole series of widgets such as buttons, sliders, rotary controls, clocks, switches, progress bars, etc. These are generated quite easily by sending out the proper widget command, along with the parameters needed to customize it to your needs: i.e. size, orientation, full scale value, etc.
The EVE controller also handles the resistive touch-screen functionality. In addition to the normal touch screen routines, where the controller returns the X-Y value of the spot being pressed, the widgets mentioned earlier can be “tagged” with an ID number, and when the user touches those widgets, this distinctive “tag” ID is returned to your program. This makes a touch-enabled GUI quite easy to implement, even when using only a modest 8-bit MCU.
Finally, the EVE controller provides an audio output. I'll discuss this further, but at this point, let's just say that the EVE can “play” sound files of various compressed formats. Also, it implements a sound synthesizer function, which allows it to play musical notes, melodies, or provide sound effects.
Now that you have a basic idea of what EVE will do, let's step back a bit, and take a comparative look at the various other methods that are available to provide a colour TFT touch-screen capability to your MCU project. In a previous article, I outlined two basic approaches to adding a TFT display to your project. The first one involves the use of a “dumb” TFT display which employs an 8-bit (or 16-bit) parallel interface to your MCU of choice. These displays are very inexpensive on eBay (10-20 EUR) but
they do have some disadvantages:
They require up to 26 digital I/O lines on your MCU, forcing you to use a 1) higher pin-count MCU than you might otherwise employ. All TFT displays operate on 3.3V, so all of these I/O lines must be at 3.3V levels.
You must find the proper driver firmware for your chosen MCU, and this driver 2) often uses up a lot of Flash memory space that you could otherwise use for your own program. You should also be aware that while these displays come in a limited number of physical sizes, there are many different LCD driver chips used on the different panels, which makes finding the proper driver somewhat more difficult.
I should mention that some of these “dumb” TFT displays are now being designed with direct Arduino compatibility. That is, they are mounted on a PCB which will plug directly into an Arduino Mega 2560 (or they include a “transition” PCB that goes between the TFT display itself and the Arduino Mega 2560). The Mega2560 MCU has plenty of I/O capacity, which addresses concern #1 above, and some of these display modules come with Arduino drivers, covering concern #2. Such Arduinotargeted boards contain level-shifting chips to handle the 5V levels present on the Arduino Mega 2560.
I tried one of these “dumb” TFT display/Arduino combinations, and while it may not be typical, I found that while the display module that I received worked, it was so dim
that it was unusable. I suspect that these Chinese vendors are selling “seconds”:
TFT displays that don't pass the normal QC standards of the TFT panel manufacturer. I have seen feedback from customers on various websites regarding this shortcoming. You may want to think twice about going down this route.
The second approach involves a serially-interfaced TFT display which contains its own intelligent display controller MCU. Such displays contain a whole library of highlevel graphics routines and touch-screen handling, all of which you can access by sending the appropriate commands to the display, over a high-speed serial data link.
Such commands are pretty compact in relation to the complexity of the graphics objects that they generate, so a standard serial data link, at a high baud rate (i.e.
115,200) is adequate to produce quite useable graphics display.
I've had excellent results on several projects using the µLCD series of displays from 4D Systems in Australia. They come in many sizes from small mobile-phone sizes up to large 4.3” displays. The SE article that I referred to earlier covered these displays in detail, as well as including lots of hints and examples of Bascom/AVR code to use with them. I recently finished a personal project using 4D Systems 4.3” µLCD display: an IR remote control which controlled my flat-screen TV and the three peripheral units associated with it. In place of the myriad of small buttons present on four separate remote controls, this unit features a clear, easy to use graphics display containing only the commonly-used buttons on each of the individual IR remotes.
The user can quickly switch amongst the four “screens” (one per remote unit) using a small push-button. An added advantage to this approach is that this unit is easy to see in the dark, which is not true of a standard commercial IR remote. Image 1 shows one of the two such units that I built recently.
4D System's new “Workshop” IDE program contains a very high-level method of designing the various graphics screens needed for such a project. If you are familiar with Visual Basic, you would find 4D Systems “Workshop” IDE very easy to use in designing a nice GUI for your application.
The disadvantage of the 4D Systems µLCD display is that they are relatively expensive. The 4.3” model, with a resistive touch-screen, cost about 100 EUR, when I bought them last year. They also need a µSD card to be inserted into an on-board socket- to hold the files containing the graphics images for the various “widgets” that are a part of the user's GUI design. This adds about another 5 EUR to the price of the display.
I happened to have 2 extra 4.3” µLCD displays left over after finishing a commercial project I designed/built recently, so it cost me basically nothing to use my “spares” for the IR remote controller project. But, since I felt that the average user would not likely be interested in such an expensive IR remote, I decided against writing an article about this project, at least in its present form (but I am working on an EVE version/article).
So, with this quick comparison of the various TFT display options out of the way, let's look in more detail at the EVE controller and the display panels that are currently available.
Since I am a fan of the 4D Systems intelligent µLCD modules, you might wonder how I became interested in the EVE display controller chips. Well, to start with, there was the issue of price. Right from the start, it was clear that EVE-based TFT display modules were going to be a lot less expensive than the 4D systems µLCD display modules. For example, the 4.3” size (which I find ideal for many of my projects) was available in MikroElektronika's Connect-EVE module, costing about 50 EUR. This is about ½ the cost of a comparable 4D Systems µLCD module.
Another consideration concerned the interface method. While I generally like using the serial port method used by µLCD modules, there can be some disadvantages to it. For any graphics applications requiring fast motion, or complex graphics operations, the speed of the serial port can be a limiting factor. Also, many AVR MCUs contain only a single serial port, so a problem exists if you have an additional peripheral device that also needs a serial port. Indeed, if your project needs a USB port capability, you will often use an FTDI USB-serial interface chip for this purpose, so two serial ports would be needed if you also use a µLCD display.
The EVE graphics controller chip instead uses an SPI interface, along with a couple of other control lines (*PD and interrupt). An SPI port is much faster than a serial port. In the case of the EVE chip, it is capable of running at up to 30 Mb/s. You won't be able to achieve this high a rate with common AVR chips, as their highest SPI rate is SYSCLK/2 (8 Mb/s when using the 16 MHz crystal common on Arduino boards).
Still, this is 69 times faster than the 115,200 baud rate that you could use between an AVR MCU and a µLCD display.
The other advantage to the SPI protocol is that you can have many different devices sharing a single SPI port, so long as they all don't need to communicate simultaneously. So, even with a modest Atmega328 MCU, you can drive an EVE display along with several other SPI peripherals, as well as any other peripheral that needs a serial port.
A second advantage to the EVE display controller chip is that it uses an advanced method of generating all of the “Widgets” or graphics objects which you might need.
These are all generated and stored within the EVE controller chip itself. In contrast, the µLCD displays form their widgets using bit-map images, which must be stored in the µSD card mounted on the µLCD board. This µSD card also holds any other images that you need to display, as well as any sound files. While the cost of a µSD card is low, it's important to note that one must download these bitmap files to the µSD card using the PC computer that is running the 4D Systems “workshop” IDE program. This usually requires the use of a USB card-reader module on most PCs (apart from laptops).
To put this in another way:
All of the code needed to generate a GUI on an EVE display is contained in 1) the firmware you write for your chosen MCU, which can be easily distributed.
The µLCD displays will require that you write firmware for your MCU, which 2) you can easily distribute, but you (or the end-user) must also have access to the 4D Systems “Workshop” IDE (which runs only on a PC) to generate the necessary GUI bitmaps. These must then be downloaded to a µSD card, which is then inserted into the µLCD display's on-board card socket.
As you can see, the EVE method is more straight-forward, particularly if others need to duplicate your project.
As I mentioned earlier, both EVE-based and µLCD modules handle all interaction with the touch screen using internal, high-level routines. That is to say, your program is relieved of the task of constantly scanning the resistive touch screen display for presses, and then doing a lot of calculations with X,Y co-ordinates, to determine which of the buttons, widgets, etc. was actually touched (or adjusted). On both of these displays, your program merely polls the display controller periodically, and it returns a code which identifies which widget on the screen was touched. This is really nice!
The last major feature of both of these display modules involves sound generation capabilities. The µLCD display's sound capability involves playing various types of compressed sound files, at a fairly low bit-rate and resolution. This file(s) must be downloaded to a µSD card, which is then mounted into the display's on-board socket. When I used µLCD displays for my most recent project, this was the only way to generate sound. In other words, if you needed something as simple as a “beep” or a click to indicate a screen touch, you had to download a compressed audio file to the µSD card. I think they should have allowed for a simple routine which generates a square-wave tone, the frequency and duration of which you could pass to the display as command parameters. Something along the lines of Bascom/AVR's SOUND statement would have been fine. The larger µLCD displays contain an audio amplifier and a very small, 12 mm speaker.
In the case of the EVE display controller, the sound functions are somewhat more versatile. It can play sound files in various formats (8-bit PCM, µLAW, 4-bit ADPCM) like the µLCD displays. However it also contains the equivalent of a MIDI synthesizer (something like the one I described in my previous article) which can either play simple musical melodies, or be used to provide simple beeps and clicks as needed for user interaction with the GUI. Playing a note consists of just a few short commands specifying the MIDI instrument, musical note and note duration. The MikroElektronika Connect-EVE modules that I am using have an audio output pin, but no amplifier or speaker on-board. I haven't needed or tried out the sound capability of the EVE controller yet.
What's your preference: 5V or 3.3V Displays?
If you are using an AVR MCU, you are probably running it at a Vcc 5 volts. You get full speed operation that way, and many of the common peripheral IC devices operate on 5V. The most commonly-used Arduino boards also operate on 5V, although this is gradually changing with the advent of the Due, as well as numerous “clones” from other manufacturers that operate on either 3.3V, or both 3.3V and 5V.