The Sunday Blog: Energy efficient design with Nextion HMI – Portable and wearable designs

The Sunday Blog: Energy efficient design with Nextion HMI

Portable and wearable designs

A small Nextion HMI display, an Arduino-like microprocessor board, one or more sensors, and all that in a small housing working on batteries. Doesn’t that sound appealing? The answer is clearly “yes”. But is it realistic? Again, “yes”! But there are several aspects to consider on the hardware and the software side to prevent your 18350 Lithium-Ion battery to be emptied within half an hour. In this article, we’ll try to shed some light on these considerations and I’ll give you a few hints.

One microprocessor but multiple consumers

There’s a reason why, in the embedded world, a microprocessor is called MCU which is an acronym for MicroController Unit: All our little Atmel AVR or ARM Cortex something “processors” contain much more than just a CPU. There are also integrated RAM, Flash ROM, Timers, and UARTs (Serial), I2C, SPI, I2S peripherals, and much more. Power saving on all these MCUs can be obtained by lowering the power supply voltage (within the allowed specs for reliable operation), or by reducing the clock frequency which, on the other side, can have a negative impact on the function of some integrated peripherals. Then, some of the integrated peripherals can be deactivated, at least those which aren’t in use.

While lowering the supply voltage (if possible) requires most times a fundamental change in the hardware design, reducing the clock speed and deactivating internal peripherals can be done in software. This has the advantage that you can use event handling to put your MCU to sleep, for example after a few seconds of inactivity, and then to wake it up when needed on predefined triggers.

So, most MCUs can be “calmed down” in several steps, from just idling down to deep sleep by writing appropriate values to the corresponding system control registers and be “woken up” again by restoring the original values. Since it is not everybody’s cup of tea to thoroughly study the specific MCU’s reference manual and then to modify the system control registers in a bare metal way, and since the most popular C++ extension by Arduino has absolutely no support for that, you might look for an appropriate library, for example on GitHub. Why re-invent the wheel?

Not all MCUs are equal…

Basically, one can say that the more recent MCUs are basically more power efficient and have – on top of that – more power saving options than older ones. For example, an Arduino UNO R3 clocked at 16MHz with a running program and powered with 9V consumes up to 100mA (which in part is due to the highly inefficient on-board voltage regulator), while a 48MHz Seeeduino XIAO draws 10mA at full speed when powered over USB. While the UNO can be brought down to draw around 10mA which is the normal consumption of the XIAO, the latter can be put into a sleep mode where it draws less than 0.1mA while it remains still awake enough to react on level changes at its GPIO pins to wake up again. 0.1mA instead of 10mA, that’s 100x the battery lifetime!

Thus, if you are into the design of battery powered projects, be careful to build these around recent MCUs with good hardware and software support for standby and sleep modes!

The Nextion HMIs

These are built from a MCU, some external memory (Flash), a LCD controller, the LCD panel, a touch controller, the touch panel, a PWM controlled power supply for the backlight, and the backlight LEDs. When we look at the data sheets of the Basic series, we find that the normal current consumption ranges from 90mA for the 2.4″ to 145mA for the 3.5″ displays at full luminosity. A few lines of scribbling and solving 2 equations with two unknowns later, we can see that we can approximate the consumption to a permanent 35mA plus 3mA per square centimeter of visual area. From which we understand immediately that reducing the display brightness by setting the dim system variable to a value <100 will reduce the power consumption but we will never reach below 35mA which is still ways too much for a hypothetic standby mode in a battery operated device.

But if we remember well, we’ve read somewhere that the Nextion HMIs have a sleep mode. That’s true! And the good news is that in that sleep mode, the Basic and Enhanced series draw 15mA, while the new Discovery Series draw only 4.5mA. Again, a more recent MCU pays! Putting the Nextion HMI into sleep mode will thus not only darken the display but also deactivate temporarily other internal and external components, but not all, since it will need to monitor the serial port and the touch panel for events which might wake it up again.

How to…

… put the Nextion automatically into sleep mode? There are several ways, all controlled by system variables: setting ussp=n will let the Nextion HMI sleep after n seconds without activity on the serial port, and  thsp=n similar – sleep after n seconds without any touch event. But before saying “good night” to your display, you should tell it under which condition it should wake up afterwards, if not, only a hardware reset will reanimate it!

… tell it when to wake up? Setting usup=1 will make it wake up as soon as serial data arrives, and thup=1 when the display is touched. This first “wake up” touch will not trigger any touch event, thus, the touch coordinates don’t matter.

And manually, if you want your MCU (Arduino or whatever) control the energy saving, just send the command string “sleep=1ÿÿÿ” over serial to put it immediately to sleep. Even with usup=0, the Nextion will wake up when receiving the command string “sleep=0ÿÿÿ” while ignoring all other commands.

And now, the cherry on the cake!

While the new Discovery series HMIs draw already only 4.5mA in sleep mode, this consumption can again be divided by 18! 0.25mA can be obtained! For this, the Discovery firmware adds a new system variable which is set to 0 by default: lowpower=1 will do the magic. Then, when putting the Discovery to sleep as usual, it will enter a deep sleep mode with that again reduced current draw. The only caveat is that it will need a little more time, about 50ms, to wake up. You won’t notice it on waking it up by touch, but if you wake it over serial, make sure to send the wake up command, first, then wait 50ms before sending further commands or data.

BTW: The launch of the Discovery series HMIs is imminent – stay tuned!

Happy Nextioning!