I'm trying to implement an simple timer that would create from a epoch time number (seconds) a time like "hh:mm:ss" which would be easy in any proper programming language, but this is the closest I got with the Nextion skrip "drabble"
hh.val=dt.val/3600 // <-- missing "% 23"
mm.val=dt.val/60 // <-- missing "% 60"
ss.val=dt.val // <-- missing % 60
I need lots of dummy variables and am still missing the modul operator.
That must be new, since back then I tried % and it produced an error.
Good to know tho'
I'm also surprised that you can now use negative values. Back then the numeric values were uint32_t.
But I think your question is a general C "issue" (or better expected behaviour)
Glad to see modulo, just put a timer routine together without it. Yet to test it.
I'll be damned. Well, that will save some time and lines. Thanks for the find.
The behavior of the modulo operator is indeed as designed. The workaround for the missing abs function is to test if the value is less then zero and if so multiply with -1.
To use the modulo function to split an integer into two parts and show them in separate number fields is not optimal: -27 ends up as 0.27 instead of -0.27 as the sign information get lost when the result of the division is 0.
I attached a simple demo which uses a text field. Please note the use of a timer as a subroutine and updater.
With the commands:
You can update the display remotely.
I think that a onChange event would be a handy feature for a variable :)
Ahh ... hence the modulo result is not dependable in all cases ... and thus undocumented
The modulo operator behaves like expected so I think that the reason for an undocumented modulo operator is the lack of any documentation regarding operators. Itead really should get their documentation right. That it only work with positive numbers in combination with the Number component is not the reason it shouldn’t be used. You can use it with negative numbers with a Text component as I show in my example. I use the % operator in combination with the prinf function to format integers, only now I realize that this doesn’t work for negative numbers smaller then the divider.
Your response brought me on the idea of an enhancement for the Number component.
When the lenth property is more then zero the number is padded with leading zero’s if shorter then the lenth property.
So with a sign override property that forces a negative sign if a negative number is stored this should work:
va0.val=-2 n0.sign=va0.val // force the sign to negative is number is negative n0.val=abs va0.val/100 n1.lenth=2 n1.val=abs va0.val%100
n0 would show -0 and n1 would show 02
Another enhancement would be a fake decimal point position and a decimal point character so that -2 could be shown as -0.02.
O, and number formatting like: hh:mm:ss :)
The options are endless :)
I think the main reason it is undocumented is that iTead has a hardware focus and a great service for custom PCB boards, with supporting software implementations not within their mandate (stated in FAQs). So a command that doesn't function 100% of the time, is less support complaints but leaving it as undocumented and therefore not supported, or the expectation of support.
The options are endless, but the resources on that tiny little STM32F030C8T6 is not. I think that a lot boils down to providing a skeleton of functions while still leaving room to implement an HMI design. Could fill it completely with libraries and no room to run the code, but choices have to be made what to keep. Most people connecting a Raspberry Pi with an SD card and better processor will perform the subroutines on their host and upload results to the Nextion. And again, as programmers, endless options and paths to arrive at the same result.
I already posted with picture in the other thread here I am spoiled with the King of MCUs that is just smaller than the Nextion 2.4". But I hear you, there is a good MCU on board that should be able to handle additional tasks. 32K/16M is tight, depending on the task to be accomplished.
The Edison has an additional single threaded RTOS mcu running at 100MHz and 384k ram (Good for gpio controls) but is limited to mailbox communications and doesn't share the main system's vast resources. I do like the Edison in that I get to program Intel based code in my favorite pascal Kylix 3 compiler with all the enterprise libraries .. all is possible. Basically a server from 10 years ago now the size of a postage stamp. It is all 1.8V logic, and I do like the fact it can run on a 3.7V lipo out of the box.
If "software implementations" are not their mandate then open sourcing would be a way to go.
There are lots of people that would like to and were capable to make that device shine, but ITEAD seems not open to that nor to hardware suggestions made by users.
e.g. while you could do some heavy processing off board there is no way to put that power on screen since there is no fast access to the actual screen buffer.
You can have an SD with a load of images but you have no fast way of uploading them.
I mentioned "software implementations" loosely in that the support is limited to ensuring the hardware is functioning and that there is no support around programming and or debug user code. As per the FAQ.
They do have a private interest in implementing "hardware suggestions made by users" by going through their custom PCBs, with a minimum quantity of 5. :) There is no fast access to the screen buffer ... unless you were to modify it and tie into it directly. But by the time you go through all that effort, you are three quarters to building one exactly the way you dreamed it could be in the first place.
So in all the people that wanted it as an open source project, how far along is that? Words or action?
If there were an open source repo for the firmware and/or Nextion Editor then PRs would follow.
The potential would be there to let actions follow the words!
BTW, I think to remember more than five people (when I come to think even I alone own more than five of these displays ;-) ) ask for access to the SD card (but not just the way that's now available for the enhanced displays) - e.g. by exposing the SPI port pins.
Which then would also open a faster route of communication and maybe a way to shoehorn data into the display buffer - but now I'm getting too fatuous, sorry.