Remember the first release ? The (internal) declaration of the NexComm object was extremely tricky since its object type varied with the use of different types of serial ports (Hardware, Software, USB). That's while the initComm() function macro was needed to get around that. All that is not longer needed. A NexComm object - you need one for each connected HMI - is now declared and instantiated with a simple NexComm Nex1;. When you needed debug messages over another serial port, you had to create a NexCommDbg object instead. Not longer needed... If you want some action (function call) when a component is pressed or released, you may simply declare these functions first, before setup(), and then "attach" these to the component in setup(). No need to have a NexListenList or whatever. Each NexComm object handles the list of its attached components automatically: As soon as you call one of the two methods NexComp.setOnTouch(function) or NexComp.setOnRelease(function), it will automatically be registered in the internal listen list if it hasn't yet already been registered before.

Inspired by the famous and extremely stylish (and expensive) wall clocks manufactured by the German QLOCKTWO GmbH which I saw for the first time in a hotel in Lausanne/Switzerland some years ago, I thought that we could try to do something similar on our Nextion Enhanced HMI displays. Please accept that their designs are protected and copyrighted, thus, to avoid any legal trouble, do NOT make a commercial project of this! This article and the related code are for didactic purposes only. The underlying technical principle is to read the RTC clock values and to process these, so that they are displayed in the form of spoken language, highlighted from a static letter pattern. In this article, we'll see how this can be done in the Nextion programming language. Today, we'll limit to the English edition, but I have plans to extend the project to be multilingual (using the EEPROM) in one of the next articles.

Two weeks ago, we talked already about the enhanced functionality of the enhanced "K" series (and btw also the intelligent "P" series) Nextion HMIs. In that blog article, we discovered the integrated RTC and we used the Nextion Expansion board in combination with touch screen buttons to adjust it. Sometimes, especially in industrial or other rough environments, touching a small screen is not the best way of interacting, thus, external alternative IO solutions may be put in place. Today, let's replace the 6 buttons by a single control, an external rotary encoder with push-button, i.e. a EC12 from Alps.Thus, the small Nextion I/O adapter will be sufficient for our needs.

Remember the Sunday Blog articles from November and December 2020? We looked at controlling our Nextion HMIs from an Arduino or compatible MCU. We saw that everything was relatively simple and required only a few lines of code if everything was known in advance: The type of the serial port (hardware, software, virtual USB), the use of a second serial port for debugging (or not), the GUI components we wanted to address, and so on. Just to be clear: This is not about making the well established and approved official Nextion library obsolete! This is a new and different way as a result of the didactical approach in my Blog articles. Depending on your scientific curiosity and your specific use case, you'll prefer to take either the one or he other. In ever case, our "didactic" NextionX library is actually only half-baked: All communication from the MCU (Arduino) towards the Nextion HMI is already and fully implemented. But the current version (0.5.0) does not yet allow to read information (attributes, events) back from the Nextion to the MCU. This will be the subject of future blog posts.

First of all: Happy 2021 to all my readers! And thank you for all your constructive suggestions and remarks regarding this blog! There is a huge positive feedback for the previous episodes where we started developing an ultra-compact alternative universal Nextion library for Arduino which overcomes some restrictions of the official library. For example the ability to handle multiple Nextion HMIs on one single MCU and without needing a specific object for each component type, and, and and... I for myself do not yet know how far this will finally go. But there are also other readers who wrote me that they were more interested in learning about the advanced use of the Nextion programming language. Although nearly everybody seems happy that everything I told and taught over the last 30 episodes runs on a standard "T" HMI, including very advanced mathematics and drawing algorithms, people want to know what the enhanced models bring in addition, besides more memory. Thus, I decided to write one week about specific and advanced Nextion features and every other week, we'll move on with our newNextion library. 

We created already a universal communication class in the last two episodes (Part 7 here and Part 8 here). It allows us with a little less than 60 lines of code in a separate .h file to handle one or even multiple Nextion HMIs connected to our MCU (Arduino or whatsoever), optionally using a second serial port for debugging each. And we can use this classes' cmdWrite() method to send commands to each of our connected Nextion HMIs without caring about the terminator which is automatically added. With this "Multiple Nextion HMIs on one Arduino", we went already beyond most existing libraries.Since, depending on our MCU and its number of serial ports, our class has alternatively to deal with HardwareSerial, SoftwareSerial, AltSoftSerial, USBSerial, we learned that the GNU C++11 compiler which is used by the Arduino IDE is a bit (in fact, very very) finicky about the type of passed object references (Serial, Serial1, Serial2, etc.) when it comes to construct depending objects like our NexComm class, we had the occasion to learn about template classes. We will need this knowledge later.