With this project I set out to build an interface from my Arduino micro controller to the Nextion panel so that I could pass commands to it and receive commands back.
This built the basics of driving the panel and get information from the panel.
In addition there is a sample program that can be given control of the panel. In this case the program draws a maze on the panel without loading any code on it. The program clears the panel and then begins to draw on it. It was designed for a 4.3 inch panel, if yours is smaller you will need to adjust the code.
So using the Arduino console you can send commands to the panel through your microcontroller and receive commands back from the panel. Most of the codes that the panel can generate are broken out so that if you wanted to use one of the functions for your own project the code is there.
The code assumes that you are using the default baud rate for the panel which is 9600.
One of the issues I came across was that there is no simple commands like getPixel or setPixel. It would have been nice to be able to determine if a pixel was on or off or even what color it is. Internally there must be something as you can draw lines and circles just not set pixels.
Here is a link to the Arduino code on GitHub.
How is fill command not set pixel
But there is indeed nothing for getPixel.
Indeed one could use the line draw command and draw a one unit line. This display seems to require a lot of hacking to get things the way you need them. A lot like displaying nice gauges. All they are are a bunch of pretty pictures strung together.
Lower Level Basics.
The building blocks to what all others are created from
- allows you to build everything as you wish.
In such little space that firmware resides, there is little need
or desire to provide duplicate with only a changed name.
Duplication consumes the space that the truly new requires.
The comment of gauges being a bunch of pretty pictures strung together
Such is animation. Even a Hollywood Star Wars film is 30 pictures per sec.
If you have a problem with a HighLevel HMI Display, feel free and use a plain LowLevel gLCD panel. There are plenty out, even Itead offers them ...
Connect it to your Arduino and programm everything you like in a LowLevel based manner ... then you have a 100% control about what you like to do ...
But besides kicking pants, read documentations of e.g. 4d systems solution how they do things instead of always blame Nextion HMI solutions.
It seems, everything which is not realized via a special command or object is a hack for you ... sorry, but it seems you even missed the nature and sense of a programming language.
- BUILD YOUR OWN THINGS ...
just to clarify
by default, Nextion displays offer a HMI concept by design. Even a small STM is used for underlaying work, even a plain gLCD panel is part of, the Nextion neither offer all STM available things to outside nor is it a standalone Arduino replacement nor is it a replacement for any simple gLCD out. It is what it is, a HMI concept. A Human Machine Interface.
It is out of scope of any HMI concept, to take over heavy duty calculation parts. It is also out of scope of any HMI display to offer all available graphic primitives of a simple gLCD.
In theory, many things besides HMI can be done.
- you can implement whole arcade style games in your Nextion
- you even can calculate Prime numbers on your Nextion
- you even can process a serial SQL query if you like
But again, the Nextion HMI was NEVER designed to do so, so don't expect so. As a HMI component, the Nextion should be used for the Interfacing part, and the machining part should really stay on the machine aka MCU ..
Out of curiosity, do you also still use Assembler to create your Windows programms and GUI components? Or in other words, would you call Assembler code a "Hack" ?
Actually I was looking for a plan LCD panel. None that I found offered the resistive touch I was looking for or where designed as a shield which I did not want. I program with a Parallel Propeller chip in C code which by the way I did have to use assembler since it required a precise timing loop that could only be done in assembly language. The freedom to use multiple languages makes the unit more flexible and open for the application developer.
To develop the maze application I first built it in C# on my windows machine. Building the code on the MCU would not have allowed me to single step through the code and find the many coding errors that I made. It did however provide the setPixel and getPixel functions. This aided in the development process. I then ported it to the Butterfly board which I interfaced to the Nextion panel. The fact that it was missing these functions seemed odd since they would have had to use it to build the circle and line draw commands. It probably would have cost them nothing to include it in the microcode.
There are many things the Nextion panel can not do such a full motion video or flowing GPS maps. Knowing these things in advance is helpful in the design process. Many times developers will get samples to tryout just to find these types of things. Reading the documentation is not always helpful in determining if it will work for a particular application.
Gerry, to say that assembly is a hack is a little off base. Every computer runs assembly language and using it is just a tool. I write in C code because I know it will generate assembly code and can be used on many different platforms to produce the correct code for that platform.
Gerry it would seem I hurt your little baby here. You must have been one of the designers of this panel.
My intent with this application was to show people how to interface the Arduino to the Nextion panel as I read time and time again on this website about not having any examples of doing this. Also processing the return codes is also not so simple. Showing some examples helps provide better documentation.
Using this code others can imbed there own maze code into this application and use it as a building block to try out there code before it is ready for prime time.
Face it, many people that visit this site are first time builders looking for answers. Once there application is finished they will probably never visit this site again.
Why can't Nextion follow a GPS Map?
- Well its not Nextion actually following the map
But Nextion is surely able bring up grid 834 and put a marker.
I'm with you there. To display a bit map should not be a problem. The issues is once I start moving and I want to slide the bitmap to the right or left and move on how do I load new bit maps to display. It's not like I can send it new bit maps on the fly.
Even with an enhanced unit that has an SD card that could hold all the maps, how would one get the maps loaded onto the screen so they can be displayed.
I find the irony in picking the propeller for an MCU
- since it too is proprietary, interpreted, and choice is limited to only what is provided.
I might argue that precise timing is setting MCU registers and not via assembler
all byte level interpreted instructions consume processing time to make calculations
do what hardware is unencumbered for.
But perhaps the propeller doesn't provide you with such register access
- so no surprise that proprietary interpreted Nextion doesn't provide register access either
But propeller is also missing, and only allows what their interpreter provides for.
How to slide bitmaps is a skill issue and not a Nextion issue
Several times, the sliding of bitmaps has been shown it can be done
Stump the Chump showed an example.
Creating Tic Tac Toe Game in Nextion Logic
Resource map only needs to be included in HMI Picture Resources
With the limited resource of the Nextion panel there would be only enough room for a small area so don't get lost.
I disagree about the Propeller chip. If you program in SPIN it is interpreted. But if you code in C or Assembler it is machine level and actually with it multicore process it is very easy to build application that can handle many different sensors at one time and not lose a millisecond in time since it doesn't rely on interrupts to process other sensors.
One of the problems with Arduino code is that interrupts mess with timing which is one of the main reason to use a Microcontroller as they run in real time. For example to generate a PWM output on Arduino requires you to program a Hardware timer and set its timing to control a pin. On the Propeller chip you only need to start one of the cores with this process and your done. Timing is right on and easy to code.
The same can be said of any microcontroller that is multicore, multithreaded.
The use of an inferior chip (reference to Arduino) is not a valid argument
- ... the problems of Arduino code ... and then discuss hardware.
Arduino MCUs can be programmed in other than Arduino C++ IDE
and this makes no reference to the underlaying hardware used
ie: the Intel Edison can also be programmed using an Arduino C++ IDE
... but why ... when better tools low and high level exist to do so
Code and Hardware can not be compared in such a manner
comparisons of code and code, hardware and hardware
the rest is too ambiguous to be a supporting argument.
But back to the GPS concept
- room for small area is subjective to resolution used
- argument deflates and fails on simply changing resolution
- high resolution small space perhaps
- but low resolution, entire states are within display range.
- area is not limited by the Nextion alone, but by total resources of system
this includes MCU and all attached resources.
- As you describe even a propeller and a simple display are not capable alone.
As an example
I can certainly fit all of the 2015 roads, lakes, rivers and boundaries for
both Canada and USA at a 3 meter resolution on 32GB microSD (29.3GB)
when that is coupled with an Edison, massive possibilities exist
Including being able to generate "local to now" resources to HMI
Hell, when really creative,
one could even upload new HMIs on Meal, Rest and Gasoline Stops.
But Nextion is designed as an HMI device and not a Garmin or TomTom
When a GPS is required, it makes sense to use a GPS designed system.
Ready for MCU control.