FTDI Chip | BRIDGETEK CleO35  and NERO-LP1 - Review

Table of contents

RoadTest: FTDI Chip | BRIDGETEK CleO35  and NERO-LP1

Author: rareiss

Creation date: 30 Jun 2017

Evaluation Type: Independent Products

Did you receive all parts the manufacturer stated would be included in the package?: True

What other parts do you consider comparable to this product?:

What were the biggest problems encountered?:

Detailed Review:

Element14 Road Test of FTDI's

CleO TFT LCD  &  NerO MCU Board

by Dr. Russ Reiss,  May 2017

INTRODUCTION

I was very excited when I came across Element14's offer to Road Test the CleO/NerO combination.  Since I had backed FTDI in their Kickstarter.com development effort for the display and MCU board, I already had a set which I had purchased through that offering. However, as so often happens in Life, other commitments had kept me from doing more than a cursory examination of them.  So, my motivation in the Road Test was less in acquiring free units, and more in having some specific motivation (and a deadline) to actually use them beyond just first impressions.  I hoped that the Road Test would be this motivation for me to dig deeper and to truly learn the subtleties of using them.

NERO MCU BOARD

The day came when the units arrived.  It was just a normal small box with two smaller boxes inside: one containing the FTDI NerO (Arduino UNO-compatible) Board and the other the very nice FTDI CleO TFT LCD Display.  The NerO looks basically like any normal Arduino UNO  clone board.

http://www.arduino.cc/en/main/arduinoBoardUno

It is, in fact, a slightly improved version of that ubiquitous Arduino board.  It has the same Atmel ATMega328P CPU, 16MHz crystal oscillator, USB interface, Auxiliary DC Power input jack, Power Regulator, Reset Button, ICSP programming header, and the usual collection of Arduino Digital and Analog I/O headers.  These headers caught my eye right away since they are combination male/female “stacked” headers rather than the more common female only type.  With such connectors, the NerO could plug into some kind of Arduino board while another Arduino “shield” could plug into the NerO: interesting.

The FTDI literature stresses that the NerO uses a switching regulator vs. the more common --and more power-hungry-- linear type.  However, this is used only in generating the 5v power.  There is still a 5v-to-3.3v linear regulator on-board.  If you supply power via the USB connector, this switching regulator does not even come into play. So, other than perhaps lower power consumption when powered from the DC jack, I didn't expect much/any performance difference from any of the familiar UNO clone boards I had used in the past.  And I was not surprised.

CLEO TFT DISPLAY

The CleO Display unit struck me right off as a very professional and even “elegant” little module.  With 480x320 pixel resolution and full 18-bit color, I was eager to see what an image on it actually looked like.  It also has a built-in resistive touch screen and powerful performance achieved by pairing an FT903Q 32-bit micro-controller with their FT810 “EVE” smart display/graphics controller.  There's even a micro-SD card slot at one end and simple audio/speaker capability along with a camera interface!  These “extras” should make it simple to build complete display sub-systems around this unit.

Two things really impressed me about the CleO display and gained my attention right off.  First was the lovely, slim bezel which framed the display and would permit ease of mounting in a simple panel cut-out.  This is where most TFT display offerings fall short. Creating a suitable bezel and mounting scheme comprises a considerable development and manufacturing effort and cost for the user.  Second was the fact that their built-in smart display controller board had rows of standard Arduino (Uno) female headers. Once I saw these, I understood why the NerO board had “stacked” (or “through”) male and female headers.  The intent is for the NerO board to plug right onto the back of the CleO display, and then for additional Arduino “shield” boards to plug into the NerO, making for a rugged and compact smart display sub-system.  Neat!!

After seeing how conveniently the modules could stack one onto the other, my mind was racing with ideas for how this lovely combination might be used with additional shields for a very neat and high performance GUI.  Rather than to simply create a bunch of artificial “benchmarks” by which I could demonstrate the use of these units, I decided to try and do at least the initial development of one or more actual representative display sub-system applications.  There would not be enough time to actually carry  any one of these to final completion, but I felt that by trying to actually use the display in a real application I would find out just how easy or hard it is to use and perhaps identify any major obstacles or shortcomings.

