I have already blogged (for example here) about controlling Arduino's (or any other microcontroller's) I/O from a Nextion HMI with a simple and easy to understand custom protocol, not requiring a complex library. I had imagined that from the basic examples I gave, people would extend them for more functionalities. But from the feedback I received (you'll fin my email address at the end of this article), I learned that you, my dear readers, prefer apparently getting more elaborated ready-to-use solutions. Thus, instead of the previous approach which was bottom-up, we'll try now the top-down. That's why I started developing a huge new project, which explains my relative silence during the last two weeks. Curios? Please continue reading!

Blogging about the Nextion Summer Sales and the generous discounts alone did not seem to me to be enough to satisfy my dear readers. Thus, I thought this could be a nice occasion to do a simple animated demo project which would run on all series and not only on the Intelligent series with their extended animation support. I decided for the NX4832F035 from the Discovery series, but the HMI file (you'll find it as usual at the end of this article) can be compiled and uploaded on any Nextion HMI display having a 480x320 resolution, like the NX4832T035 or the NX4832K035, without any modification! Choosing a different screen size or resolution would require to rework the picture resources just a little.

Three weeks ago, I published an article about simple serial communication from a Nextion HMI towards an Arduino, so that the latter could handle 25 buttons on a screen with only a handful of code lines. This was intended to show that for many simple use cases, there is often no need for using a complex library and the Nextion protocol with its variable message lengths and the famous 3 x 0xFF terminator. The week after, I went on, this time showing a simple event handler for the Arduino, so that it could process events auto-generated by the Nextion, just by enabling the "Send Component ID" case for all components. Since then, we were bound to the Nextion return data format, the Arduino side code was somewhat more complex but still shorter and simpler than using a library. Nevertheless, it seems that did not so much trigger the interest of you, my dear readers, the click rate was only about 60% of the article before. From which I conclude that you prefer simpler solutions... Lets get back to a more basic approach, allowing to simplify things by sending only two bytes, a command byte and a data byte, and make it fool- and accident-proof without a terminator sequence.

Today is a very hot day, at least where I live. 34°C or 93°F outside and 29°C or 84°C inside my home office in a 400 years old house without A/C... Nevertheless, after two successful articles about the basics of serial communication, part 1 here and part 2 here, I didn't want to leave it at the theory. Thus, today we move over to practice.

In part 1 of this article series, published last Sunday, we learned about the difference between CPU and MCU, about integrated peripherals which act independently and communicate only on purpose with the CPU, and about (because the UART is the most solicited peripheral in most MCU based projects) the way, an Arduino (or any other MCU) handles incoming serial communication. But, as I learned from your feedback, many readers didn't yet see the link with the underlying problem which led to the creation to these tutorials. Thus, I'll try to move on, this week, and make things still clearer!