Rarely has a design changed the Makerspace like the Arduino. You can find them just about anywhere, with varying prices from less than 10\euro all the way to over 100\euro for the most advanced models. One of the major strong points for Arduino has been the shield support, a unified header system that allows people to buy existing shields to add functionality, or for the more adventurous to design their own. You can find shields for prototyping, motor control, 110/220V relays, LCD segment screens... Just about anything, really. And yes, you can also buy shields with TFT displays.

Reading the Arduino

It's late afternoon, and I need to buy my monthly train ticket. I go to the new hall that they have made here - no more queuing up in a line of people, there are comfortable sofas, and several screens indicate which client should go to which desk. Before sitting down, I arrive in front of a machine, that asks me why I am here. I have a few options; information, immediate departure, or future departures. I press the screen on the digital button, and the screen changes, to inform me of my number. A printed version comes out, and judging by the number I got, I have a few minutes to wait.

Multiple systems exist for printing data from an Arduino. 16x2 LCD screens are common, but lack elegance. TFT displays exist, but until now, they haven't been anything sexy. I have a few designs hidden away in my boxes, most of them can indeed print text, but remind you of the pre-TFT era of DSTN laptops. The text isn't crisp, the colours bleed, and more importantly, it is extremely slow. I mean painfully slow. Animations consist of writing text, wiping the zone, and then reprinting text. I've never actually delivered a project with TFT screens because, well, I can't look a client in the eye and expect him to be happy with the final product. Now, to be fair, you do get what you pay for, and you can't expect a 10 or 20\euro board to get you far. My 10\euro board lasted the time it took to write an Arduino book, and now looks too fragile to take out of my drawer.

CleO

The CleO is a shield for Arduino, used to showcase the FTDI FT810 EVE graphical processor. It would be unfair to call it an evaluation board, it is ready to be used as-is in most situations.

CleO exists in two formats; the CleO35 is a 3.5" TFT touchscreen with a resolution of 320x480. The CleO50 is the bigger brother, and boasts a 5" screen with a resolution of 800x480. It comes as an Arduino shield, in a rather surprising orientation, which I'll go into later. It has, of course, the beautiful TFT screen, but also has a micro-SD card slot, PWM amplified audio output, and a camera interface. FTDI supplies modules for both video and audio. The device comes ready to be mounted, and has CE and FCC certification, ready to be used.

In this review I'll go into the CleO35, since that is the board that FTDI and element14 kindly provided for this review.

NerO

The makers of CleO had a problem. The CleO board uses up to 150mA just for the TFT display. It also includes a speaker, so when outputting at maximum volume, that figure goes up. Add a few components and a camera, and you find yourself close to 500mA. If you need another shield, then you might have a problem. Anyone who has used an Arduino project that needed more than 500mA will know what I'm talking about; sooner or later you start developing electronics just to handle the power, because the Arduino regulator can't.

Enter FTDI, with the NerO. Their aim was simple; create an Arduino Uno compatible device, but rethink the power regulation circuitry.

The NerO exists in three formats; NP, SP and LP. NP is short for No Pin, meaning that there are no pins underneath the board. This is what you would expect from a normal Arduino. SP is short for Short Pins, meaning that the shield headers extend out from underneath the board. LP, for Long Pins, means that the pins extend out from underneath, and are longer than the SP format. The board provided was the LP version, and there is a good reason for that, which I will go into in the next section.

Shield orientation

The CleO is a surprising shield. Typically, you take an Arduino, and you place your shield(s) on top. The CleO is different, the Arduino is placed on the CleO, and not the other way around. While some might think that this breaks shield compatibility, this approach does in fact work very well. You probably don't have an Arduino at home or at work that can work natively with the CleO, but there are two options. Number one, the NerO, designed specifically for the CleO both in terms of shield headers and power regulation, or if you want to use something else, FTDI also sells an "inverter" allowing you to use your Arduino, or compatible.

