I have an nextion "Variable" and y want use it like a flag register (bit0=state1,bit2=state2, ... )
So y need binary operatiors like :
myVariable.val=myVariable.val and 4
myVariable.val=myVariable & 0b0100
myVariable.val=myVariable.val or 4
myVariable.val=myVariable | 0b0100
How can y do this ? Waht are the good syntaxes ?
I do not believe that it has been implemented into the instruction set on the Displays.
Currently This would be a function needed to be done via your MCU
I am now reviewing all of the Feature Requests, this will take some time, patience please.
This has not yet been implemented, but will be represented
I certainly agree that this would be a useful feature, and hence why I will be representing it.
However, for dealing with bits, there are various means to work with it, some techniques you may find interesting. To create multiple variables is not as much of a pain as you make it out to be.
If I have 30 status bits, performing power-clicking 30 times isn't too hard.
However some explanation of some techniques can help
If these 30 variables are sequentially created and their .id numbers remain sequential, then you can save a bunch on serial bandwidth by sending all 30 bits in a single uint32_t bitvals.val=flags where flags is your 32-bit number. Unpacking this to your 30 sequentially .id ordered variables is easy where the # is replaced by the starting number of your variables
This can be bypassed all together if you each bit is represented by 2 pictures on/off and your picture .ids are sequentially ordered where the # is replaced by the starting number of your pictures and doesn't require variables to be created at all.
b[sys0+#].pic=3 // where picture #3 is for on
b[sys0+#].pic=17 // where picture #3 is for off
Likewise on your MCU side, if you have an array of 30 bytes containing 1 or 0
NexVariable bitflags = NexVariable(0,37,"page0.bitvals");
The result is up to 25 bytes being sent over serial for the entire 30 bits
Further efficiencies can possibly be found in your MCU documentation.
If you have an ARM based Cortex MCU, bit aliasing will allow you to declare your 30 bits in one 32 bit variable as a volatile absolute and allow you to use the upper aliased addresses for working on each bit but read or write your entire bit array from that one single variable.
Things that become very inefficient most often is a result of not looking for efficiencies.
thanks for your detailed reply, it is interesting and useful.
1. You state: “To create multiple variables is not as much of a pain as you make it out to be.”
I did not imply that creating a lot of variables would be a pain I only said it would be inefficient, can you tell me where I said it was a pain? You the proceed to give an example of 30 bits, I have in the past done jobs using thousands of alarm and status indications passing between PLCs and HMIs, and SCADAs.
I agree that clicking on the variable in the toolbox isn’t too hard and I can manage it thanks.
2. You state: “The result is up to 25 bytes being sent over serial for the entire 30 bits” and “Things that become very inefficient most often is a result of not looking for efficiencies.”
I am sorry but 25 bytes being transferred for 30 bits, is not efficient 4 bytes for 30 bits is
I was simply trying to suggest useful features that real HMI units have, not with the expectation that they may be adopted, just to point out in real world applications this sort of facility is useful. After all the device is marked as an HMI solution, so itead should welcome suggestions from HMI users.
HMI, in its simplest terms, includes any device or software that allows you to interact with a machine.
This can be as simple and ubiquitous as the traditional single-touch display mounted on a machine or as technologically advanced as a multi-touch-enabled control panel or even connected mobile technology such as smartphones and smartwatches.
HMI is considered an interface that allows humans to interact with the machine.
Examples of HMI physical aspects could be a machine with touch display, a push button, a mobile device, or a computer with a keypad.
But in any case, HMI represents an Interface to a machine and NOT the machine itself.
It makes not a lot sense to discuss, what shell be included inside such an Inteface per se because different people have different understanding and needs. But machine and task logic should stay on the machine and not on the Interface.
There are surely solutions out which also offers much more than such plain Interfacing, many with even a whole integrated process unit. But to be fair, such solutions are also far away from the price you can buy a Nextion solution.
And not to forget, efficiency is no meassurement for a fixed method, efficiecy is always linked to a given task and comparison.
In the spirit of discussion. Pain implied, Inefficiency results in a pain for someone.
The Nextion Forum has but 5 Categories.
Announcements - from the company and staff
The Gallery - where users can showcase techniques and finished works
Free Chat - open ended discussions
Report A Bug - something went wrong
Feature Requests - something is missing.
Now, when someone posts in the latter two, it is because they can not attain a result they are looking for. So I will take that as the opportunity that if I have additional information that could be useful and assist a user get past their hurdle, I think that should be the right thing to do. Not just a speedy reply for your immediate issues, but also left as assistance for those that should follow later.
Without me having provided the b[ ] array method above, the application of variable for bits would be one by one, and some crazy long if else if ... statement. Not because of any lack of skills, but because there are no other means to access the components where a for or while loop can be applied. So, it is useful information and without such a most painful process indeed. It is possible you may have found the thread where the b[ ] was discovered, but it is long since buried under many other discussions.
Its efficiency is compared to what the task would have been prior to such information. 7 bytes at best for each bit one by one, across the 30 bit example 210 bytes over the serial, certainly not as good as 25, and no matter how much we can desire it, 4 bytes is merely - not possible on this system, making a 4 bytes discussion moot.
I too have had to deal with status bits, over 371,000 in one application (not on the Nextion and not on a single mcu). They can become very useful. Representing a couple of 1000 status bits is possible, however the Nextion is limited to 250 components per page, and it could more likely be passed by as less effective - but as Gerhard has pointed out, when linked to a given task - it depends on how the developer implements.
But a "real HMI" could be as simple series of physical buttons and leds or even a single button. If the human interaction with those cause the control of a machine, that is deemed an HMI by definition. So I believe you will find the Nextion more capable and configurable then just mere buttons. But I will also add that the Nextion is also capable of a game of Yahtzee, or a digital picture frame, and where no machine interaction is occurring, it would fall out of the HMI definition. This is entirely up to the developer if they are to implement the Nextion as an HMI.
And as for the suggestion, it is being represented - as stated previously - that has not changed.
Can't understand why some are so often negative about making the HMI side more powerful or smarter while this could really boost sales and widely increase the number of use cases. Actually, with the current script interpreter, I understand that one runs quickly into the limits of the Nextion display's MCU.
That's why I'd suggest moving over to a different approach, away from interpreting, but letting the WYSIWYG editor generate object macros which, with the help of a (hidden, since it included all Nextion production secrets) Nextion API library and toolchain would be compiled via gcc into a true hex file for that ARM A7 MCU. The callback functions such as touchPress(), touchRelease() would be pre-defined empty and compiled with the __weak__ attribute, so that the user code for the corresponding event would override these if present, and the user could write full C/C++ code, using the public and documented API calls for the Nextion specific functions, which would be compiled in a much more efficient manner and run much quicker.
As an example, see how Paul Stoffregen created a visual design tool (even online!) for the Audio library of the famous TEENSY processors : external non nextion link redacted by staff