I want to read the spec on how a "progress bar" is to be set up.
I want to read the spec on how math precedence works on the Nextion.
Is there any place / document that describes how the Nextion works? Yes, I have the "Nextion Instruction Set", but it doesn't describe the "toolbox tools".
Is the only way to find out the details of a Nextion display by trial and error and nosing around?
for this we have the
- Forum in general ...
- Tutorials in the forum in general ...
- Tutorials in the Gallery ...
- Tutorials in the Free Chat ...
just read them, use one of the many example HMI's out, load it in the editor and look what the code does ...
what shell an extra document show more than such examples?
Sorry Paul, such minor details are not documented.
I believe the next version soon to be released is v0.44, so things change a bit.
As such, there are those here that will aid others to get over their hurdles.
A spec for how a progress bar is set up ... hmmm
click progress bar component
new progress bar is generated on canvas
adjust attributes as desired in attribute pane
Nextion math precedence
integer math, no floating support
non complex expression left to right
no math precedence (requires complex expression)
How Nextion works
Connect GND line to common GND
Connect RX to TX
Connect TX to RX
Connect 5 volts to 5V line 1A or 2A as per recommended
As electrons begin to flow Nextion magic occurs - should come on
Overview of the tools in Toolbar
From Nextion Editor
Select Help Menu Item under Help Menu
This launches Web Browser to Nextion HMI Solutions page
Follow links to Nextion Editor Quick Start Guide
Trial and error the only way?
No, reading and seeing what other has done also provides clues.
Many sub groups specific to Nextion application (DCC++ trains, CNC, MMDVM, Radio)
Now I have explained much in this forum in a tribal manner, and what I found was most of the users are of a highly intelligent species. And going too far into detailing "specs" is viewed as just plain insult to their intelligence. As such there is no need to super document every detail. It could also be viewed as insulting to detail too much as if they couldn't figure out how a progress bar handles a stretched 0 to 100 range, implying they may not have the required mental facilities to handle the programming logic they need to program their MCU. All of which would be moot when such a lack of logic fries all when electronic calculations are incoherent and were just plain wrong - if such were actually to be true.
Most come from the old school embedded world where it is super common and down right expected that one has the prerequisite electronics knowledge, the prerequisite programming skills. In such embedded world that they come from, it is the users domain to read the materials at hand and research. Reading the 1479 page MCU manual is not only ordinary, it is expected.
Now Nextion doesn't come with such expected 1479 page manual as it is not open source, it is closed source - much like your tablet also doesn't come with such spec details. The essential electronic details are in the datasheet for the Nextion Model you have, also found on the Nextion HMI Solutions page links found by selecting Help Menu Item under the Nextion Editor Help Menu.
Nextion Questions and support - Nextion Forum
Compiler and programming language support - usually your Compiler Forum
I can provide fair help or knowledge, but not all.
Somethings still remain within the users domain
I love explaining, perhaps too much so. And I expected there was some background experience when you asked for the "specs" of.
So if you have questions - I certainly don't mind answering. At version v0.44, still a few things are fluid, specs could change rapidly as new features are included. There is no usual 1479 page manual, partly due to it being at a lower version, partly because source is closed. But lets be a bit more clear why there are many "interpreters" being created.
The Nextion is driven by a Cortex M0 MCU on the basic models, 8K SRAM and 64K Flash, the enhanced models are Cortex M3 20K SRAM and 128K Flash. This space is shared between "The Firmware" and the user HMI design. The size of the SPI Flash is model dependent (even custom). So having the ability to preload resources Nextion side of a slow 115200 baud RX/TX pair is beneficial. The Nextion is a few commands to shortcut some work, and a series of attributes.
But one first has to understand and come to grips with embedded. These interpreters are being created to put square pegs in round holes. The Nextion is not a tablet, or a computer system - it is a display with an embedded MCU. Much overcomplicating of the situation trying to think of it in a scope that it is not leads to people writing translators in the means they are thinking, rather than adjusting their understandings of. .Net people are expecting this and that, Driod peoples expect something else again. PIC, STM, ESP users seem to get it when their understand is aligned with the fact you are dealing with an embedded MCU.
But really, I am not sure that I ever saw Microsoft Visual platforms have a "spec" for a progress bar. Progress is 0% to 100%. Ours can be set horizontal or vertical but not diagonal or fourth dimensional. As a two dimensional item on a canvas it has an .x and .y attribute that marks starting position and a .h and .w attribute to define its size. It comes equipped with the a .val attribute that is for a 0 to 100 range to represent percent. Now like many progress bars, it carries a few bells and whistles. Two color using an .sta of solid color paints the background with the color in the .bco field and the progress is colored by the color of the .pco field. This gives the look of an old DOS or Windows 3.1 program. Using an .sta of image uses two picture resources bpic for background and ppic provides the progress overlay.
But a progress bar has been a progress bar for three decades now. So why must an interpreter be created for such a simple component. But now that I have probably over explained things, you too probably feel it is an insult of your intellegence
and just to make it a bit more clear and simple ... :-)
All Nextion-Object Screen-Units are defined in Pixel.
In digital imaging, a pixel is a physical point in a raster image, or the smallest addressable element in an all points addressable display device;
so it is the smallest controllable element of a picture represented on
the screen. The address of a pixel corresponds to its physical coordinates.
Very important, this physical coordinates do start with 0,0 at the topleft corner of your system in contrary to a normal mathematical coordinates system, where 0,0 is normally located at downleft corner.
Still to clarify ... :-)
- what's an address
- what's a raster image
- what are coordinates
"there are those here that will aid others to get over their hurdles."
Thought so, until today.
So what is your actual hurdle?
So far you haven't presented a hurdle
Perhaps you are stuck at your concept.
Creating a Nextion Page Component provides you with a blank canvas. And now you as the artist, it is up to you what you want to do with this blank canvas.
HMI is Human Machine Interfacing, so generally the display is used to gather user input and output status back to the user. This is very dependent on what someone's needs are - and then very different how each artist realizes their interaction from the user (via display components) to the machine (MCU and what the MCU now controls).
As there is a graphical aspect, the same project could be realized in 100's of different "artistic designs" ranging from not so visually appealing (but functional) to masterpieces that should be in an art gallery. But most are first concerned with making it functional. Functional to what? That requires you to define what you need as input and status from your machine. Then how you want to present this to your user.
The MCU is an interface between the Nextion and other electronic components, and usually is in control of the logistics on the electronic side. As such the type of MCU used in your project is up to you, usually chosen to fit the needs of your project. For many projects, a small MCU may be sufficient, for others a large MCU may be necessary. MCUs variety ranges to 1000's of various MCUs of wide ranging specifications in use with Nextion. The tools used to program these MCUs are just as ranging, to include 100's of programming languages, all with their own selection of compiler vendors and vendor specific interpretations of "the programming language" implemented by their compiler.
As an example, in the Pascal programming language, there is a wide enough variation in the "language" implementations between vendors for ARM MCUs such as mikroPascal, to TurboPascal for x86 architectures, to Kylix on an Edison MCU, or FreePascal.
To further add to available options, each compiler/language combo also has various "Libraries" specific to the compiler and MCU. Any user code can be considered as a library in its reusable nature to speed the development of future applications. So you may indeed find multiple libraries available for a given language and compiler for any MCU architectures - MCU family inclusive to chip specific.
But this is beyond the scope of Nextion, other than for Nextion to provide a simple common interface that serves the need for all these variations. For this Nextion chose a two wire 3.3V/5VT TTL implementation of a basic RX/TX UART. Simply push the needed characters/bytes across the wire and receive the bytes. For this you have the Nextion Instruction Set, and note the triple 0xFF bytes needed to terminate data in both directions. The Instruction Set is in human readable lower case ASCII. The elements of your HMI design are stored display side of the RX/TX pair for speed over slow 115200 bps data lines. So this means that part need not clog your limited MCU with resources like Fonts and Pictures.
As far as the Nextion Instruction Set goes these are limited text based shortcuts, sent over serial. But as with any programming logic, ordered in a crafty way produces amazing results.
and the Nextion Editor is not away from general standard definitions ...
this is public available information, people only must search and read for ...
there is really no need to publish all double and triple ...
if people don't like to search and read on their own, it won't make a difference where the information is posted ...
they just wont search and read ...
Wikipedia is a public service, it is neither hidden nor cryptic nor in a language you won't understand ...
so, what is the reason that people still don't read ...
sorry, but it is not our task to search and read such general articles for you ... and we also won't publish such basic general articles ...
Thinking on your follow-up regarding users and interpreters:
The examples I gave were from users experienced in programming and electronics that see more value in engineering software without having to go back and forth with the technician to see if something works this way or that way. Many users are creating their own "interpreters" just to make the displays work with their programs.
Continuing on from where I left off in the vastness and variety of MCUs in play:
A Human Machine Interface is generally specific to the project hardware. There certainly isn't a "one size fits all" approach. Further to the speech about how many MCUs, compilers, languages and libraries - even if a few programmers managed to somehow use the same number of components in the HMI design, their artistic flare would make the requirements of the MCU code different. This programming artistic license means two variables used for the same purpose could be called by two separate .objname 's, or could be ordered differently on their canvases. This means that their MCU code would be different to manipulate this variable in their respective MCU side code (as well as any Nextion Side logic). The order of the components on their canvas has meaning when it comes to the Nextion HMI, as Nextion sends out its Touch Return Data based on this (see Nextion Instruction Set).
So two users with a variable to hold a "press count" and using Arduino C++ as the programming language and the IteadLib for this example, User A has called his variable "presses", and user B has called his "count". User A''s page is called the default "page0", and User B renamed his page to "mainpage", UserA's variable was the first component added to the canvas, while User B's variable was added last and has an .id of 14. User B also had foresight to make his variable global for his needs, User A did not.
User A defines his variable
NexVariable NumPresses = NexVariable(0,1,"presses");
User B defines his variable
NexVariable CounterA = NexVariable(0,14,"mainpage.count");
User A accesses his Nextion side variable with NumPresses.getValue(&number) and NumPresses.setValue(number), but this only works for userA's design when the HMI user is on the correct page - User A has chosen to track the current page with the sendme command. User A also had his variable as default numeric while User B has his defined as a string - which further adds differences to their programming. User B accesses his String variable with CounterA.getText(&buffer) and CounterA.setText(buffer) - but doesn't need to be concerned with sendme as his is global. Every difference in the design of the user's HMI project changes how the limited MCU is to deal with the user specific design.
So if you were referring to "interpreters" for their "programs", this is not actually an "interpreter", but it is perhaps the programming required to tell their running Nextion HMI design they would like to get or set a value in their individual respective and unique HMI designs. Try and see if you can get 100 programmers to do something in an exactly the same manner - my bet is that you would be lucky if two were duplicates - and then only because the one had copied the other without doing the work.
Also, still trying to figure out your questions and hurdle
Much of all of this you should already know and be fully aware of. The month you spent picking Michael's library apart should have given you deep insight into what the MCU needs to send to work with the Nextion and what the Nextion sends to work with the MCU. So if in that month or the following month you also played with Nextion Editor, you would pretty much know all that the Nextion HMI is capable of. You didn't disclose then what you were working towards, you haven't disclosed anything in your vagueness now. So it is pretty hard to be a mind reader.
I'll take a guess. Perhaps you are having difficulties with a group that is using the Nextions and they are always running to you for help, in which case - they could present their hurdles here themselves. No matter how much you or I read, it doesn't increase their understandings - they have to read, user domain. Help -> Help takes them to the Nextion HMI Solutions page, and they should really go through the Nextion Editor Quick Start Guide and the Nextion Instruction Set. After that, the artistic license kicks in, each has to implement their very unique designs - requiring different approaches and code. You probably can't dictate the logic to the group.
And if my guess is wrong, well, you'll have to tell more when presenting your questions and hurdles. As stated earlier, the Nextion is closed source - and as such, such documents do not exist.