Start a new topic

Another (light) Arduino library and some formatted printing helper

 Guys,


I would like to donate a tiny Nextion library for use on Arduinos I built from scratch for fun. It is by far not as capable as the "official" library, but it has a very small footprint.


The library has been developed and tested on both an Arduino Zero Pro and an Arduino Uno. It works on both, although 32bit handling of EEPROM values does not completely satisfy me on the Uno yet.


You are left to your own with it - I deny any responsibility for whatever you may do with it. It is all your fault :-)


A few words of documentation can be found in the NextionLightLib.h file. Additional insight may come from the example INO file I also attached. The demo will need the attached HMI file to work properly.


The Nextion Light Library and the demo INO both make heavy use of another small library: mini-printf, that is also attached. This library provides a very small implementation of the snprintf() function (named "mini_snprinf()") to write formatted text into char buffers. As an add-on, a "mini_uprintf()" variant is given, that is able to write formatted text to a Serial interface directly. 


Again no formal documentation exists - see the mini-printf.h file for some hints.


Have fun with it!



zip
zip
HMI
ino

3 people like this idea

I am missing the point I am afraid. The example you cited clearly shows high byte before low byte for x and y in the returned data and exactly that is what my code evaluates.
Told you I'm confused! :D Of course your code is correct. I'm just screwed up with the docs.

It screwed with my brain when Nextion switched the format from little-endian to big-indian. I had created a routine in my procedure to decode the l-e format in the buffer to an integer and was using that in the touch routine without thinking about it.

Nextion. Inconsistency is the word for it.

 

Michael, I'm stuck on the Nextion way of identifying a component with both an ID and a NAME.

The NAME is set by the user (with suggestion of type of component) and the ID is set by the Nextion.
ID is basically an integer, but isn't consistent when deleting components on the Nextion. Components after the deleted component get renamed.

NAME becomes a user defined string, but is unsuitable for small MCUs without robust string handling.

In your library code, you specify that the ID must be sent/set from the Nextion editor. (I see the checkbox. I had to read down into the code to find that, BTW.) It seems like the Nextion CLICK command doesn't send anything unless the editor checkbox is checked.

So, it seems that one needs to keep a synchronized list of component IDs and forget the more advantageous component NAME. Is this the conclusion that you came to?


I must be missing something.

NextionError Nextion::getClick(unsigned int *page, unsigned int *component, bool *event)
{
   NextionError rc = NXSUCCESS;

   rc = getTerminated();
   if(NXOK_TOUCH_EVENT==rc)
   {
      *page = rcvbuf[1];
      *component = rcvbuf[2];
      *event = rcvbuf[3];
   }
   return rc;
}

 

 

Within the Iteadlib (maybe an inspiration source) components were declared

    NexComponent myComponent = NexComponent(3,5,"page3.t0");

where 3,5 referred to the page with pageno 3 and component id of 5

and where the page3.t0 gave the text version of the component name


The Nextion Editor more or less requires text commands

   t0.val=32ÿÿÿ to be sent, or a global on non current page page3.t0=32ÿÿÿ

The components .setValue would parse this out and pass to sendCommand for the ÿÿÿ termination


Referring to the Nextion Touch Events 0x65 return codes

  0x65 0x03 0x05 0x01 0xFF 0xFF 0xFF used the 3,5 page,id parameters to build a listen list


Now getting to the click method,

   the Components hidden sendID attribute is only set by the component Checkbox in the Editor Event

When the touch press/release event occurs on the Nextion triggered the touch sensor

   the sendID is checked if set and therefore sends the 0x65 Return Codes

But when the touch press/release code is triggered by command, the 0x65 is not part of the function.


I do not see this as a bug, as a coded click m1,1 is not a touch event - thus no 0x65.


I am only referring to the IteadLib in that it may shed some light as to the workings of the Nextion.

Hi Paul,

you indeed have nailed a tiny gap there. At runtime on the MCU side, there is no way to determine the objname attribute that is needed for the serial commands from the component ID the click event will deliver. The obvious
print b[componentID].objname

 simply does not work, it results in a 0x1A error ("Invalid variable name"). Same applies to the (less obvious)

 

t0.id=99

 that yields a 0x1E error ("Assignment failed").


So for the time being I see no alternative to maintaining a list of component IDs and their objnames on the MCU side if you need the combination of both click event watching and dealing with the component clicked afterwards. At least the component IDs do not change any more when you deployed the TFT, the re-ordering only happens in the editor.



 

Oh, by the way: what you _can_ do, is simulating the click event yourself in the touch event on the Nextion side. If you do a

 

printh 65 02 99 01 FF FF FF

 _without_ selecting the click transmission option in the editor, you can signal a click with an ID you predetermined - here 0x99. You will have to add that to any component where you need to react on clicks, though.

 

Now if the Nextion had a command that sent the list of ID vs. NAME, I could look up one from the other. Even that wouldn't make it easy. So, I guess I'll do it the hard way and keep chipping at the big rock with the little rock.

So for the time being I see no alternative to maintaining a list of component IDs and their objnames on the MCU side if you need the combination of both click event watching and dealing with the component clicked afterwards.

 

 

Hi Patrick, I am registered now over at the new forum ;-)
Login or Signup to post a comment