POSSIBLE APPLICATION WITH “HAMSHIELD” RADIO BOARD

As soon as I saw the way that the display, NerO MCU Board, and another shield could be stacked one upon the other, I immediately thought of an application using a new shield I had recently received: The HamShield.

Http://www.hamshield.com/hamshield.html

This single board (with Arduino connectors) comprises a complete VHF/UHF transceiver (both transmitter and receiver functions).  It's primarily intended for use by radio amateurs (“ham operators”), thus the name.  It was funded on Kickstarter.com and I have a unit on hand from that effort.

The HamShield is no trivial product in its own right: it is capable of wide frequency coverage (including the amateur 144, 220, and 440 MHz bands) and relatively high power (one-half watt) for such a small unit.  But most interestingly, it supports all sorts of communication protocols with it's variety of voice and data modulation modes (Voice, AFSK, CTCSS, CTDSS, KISS, PSK, QPSK, DTMF, SSTV, etc).  But it's just the radio!  For many, if not most, applications one requires some type of user interface.  I thought the CleO touch-screen display would be ideal, what with its powerful internal smarts, compatibility with a UNO board like the HamShield, and simple stacking design/packaging.  So, that would be my first project, I thought!  I plugged the three units together (see photo) and started getting very excited over the possibilities. I bought an aluminum box to house and protect everything and started out by simply combining a CleO demo project with a HamShield demo project as a single program. None of the interaction between the programs had been worked out, nor even the precise specification on what the thing would do.  I just wanted to see if all the hardware and software would play well together.

At first, things seemed good. I could talk to both units with very simple test programs I wrote.  But unfortunately, when I tried using more realistic demo programs, results were not good at all.  No matter what two programs I attempted to run together, I would run out of program memory and/or data memory upon compilation.

I faced a few options:

