The Sunday Blog: Nextion News

The new Discovery (F) Series HMI displays arrive!

As announced a few weeks ago, we are now at a point where worldwide semiconductor and other materials shortages ask for more creativity from our side to maintain our LTA commitment. As it is actually very difficult to source reliably the MCU inside the smaller Standard (T) Series HMI displays, even when paying 10x the initial price, it was big time to think about a drop-in replacement for these which we can offer in big quantities and at a more reasonable price. That’s why my Chinese colleagues “gave birth” to a new series of HMI displays, called “Discovery”, available in 3 sizes: 2.4″ and 2.8″ with a 320 x 240px resolution, and 3.5″ with a 480 x 320px resolution, just like the Standard or Basic (T) series.

And that’s how they look:

The yellow/orange pcb colouring is very distinctive compared to the rather decent blue of the T series.

A true drop-in replacement ?

Yes! The physical dimensions are the same as the Basic (T) series, as are RAM and Flash ROM sizes. The power/UART connector and the SD card slot are in exactly the same place.

The LCD panels look identical in terms of brightness, contrast, color tone, and viewing angle as you will see below.

During the beta test, I re-compiled about 50 HMI projects for the T series which I have on my hard disk and all ran on the Discovery (F) series without the need of altering the code. Uploading the compiled .tft files @921600 baud, using a CP2102 USB to TTL serial adapter worked 100% reliably.

Thus, be it a single project or mass production, switching from Basic to Discovery series is as easy as opening the HMI file in the Nextion Editor, changing the target device with 3 mouse clicks and compiling/uploading again!

And the performance?

Under the hood of the Basic series, there is an ARM Cortex M0 CPU @48MHz. But the new Discovery series are powered by a Cortex M0+ @64MHz. The clock speed is thus 33% higher. Beyond that, the Cortex M0+ has an extended instruction set, compared to the “normal” Cortex M0, which could again increase the performance, depending on the application, and always under the condition that there are no other bottlenecks in our system which would pull the handbrake of the CPU. So, ideally, we should expect a noticeable performance boost.

What you will quickly see, is that the Cortex M0+ allows already for more efficient .tft code. Today’s example project, the benchmark test below, compiles to a 222,876 bytes tft file for the Discovery display, while exactly the same .hmi file compiles to 332,412 bytes for the Basic display. It gets exciting…

The benchmark test

How to compare two HMI systems, especially if they seem to use identical graphics hardware (LCD controller and panel) ? After thinking some time about that, I decided that it should be “something with circles” because that’s a true challenge for an embedded system without numeric coprocessor. For each pixel of each circle, a calculation or approximation of values corresponding to a sine and cosine has to be done, or alternatively a coordinate transformation which invokes squares and roots. Whatever method is implemented in the firmware, it challenges the embedded MCU. Not enough, I decided to add to the challenge by calculating varying color gradients and letting the Nextions draw series of concentric circles with varying radius.

The HMI benchmark project

GUI-wise, it’s simple! A simple page with static black background as a canvas for the circles drawn by the cir GUI command. At the bottom right a number component which displays the current loop counter value. Add a font and you are done.

Code-wise, we need first to define a few global variables in the program.s file:

int le,lm,li           //loop vars for the 3 nested levels
int c                  //center coordinate
int has_r,has_g,has_b  //color components
int lum,luc,rev,lr     //helper vars
int color,radius       //calculated drawing variables
page 0                 //Power on start page 0

Then, everything happens in the page’s postInitialize event:

First, the (identical) center x and y are calculated from the page width. Then, there are 3 nested loops which control the counter and the drawing direction, increasing or decreasing radius (outer), the RGB base value (intermediate), and the fine gradient (inner). finally, the display is refreshed and the counter display updated.

c=b[0].w/2 //calculate the center coordinate(s)
le=0       //initialize the counter
while(le<65536)
{
  //outer loop for counter and drawing direction
  rev=le%2 //if counter is pair form inner to outer, else reverse
  for(lm=1;lm<8;lm++) {
    //intermediate loop for the 7 RGB base values: has_b=lm%2 has_r=lm>>1%2
    has_g=lm>>2%2
    luc=has_r<<5
    luc+=has_g
    luc<<=6
    luc+=has_b    //assemble a RGB vector in 565 coding
    lr=lm-1<<4    //calculate the radius offset
    for(li=0;li<16;li++) { 
      //inner loop for the gradient 
      lum=li*3/2+8  //calculate the gradient value 
      color=luc*lum //multiply with the RGB vector 
      if(rev>0)
      {
        radius=112-lr-li //calculate the radius form outer to inner
      }else
      {
        radius=lr+li     //calculate the radius from inner to outer
      }
      cir c,c,radius,color //draw the actual circle
      doevents             //refresh the screen
    }
  }
  le++      //increment the counter
  n0.val=le //display the counter value
}

The benchmark result

Now, how to measure the performance in absence of a reliable RTC? The answer is letting the benchmark run in a loop and increase and display a counter on each run. If you start both devices under test at exactly the same moment, you’ll probably see that one counter will have reached a bigger or smaller number after some time. If you make the observation period long enough, this will allow to compare precisely the different performance factors:

As we can see, and longer time observation confirms it, the overall performance of the Discovery over the Basic series is between 36 and 37%, as expected! If we see now on top on this that the compiled tft files are smaller and we can thus “stuff” more code and resources into the Discovery’s flash memory, there seem to be only advantages for switching from the Basic to the Discovery series.

And the best, although not yet officially published: The marketing department whispered me that thanks to the lower price and better availability of the MCU, the retail price of the Discovery will be lower than the corresponding Basic HMI displays, and that despite of the improved performance!

Questions, comments, suggestions, bugs? Open a discussion in our forums!

Happy Nextioning!