The advantage to having your Arduino on top of the LCD is precisely for shield compatibility, and once you try it, it does grow on you. Before trying, I thought that this would be a bad point, but it isn't. The CleO sits flat on the desk, and the LCD screen sits back a little, so it won't scratch. Having the shield in this orientation is a plus, especially if I want to add an RTC to my project; it can sit on a breadboard on the opposite side to the LCD screen, and everyone works happily together.

Software

It isn't just about the hardware; the hardware can be the best in the world, if there isn't any adequate software, then it just doesn't work. Fortunately, this has been thought through. The kits come with a welcome text, inviting you to connect to a website, CleOstuff. The website itself is rather light; there is a video tutorial, some news, and the download packages, but don’t be fooled by the simplicity. Slow Internet people, beware! The file weighs in at close to 600 megabytes, so it might take some time.

While the website might be light, the software package most certainly isn’t. We’re not talking about the 1 kilobyte README file that tells you how to download the package, which you don’t need to read because you already downloaded it. No, this package comes with one ReadMe (clocking in at 11 kilobytes), and four folders. The one called “Arduino Libraries” is clear enough, “SDCard” and “PCTools” too. The fourth one, called “Documents”, is a little vague, but this is where the magic happens.

Hello, World!

The CleO35 (and indeed the CleO50 too) uses a system of image frames. The Arduino no longer knows anything about the image; instead, it instructs the CleO to perform certain actions. The advantage is memory size, you don't need to have a large buffer containing image information. Another advantage is the video processor, something I haven't seen a lot of on other boards. With some LCDs, if you want to draw a square, the software needs to calculate each pixel, and update the scene. Remember your “Hello, world!” application on a 16x2 LCD screen? If you printed out a number with 2 digits, and then again with a single digit, the second digit was still on the screen. If the temperature sensor first said 10 degrees and then 9 degrees, if you weren’t careful you would print out 90. To safeguard that, you added a space at the end of the string. But wait, what happens if the digit is 3 numbers long? Add another space. Oh, forget it, just add a bunch of spaces at the end, effectively wiping the text. That won’t happen with the CleO. The Arduino tells the CleO to “write x at y”, and the CleO’s graphical processor does the rest, and it does it very, very well.

Let’s try with the most basic of programs; Hello, World! First you need to initialize the CleO engine, using the CleO.begin() function. Now you are ready to go! To create a new frame, use the CleO.Start() function, and to print the frame, use the CleO.Show() function. In between the two, several functions can be used, I’ll use the CleO.String() function which prints out a string at a specific location. The code looks like this:

void setup()
{
    /* Initialize CleO - needs to be done only once */
    CleO.begin();
    /* Start building a screen frame */
    CleO.Start();
    /* Draw a string "Hello World" at (160, 240) */
    CleO.String(160, 240, "Hello world");
    /* Display completed screen frame */
    CleO.Show();
}

That’s a program that is easy to understand, and indeed, it is actually the first program in the CleO documentation; Tutorial 2a (tutorial 1 being the setup process).

Touchscreen

The CleO isn't just a fancy screen, it also has a fully integrated touch controller, using resistive touch technology. Touch manipulation is good on this screen, but remember that this isn't a mobile telephone; it only registers a single press. However, since it uses resistive touch technology, you can use your finger, a pen, or any other device.

The Cle035 requires a fairly powerful press, much more than you would use on a mobile phone using capacitive touch technology. The increased pressure means that you won't drag, only activate widgets, but the screen feels solid, and doesn't warp when you apply pressure.

From a software side, registering a touch is simple; using a system of tags and touch. A tag can be assigned to a widget, so it is possible to know if a particular widget is being pressed or not. It is also possible to get \texttt{x} and \texttt{y} coordinates for the touch location, as well as the duration of the press.

Widgets

A device is only as good as the software, and in this case, the software is only as good as the widgets provided. In the case of the CleO35, the software is excellent, and there are a large amount of widgets provided. The typical dots, lines, rectangles and circles are provided, but it goes further to provide needles, something you don't see too often.

Text manipulation is this device's strong point, since you can add your own TrueType fonts on the SD card.

