FTDI Chip | BRIDGETEK CleO35  and NERO-LP1 - Review

Table of contents

RoadTest: FTDI Chip | BRIDGETEK CleO35  and NERO-LP1

Author: adsicks

Creation date:

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?: Smaller OLED displays. Serial Lines

What were the biggest problems encountered?: Minor glitches in the libraries.

Detailed Review:

I would like to thank Element 14 and Bridgetek for allowing me the privilege of RoadTesting the NerO and CleO touch display. This has been a product that has given me plenty of fun and enjoyment working with.

 

Description

 

The NerO is an energy efficient Arduino  with both male and female headers. The male headers connect it to the CleO, a high performance tft screen based on the FT81x graphics controller and the FT90x microcontroller.

 

image

Pins on the back of the NerO for easier mating with CleO

 

Features and Specifications

 

NerO

The Nero is an energy efficient Arduino clone that allows a full 1 Amp  current draw without overheating. It also features:

 

  • Hi-Speed USB to one-wire interface converter
  • On-Off Switch for added user convenience
  • FTDI FT231X USB UART
  • 5V Switching regulator

 

image

NerO Arduino reference design

 

CleO

A 3.5 inch tft display that uses a single SPI line for communication with the NerO. It has pin pass-through functions. Other features are:

  • FT81x graphics controller
  • Touch and audio functionality
  • FT90x 32-bit RISC microcontroller(310DMIPS)
  • Anti-Aliased graphics
  • Smooth animations at up to 60 frames/second.
  • Portrait and Landscape modes
  • Micro-SD/e-Flash  up to 8 simultaneous file operations without using Arduino resources
  • Panel Mount Bezel

image

Back panel of CleO

 

 

Software Libraries

 

Bridgetek provided some excellent libraries to use for GUI programming on the CleO. They are surprisingly simple, yet powerful. They are very easy to learn and use because Bridgetek has provided drawing primitives. The primitive allow drawing of:

  • Strings
  • Bitmaps
  • Lines
  • Points
  • Circles
  • Rectangles
  • Needles

There are also numerous color constants defined to give a wide variety of colors.

There are also several widgets provided by Bridgetek along with the EVE widgets. These so called CleO widgets add functionality that is lacking in the built in FT81x widgets. The CleO widgets are.:

  • Color Picker
  • Set Date Time
  • Alphanumeric Keyboard Input
  • Sketch Pad Input
  • KeyPad

 

 

Unboxing

 

My full unboxing report is here.  In short, The NerO and CleO both fired up. There was no hard manual, but the documentation on the webiste at CleOstuff was impressive. There were full tutorials to help get started. The primitives are intuitive and easy to use.

 

Grid-EYE Applet

I wrote an applet to display data from a Panasonic Grid-EYE connected to a 1-wire bus for another RoadTest. The full RoadTest is here.  This video shows the configuration screen and the running data capture. All in all it only took about 500 lines of code and 6 hours to write and debug. Getting the gradients working correctly seemed to take up more time than getting the GUI working.

 

 

Video of applet that displays Grid-EYE data.

 

You most likely noticed that the numeric input for the temperatures is oriented for portrait instead of landscape. This is by design. The widget will not fully display in landscape mode. The OK and Cancel buttons are offscreen. So I had to re-orient the screen when the widget was shown.

 

As an example of how easy the primitives are to use, here is the main loop that draws the Grid-EYE data on the screen:

 

           for(idx = 0; idx < 8; idx++)
            {
                for(idy = 0; idy < 8; idy++)
                {
                    pixelTemperatureF = fAMG_PUB_CMN_ConvStoF(pixelTemperature[idx*8 + idy]);
                    CleO.RectangleColor(GetColor(pixelTemperatureF));
                    CleO.RectangleXY(60+(idx*40), (idy*40), 40, 40);
                    Serial.print(pixelTemperatureF, 2);
                    Serial.print(" ");
                }
                Serial.println();
            }

 

Drawing the squares to represent the pixels only took 2 lines of code. The call to CleO.RectangleColor sets the color and CleO.RectangleXY sets the x and y coordinates and the length and width respectively. It took more lines of code to create the temperature gradient:

 

uint32_t GetColor(float temp){
  uint8_t r, g, b;
  uint8_t rmax = (colorHot & 0xff0000UL)/65536;
  uint8_t gmax = (colorHot & 0x00ff00UL)/256;
  uint8_t bmax = (colorHot & 0x0000ffUL);
  uint8_t rmin = (colorCold & 0xff0000UL)/65536;
  uint8_t gmin = (colorCold & 0x00ff00UL)/256;
  uint8_t bmin = (colorCold & 0x0000ffUL);
  uint32_t rCol;
  
  float pct =(temp-minTemp) / (maxTemp - minTemp);
  r = rmin + pct * (float)(rmax-rmin);
  g = gmin + pct * (float)(gmax-gmin);
  b = bmin + pct * (float)(bmax-bmin);

  rCol = (uint32_t)((r * 65536) + (g * 256) + b);

  return rCol;
}

 

