Start a new topic

Nextion HMI FLASH/SRAM consumption

Hi,


I'm a new user of Nextion HMI.


I plan to use a Nextion Resistive Display for "big" projects (to give an idea: 30x pages, 40x txt objects of 20 characters per page + some icons).


Currently, I'm trying to estimate if resources provided with a Basic/Enhanced Nextion HMI display matches with my need.


My question is about FLASH and SRAM consumption of the Nextion display.

I read in the forum SRAM is (obviously) used by the Nextion display firmware/interpreter itself and by the objects used in each pages + the variables of the user code (PreInitialize + PostInitialyze user code).


I interpret the internal display operations as following:

  1. The Nextion WYSIWYG graphic builder generates a .HMI file.
  2. The .HMI file allows to generate (compilation) a .TFT file containing the firmware of the display + all the pictures + all the static properties of each object of each page. The dynamic properties of each object require some SRAM (.txt, .bgo, picc...). FLASH is used to store the firmware, the pictures, the objects of each page and the static properties of each object + the size of each dynamic properties (for ex: number of bytes for .txt property).
  3. The .TFT file (binary image) is loaded inside the display (using the built-in SD card slot) or over the serial loading protocol.
  4. At startup, the firmware reads in FLASH memory the structure of the page 0 and load it (w/ or wo/ Pre/Pots Initialize user codes) by reading the static properties. This explains each time a new page is loaded, if PreInitalize user code is not used, the default properties defined in the Nextion WYSIWYG graphic builder are displayed.
  5. Then, the host µC (let's say an arduino, for instance) can set dynamic properties such as .txt property.
  6. As (AFAIK), each time a new page is (re-)loaded, the dynamic properties of each object in the page are loaded with the values defined in the Nextion WYSIWYG graphic builder, I suppose the SRAM dedicated to the user is available for the newly loaded page (shared user SRAM area).
Thats' my understanding of the internal operation.

Now my question:
After reading an answer of Patrick Martin in the forum:

[quote]

When you realize that on the Basic model of the Nextion, its onboard mcu is limited

An STM32F030C8T6 8K SRAM, and 64KB Flask with 4M/16MB SPI Flash.

The 8K SRAM is responsible for both the firmware and the HMI,

- reserving 3584 bytes per page for each page in the HMI file.

[/quote]

Can you confirm my good understanding of the internal operation:
  1. FLASH is mainly used for the firmware, pictures and structures describing each object in each page.
  2. User part of SRAM (3.5Ko for the Basic Nextion Display) is available for each page: so, if I declare 30 pages with 40 txt objects (of let's say 20 characters), I do not require 30 x 40 x (dynamic properties + txt max size) of SRAM in total.
Sorry, for this long post, but it is vital for me to estimate if the Nextion Display can be used in my "big" projects and to estimate the spare FLASH and SRAM in case of an evolutive project. It would be frustrating to be stuck for an evolution.

Regards,

RC Navy.




First, I am certain that my quote is in a user request to bloat firmware with unneeded functions.

 - where would such firmware expansion go, except to decrease resources of user HMI.


SRAM is shared resource between the firmware that run Nextion and user HMI needs.

   The T series Basic Models have an STM32F3030C8T6, 8K SRAM/64 Flash MCU

     - as such 3854 bytes is available to the user HMI page.

   The K series Enhanced Models (3.5"+) have a larger GD32F103RBT6 20K/128K MCU

     - on these models, 8192 bytes is devoted to the user HMI page

The available SRAM is displayed on the StatusBar of the Nextion Editor for selected model

Device Toolbar item where user selects model for HMI also shows this amount.


The HMI design is static and uploaded in SPI flash, 4M/16M/32M (also shown in Device)

The Nextion firmware then interprets HMI at runtime with static design values available.

  - as such, when page loads on page changes, old is dumped new is statically read in 

Also told in the forum many times, the order of events on page change


PreInitialize Event of loading page runs

Old page values is dumped - new page is loaded as per user design

PostInitialize Event of loading page

Nextion waits for event to occur, either 

   - timer event

   - command over serial received

   - touch event

   - component binding event over GPIO (enhanced models)


So with the exceptions of Global variables, all else is dumped between pages

In the Nextion Editor during the build process with "Compile Button"

  The Output pane messages now display

      Global Memory usage

      Page stats (for each): Global + Page SRAM usage = total SRAM usage.

A Total that exceeds available is an obvious error.


Dynamic attributes of a component may/may not use SRAM

 - some changes have been being made, where past was .val and .txt only.

HMI Component design is in SPI Flash and do not necessarily use SRAM.


So reviewing:

1) Nextion Editor is mostly WYSIWYG - GUI section of Nextion Instruction Set less so

2) First two sentences correct

    MCU Flash for firmware, TFT will consume available SPI flash (size depended as per device)

3) Correct.

4) Preinitialize and PostInitialize are always used.

5) User MCU can do more than just change components dynamic attributes.

    With the exception of block instructions (those requiring { }, such as if, while and for)

    the user MCU can send serially and acceptably formed Nextion Instruction.

    It is therefore possible to build complex HMIs with almost no components via GUI

6) SRAM available between pages is both system variables and global variables.


PART II

1) see #2 above