1. - artificially simplify the goal of the project to where I could fit the program in the NerO,
2. - change from a UNO-compatible board (NerO) to something like an Arduino MEGA 2560 or any board with more memory on it      such as (https://www.arduino.cc/en/Main/ArduinoBoardMega2560),
3. - add another processor board to handle the radio and use the NerO just to handle the CleO display.

  None of these options appealed to me, nor did they satisfy the basic goal of this effort: to evaluate the CleO and NerO together in a realistic application! Consequently, I sadly discarded this as a candidate for my Road Test efforts.  I do, however, plan on returning to this project on my own at a later date.

CNC DRO DISPLAY APPLICATION

While I was getting my feet wet attempting to use the CleO in a HamShield application, I was intrigued by many support features offered by the firmware built into the display.  There are a host of high-level commands for controlling the display.  These include the expected drawing tools for creating points, lines, circles, rectangles, and needles.  It includes control over background (color, gradient, or image), line colors, etc.  It supports bitmap images, and even audio and video playback!  But beyond even this impressive list of capabilities, they have “widgets” which offload your processor by letting the display's on-board MCU processor (and graphics control chip) do the work for you!  These include such niceties as: Buttons, Clocks, Gauges, Keys, Progress Bar, Scroll Bar, Slider, Dials, and Text.  I was anxious to try out some of these as well as the other many features!

I began envisioning using the CleO display as something I'd used in a variety of other forms before: a CNC Digital ReadOut (DRO).  These units serve as the operator's interface to a CNC machine.  Their most basic function is to display the status and current position of a tool (cutter, welder, plotter, 3D printer, etc) in X, Y, and Z readouts (and perhaps additional axes if required).  So, I began growing such a GUI piece by piece in a “bottom-up” manner by which I typically develop my projects.  By walking you through my development, I hope to give you a feel for what the CleO/NerO combination can do for you as well as the steps one might use to “grow” a typical application into existence.

Starting with the basic need to display X, Y, and Z axis information numerically, I used the rectangle object command to create three boxes at the top of the display (oriented in “portrait mode”) as seen in the following photo.  I made them different colors just to see that feature work, and used the CleO.Corner() function to round the corners for nicer appearance.  I didn't worry yet about being too precise or putting data in these boxes, but just getting them  to appear on the screen, learning what parameters could be used, and locating them somewhat reasonably on the display.

It then occurred to me that it would be nice to present the data in either Imperial (inch) or Metric (mm) format.  So, I needed something the user could touch to switch between these two display modes, and an indicator to show the current mode (inch/metric).  Rather than simply add a fourth box to the display, I found an image that seemed nice and after altering it some using PaintShop Pro I attempted to put the image data onto SD card so my CleO DRO program could read and display it.  It displayed SOMETHING, but not at all what I expected or exactly what I had created!  I learned that CleO only accepts a limited range of formats (even though they may be called JPG, BMP, or PNG).  I now appreciated what these “PC Tools” were that came in the zipped CleO file I had downloaded on day one!  It started to seem like they thought of everything, and I was glad.  After running my “inch-metric selection” image through their image converter program and uploading it to the SD Card, everything looked as I had expected.  Adding this image to the display required only two additional instructions.

I might point out that the “code” required to get to this point was trivial.  It simply was the calls to the appropriate built-in commands (functions) for generating the grahic elements, with suitable parameters specified.

Note that at this very early stage of initial testing, I simply put everything in the Arduino setup() function.  It ran just once and put the desired image on the screen.  The image remains on the screen until a subsequent CleO.Start()/CleO.Show() pair are executed (with the desired new code in between).  Later, I would move these to an updateDisplay() function which could be called from the main loop(). This routine would create the current GUI image (built using these same commands and more) but with data and parameters appropriate for what needs to be displayed at a given moment.

If you noticed it, you might have wondered why the positioning of the “inch-metric selection” image is at (-43,122)!  This is simply a “cheat” on my part since I found that the image I had created was too wide for where I wanted to use it.  So I position the left edge of it off the screen (negative horizontal start value).  By setting the vertical start value to 122 it drops down under the three XYZ boxes nicely.  Obviously, by setting these parameters appropriately, it could be positioned anywhere on the screen that you desire.

Note also the CleO.begin() call at the very start (this should happen just once, so setup() is where it belongs).  And also the CleO.Start() and CleO.Show() calls.  The Start() function begins a fresh screen-shot buffer.  The graphic commands fill this buffer with graphic objects. And the Show() function causes the buffer to be displayed on the screen.  It's quite simple and practical once you get used to it. However, I was beginning to have some (unfounded) concerns about whether or not such an approach would be fast enough to rebuild the screen when things were actually happening “on the fly!” You will see at the end at the end of this Road Test report in a movie I created that updating the display is super fast with NO artifacts!

Okay, now I was ready to see some data (fake data is fine for now) in those boxes, and some support of the inch-metric operation.  Here the code gets more involved, but the complexity has little to do with the display operation and more to do with manipulation of numeric data, formatting it for display complete with white space and +/- sign in the right places, suppression of leading zeros, and inch-metric conversion math.  So, I won't bore you with the gory details of that portion of code. The next photo shows some numerical data in the X, Y, and Z data boxes (all nicely formatted thanks to this code).  I had a choice of text fonts I could use here, and though Times Roman looked fancier, I went with one that was bold, simple, clean and crisp.  If required, I could have created and used my own font, as this capability is nicely supported!  I was rather pleasantly surprised to find that, even though the display is not “large,” the data could be read from over five feet away easily!

You might also notice that I used the CleO.CircleExt() command to add two red circles on top of the BMP image which I am using for inch-metric selection.  I realized that I needed some way of indicating which mode the data is in: inch or metric, and this seemed a reasonable way to achieve it.  Notice how simply we are able to add a graphic object (filled circle) precisely ON TOP OF the inch-metric BMP image we placed on the screen earlier.  In use, only a single red dot is active at any given time: the one associated with the current mode selected.

Everything looked pretty nice to me now, and by adding some logic to this application I figured I should be able to achieve a basic DRO function.  However, I have this big, free, bottom half of the display available still.  There must be something I can do with that resource!  I know, how about a plot of the tool movement as the CNC machine operation progresses?  It needn't be terribly high resolution since its function would just be to give the operator an idea of how far the operations have progressed.  I settled on a 300x300 pixel area and adjusted the boxes and their spacing to have everything fit comfortably.  Obviously, in practice, the actual data would have to be scaled to fit in this 300x300 area.  I implemented this plotting function with rather simple use of the CleO.Line() functions.  It is almost trivial to control the lines' width and color.  I also added a pair of X, Y coordinate lines to the plotting area, placing the plot's origin (0,0) at the center.

I then created some code to generate dummy data to appear in the XYZ boxes and on the plot and a timing function to present new data once every second.  At first, my logic/code was a bit messed up and the “inch-metric selection” touch function got locked into this updating; you had to touch the display until the next second's data appeared for it to register.  Obviously, this wouldn't do.  So, I broke out a programmed one-second timer function to its own routine.  It just checks millis() and sets a flag (tick) when it's time for new data to appear.  This freed up the main loop to call the touch() checking function as quickly as loop() could do its thing... which was quite fast since now ALL delay()s were removed from the program!!  I normally would implement these things using hardware timers and interrupts, but I wanted to stick with as pure and simple Arduino coding as possible.

Now, setup() is very simple, it just initializes the display with CleO.begin() and sets the value of a few variables.  The main loop() routine is also quite simple, repeatedly calling checkTimer() and touchControl() functions as fast as it can run its loop.  A bit of simple logic controls the presentation of (dummy) data at a once-per-second rate (for ease of viewing).  It repeats the (same) data over and over.  Inch-metric modes may be changed at any time, regardless what the plotting is doing.  I first required the user to touch the “inch-metric selection” image bar to register a change.  But I found it way more convenient to permit touching anywhere on the display to toggle the inch-metric mode.  This required just a simple change to the program related to the use of the CleO.Tag() function.  The red dots let you know which mode is currently selected, and the data in the XYZ boxes is converted and displayed appropriately.  The following video shows this “final” CleO DRO handling the dummy data (being generated by the program itself) and my finger changing modes at will (sorry the movie is not in better focus, but that was the best my camera could do).

https://www.youtube.com/watch?v=I1EtNyZgt0s

Edit media

Dimensions x Small Medium Large Custom

Subject (required) Brief Description Tags (separated by comma) Video visibility in search results Visible Hidden

Parent content

FTDI Chip | BRIDGETEK CleO35  and NERO-LP1 - Review

Poster

Upload Preview

Ok

Cancel

The dummy data I used in this demo  is simply repeated generation of regular polygons with edges numbering three to fifteen.  The timing control I built in causes a new edge to be drawn every half-second using the CleO.Line() function.  This seemed to be a rather simple, yet interesting use of the plotting area and also permitted checking the validity of the XYZ data displayed in the three boxes.  One might notice that there's some obvious round-off error occurring, but it's quite minor.  When using the Atmega328P with Arduino, both single-precision (float) and “double-precision” (double) floating point numbers both use the same 32 bits.  In other words, there is no true 64-bit  “double” data type as might be found on the Arduino Due and other higher-end Arduino boards.  This could be an important limitation when trying to utilize the NerO in some applications.

  CONCLUSIONS

• The NerO UNO-compatible board seems adequate for simple to moderate tasks.  The simple prototype DRO program as presented above uses 10330 bytes of the 32k available for program memory.  It uses just 818 bytes for global dynamic memory, leaving 1230 bytes of the 2k SRAM available for local variables.

• The NerO board does not seem adequate for more advanced programs.  I would suggest that an Arduino MEGA 2560 be used.  FTDI might seriously consider offering such a support MPU board.  Also, many of the more advanced ARM based boards would be suitable. The ESP32S unit has extensive Flash and SRAM, both Wi-Fi and Bluetooth capabilities, and probably sufficient capability to nicely interface with the display.  Someone could mount it on a UNO-compatible shield board for plug-in compatibility.

• It would be nice/necessary for the MCU board to support multiple I2C and SPI interfaces so it can handle both the CleO display as well as other devices required by the application.

• The control processor and graphics processor on the CleO display board work very well together and support the smart command set in a very easy to use way.  Drawing functions are quite adequate and logical to use.  A powerful set of “widgets” can ease much of the GUI creation process, although I did not find them necessary for this particular demo application.