This is the entire function to create all of the toolbox icons used in the demo:

 

// icon handles
uint16_t hIco_pause, hIco_play, hIco_settings, hIco_camera;

void DisplayIcons(){

 if(GErun){
    CleO.Tag(1);
    CleO.Bitmap(hIco_pause, 420, 0);
  } else {
    CleO.Tag(1);
    CleO.Bitmap(hIco_play, 420, 0);
    CleO.Tag(3);
    CleO.Bitmap(hIco_settings, 420, 120); //Open SettingsScreen
  }//depends on play or pause

 CleO.Tag(2);
 CleO.Bitmap(hIco_camera, 420, 60);// Take Screenshot
 UpdateIcons = false;

}

 

Event handlers take a little more work, but they are created first with the call to CleO.Tag before displaying the image or text you want to use to capture a touch event. Then, in the main loop a control() function is called that calls CleO.TouchCoordinates. Then tag of the item that was touched can be polled in a switch statement as is done in many GUI libraries.  The typical main loop looks like this:

 

void loop(){
     
     display();
     control();

}

 

 

Here is part of my control loop for my Grid-EYE demo:

CleO.TouchCoordinates(x, y, dur, tag);
  UpdateIcons = true;
  
  if (previousDur == 0 && dur != 0){
       previousDur = dur;
       switch(tag){
           case 1:
           if(GErun){
           msg="Pause";
            Serial.println("Pause"); 
            GErun = false;
           } else {
            msg="Run";
            Serial.println("Run");
            GErun = true;
           }
           
      // pause run
            break;

 

 

The full code is included at the end.

 

Summary

 

The NerO is an Arduino that delivers a full 1 Amp of power without overheating by replacing the LDO regulator with a switching regulator. The Cleo35 is a high performance tft touch display with a GPU and microcontroller, sound and SD card slot. The CleO is easy to code with the provided libraries. Bridgetek did and excellent job with the documentation. I was able to create an applet to display data from the Grid-EYe in about 6 hours time. Only 2 of those hours were spend programming the basic GUI.

 

The only downsides was the SD card being behind the bezel making it difficult to access in some mounting positions and there is no way to access the SD card from the computer once it is hooked up to the NerO because the USB plug is on the back of the CleO. Unfortunately, I really don't have any idea how it COULD be layed out any better. There is an up side of the SD card being behind the bezel. If this is used in a security application the SD card will be physically secured from the users.

 

I did have a few problems with what appears to be memory leaks. For example, in the DisplayIcons() function show above if I used a single variable as a file handle to load the icons then called CleO.Free() afterwards the relays on the MAXREFDES130# would hum and the applet would crash. Using globals for file handles fixed that. However, I was using the  CleO_1.0.1 libraries and there have been a couple of updates since I started. I didn't update them because I didn't want to worry about any code breaking in the middle of the other RoadTest. So I'll try the updated libraries and see if some of the leaks are fixed.

 

I really enjoyed working with the NerO and CleO for this RoadTest. This is a great touch screen for use on the Arduino platform that doesn't break the bank. In fact, after using this screen I will have a hard time going back to LCD and OLED screens. I think I am spoiled now.

 

What's Next

 

My next post will demonstrate my Arduino Graphing Component tester  that I am in the process of porting from an OLED screen to the CleO.

 

image

Graphing Component Tester in progress.

I am using the MCT-1601 code for this next project and used the Cleo Tools provided by Bridgetek for the Windows platform to create the icons.

 

The next step is to integrate this tester with the Mixed IO capabilities of the MAXREFDES130# and then re-write the Grid_EYE demo to use the OneWire library from Bridgetek so the Grid-EYE capture can be sent directly to the desktop. Hopefully I can fit all of this into the NerO's memory so I can have component testing and heat sensing all in one unit.

 

I would also like to figure out why my Charger Doctor USB ammeter is not doing USB passthrough so I can get an accurate power comparision with an Arduino Mega. So until next time, happy hacking.....

Anonymous
  • No, but Bridgetek has a their load test example that is repaetable on this page --> brtchip.com/m-nero/ Scroll down a bit. I would like to repeat a test that is similar to that one but I wanted to use the serial line.  The CleO pulls about 170mA at an idle and 180mA while displaying graphics is the reason I would like to do it over serial. I hooked it up to a USB power consumption meter and something is now wrong with the USB pass through piece of it.  The pass through worked before because I used it ti test and compare the consumption of a couple of infrared mice.....

  • Nice test report.

     

    I was very curious as to how easily the display could be setup, so you have given me a data point to consider for potential future applications.

     

    Have you actually tested the full power delivery capability or just repeating the specification?

     

    DAB