2) Correct.  SRAM is not accumulative on whole project.

    The "Compile" build process reveals page consumption for each page.

     - Best to think of each page as individually running program + shared Globals.


The concept of HMI (Human Machine Interface) is not just for MCU to change component values

  - this is a status aspect where Machine updates current status back to the user.

  If this was all it was (to change component values), a simple display (terminal) would suffice.

But the more powerful aspect is the interfacing with the Human user

  - allowing input from the user to the Machine and MCU decides and reacts on such input.


The use of minimal pin count for a display (thus two wire over Serial) frees MCU side resources.

- but with a balance that things as graphics and fonts are stored Nextion side

     so that these bandwidth heavy resources do not clog the two wire Serial.

- couple that with Nextion side logic is able to preprocess user input, reducing RX/TX further.


And the simplest quickest means to HMI is selecting Component Send Component ID 

 - allowing MCU to be informed of Component touch events and MCU side can process.


But the larger the project, the closer you approach Nextion's limits.

 - limits of available SRAM

 - limits of available SPI Flash

 - limit of 65534 total project attribute/code lines

More thought to keep the design efficient and within limits is required the more complex the design


1 person likes this

So if you have taken the steps already to download v0.46 of the Nextion Editor

- you are already able to do more than just estimation on SRAM usage.

Placing the required components on the page, 40 text of 20 length and 5 pictures


1310 bytes used per page as spec'd to the above.

Each and every page spec'd the same will use the same - 1310 bytes

How much of this is global on each or any of the pages?

 - again set .vscope to global - compile again.


In worst case (as per what you described), the MCU sends to Nextion

   40 commands to fill in the text components on page change

       page12.t14.txt="12345678901234567890"ÿÿÿ

   38 to 40 bytes per text, x40 components = 1600 bytes worst case

Using 115200 baud, allows ~11520 bytes per sec, so ~140ms

   (give or take, smaller txt lengths, and timing is never optimal)


But an array char texts[30][40][20] will use 25200 bytes

   (text 20 will require null termination of 1 additional char)

   this will definitely exceed any Nextion model if all are to be globals.

Page by page, Nextion is indeed able to handle

  the better question is can your selected MCU handle.


Perhaps this is getting away from HMI design as for Human Machine Interfacing,

But such a 30 page 40 item menu can be done

 - designed for the 3854 byte 3.5" NX4832T035_011 model.


image


Such uses 1648 bytes of Global Memory 1323 bytes per 40 Text Page, Max total of 2971 bytes used.

    This is within the 3584 bytes available for user's HMI design.

Each of the 1200 Text components with Press and Release functionality.

  - creating 2400 user defined functions to be handled MCU side.


But where this gets far away from an HMI design is

  who's to code 2400 functions 

tft
(1.41 MB)
ino
(425 KB)

So I tinkered around throughout the day on optimizing colossal.ino a little.


Colossal Menu

 - 30 pages of

       40 Text Components with

            20 characters

            Touch Press Notification to MCU

            Touch Release Notification to MCU

       5 Icons

            Home (1st)

            Prev (2nd)

            Next (5th)

 - Master Menu

      Menu of 30 pages - click to change

      onChange, notify MCU

          MCU updates 40 dynamic Text components

              with current text values

          MCU repositions for the 40 item 80 functions relevant to page

   - Optimized 40 item Text change on page changes

        for 40 items @20 chars, reduced to 888 bytes needed to update

           at 9600 baud ~925 to 1000ms, @ 115200 baud ~85 to 150ms


Nextion side TFT

    1523 Components

     ~2689 to 2900 event and code lines

    Lower side SRAM usage   884+1323 for 2167 of 3584 bytes

    Upper side SRAM usage 1648+1323 for 2971 of 3584 bytes (redundancy)

    TFT file size 1480951 bytes of 4128768 bytes available for TFT in SPI Flash

     So room for some Nextion side decoration


MCU side Arduino framework with Iteadlib Arduino Nextion Library

     Tweaks to NexConfig.h and NexHardware.cpp/h needed

         for chosen MCU and page change notification and handling.

     2400 user defined functions (30*40*press/release)

     ~12376 lines of code (can trigger user function, did not write user function)

     handle page by page

     Dependent on MCU, I coded with an PSF-A85 in mind (occasional report differences)

         281869 of 761840 bytes 36% flash used    ~58.5K  Nextion HMI related

           58732 of   81920 bytes 71% sram used    ~26.6K Nextion HMI related

So probably plenty of room for enhancing the framework on user MCU side.


I think that this should prove even the smaller T Series Basic models

   are more than capable of handling a large workload even if

   this is deviating away from Nextion's purpose of Human Machine Interfacing.


1 person likes this

 Hi,


thanks Martin, for these very very detailed answers: awesome technical assistance. :-)


Now, I'm reassured with the capabilities of the Nextion displays.

You demonstrated that the N series are able to match with my need, but to secure my design, I will use a K series (enhanced), which provides more spare FLASH and SRAM for future evolutions with a serial communication set at 115200 bauds between the Nextion display and the host MCU.

Additionally, you gave me some tip and tricks to optimize the FLASH/SRAM consumption and some advices for MCU side (where I'm more comfortable for FLASH/SRAM consumption estimation).


I believe this post will be beneficial for lots of embedded hardware/software designers.


Thanks again,


RC Navy


Login or Signup to post a comment