Benchmarking

Benchmarking, the art of getting figures, and trying to compare them to something else, but it isn't always that easy. One of the easiest benchmarks is the random rectangle; display a rectangle using random coordinates and then start over, ending in what is often a rather nice 60s style wallpaper. On the CleO, this isn't possible, so no 1960s wallpaper for me. The CleO's graphical processor generates frames, so every frame is calculated, that is to say if you want a button at a particular place, and a line here, a rectangle there and some text, the engine will calculate that, and each frame will be unique. This has advantages; if you are making a digital voltmeter application, you don't need to delete the text before rewriting at the same place (something users of 16x2 LCD screens probably know very well).

So, the question remains, how fast is it? I came up with a few routines to see just how fast it is. Since the Arduino has a rather nice way of calculating the amount of milliseconds that the sketch has been running, I decided to create some routines to see how long a frame would render. This is the strategy I've been using:

unsigned long StartTime = millis();
CleO.Start();
/* Draw frame */
CleO.Show();
unsigned long CurrentTime = millis();

The very first frame, however simple, takes a rather standard constant 52 milliseconds, probably from the need to initialize the screen. From there on, every frame I rendered, no matter how complex, took around 16ms between the CleO.Start() and the CleO.Show() function. It is difficult to see on-screen just how fast this device is, but the results would indicate a rather comfortable 60Hz refresh rate.

To dive a little deeper, I wrote a quick sketch that draws a line from one corner to a specific number of pixels. The code looks like this:

StartTime = millis();
for (i = 0; i < 300; i++)
{
    CleO.Start();
    CleO.Line(0, 0, 310, i);
    CleO.Show();
}
CurrentTime = millis();

In this example, we will be drawing a diagonal line, from one specific pixel at 0,0 to 300 different pixels. The result is a very smooth animation, with no flicker or shearing, perfectly anti-aliased. The entire operation clocks in at 5077 milliseconds on average, for a total frame time of 16.9 milliseconds, or to put it another way, approximately 59Hz. Drawing lines might seem simple, but it isn't. When lines are parallel to screen edges, the operation is simple, but I designed this test to force the processor to use geometric calculations, and it performs very well.

Conclusions

I'll be honest, I had to take a break during this review, making it one of the longer ones I've written. The original NerO board was defective, making a review impossible. A few logistical problems made sourcing a replacement difficult, but the new NerO works perfectly, and the CleO never had a problem. This incident does not affect my review, except that it took longer than expected.

FTDI promises a device that can "be easily programmed by almost anyone to give professional looking HMI / GUI's with no prior knowledge of complex graphics programming". So, how did it fare? Very well! I have two decades worth of embedded experience, but I've never really done any graphical programming before, so I might have been the ideal candidate for this test.

Creating a graphical interface is indeed simple; just tell the CleO what you want, and where, it does the rest. The anti-aliasing is beautiful, and doesn't really give you hint of pixel size. Rendering is lightning fast, and by adding your own fonts, pictues and animations, the possibilities are almost limitless.

The build feels solid, and did indeed survive being poked at by a six year old kid. She was able to use the programs I wrote without any difficulty, applying the right pressure on every widget. The screen itself is bright, and usable in sunlight. Viewing angles are pretty good for a device like this, but with notable color changes. If you want the best user experience, it should be used by a single person at a time, standing right in front of the device.

The documentation is good, but I did find myself frustrated at times; when looking at a function, I wanted to see exactly what the function required, and what it returned, but I couldn't. The documentation lists the functions available to the programmer, but clicking on them sends you to an example. The examples are very well thought out, but some information is still missing, so you end up copying and pasting the line, and replacing what you understand, leaving the rest.

The CleO/NerO solution won't appeal to everyone, since you can't control individual frames. If you are looking to make 80s screensavers, this won't be the ideal kit for you. However, if you are looking to make fire and forget display applications, the CleO/NerO solution provides a very professional display, something that I'm not ashamed to show to a client, and something an end user can use while feeling confident in the project.