Start a new topic
Solved

Touch screen issues

Hello!


Just wanted to bring two things to your attention, not sure if these issues have been sorted out yet, if so please point me in the right direction!


Firstly, if i add any code in my arduino loop code, the touch screen function almost completely disappears.


E.g


Read analog signal ----> send value to display


If i simply add that code into my loop it barely ever picks up a touch event.


Secondly, i cant increase my baud rate above 19200 without also losing the touch event.


It works perfectly running @ a baud rate of 115200, with multiple analog signals being measured and displayed onto the display (4.3"), including graphs!


Just no touch function!


Thanks!


This is a user mcu side coding issue on strategizing use of loop() to allow sufficient time to ensure the efficient running of nexLoop and Arduino serialEvent (implicit or explicit).  When user code is sequentially processed line by line, 

a) either some code segments are taking way too long such that incoming data becomes lost, or

b) the loop() code is running unbridled unconditionally and overloading serials preventing incoming data from being received or causing serial buffers to overflow.


In such cases users need to restructure their code so this does not occur.

Touch events can only be received and processed by your MCU when your code allows for such.


As bytes are received in nexLoop() and serialEvent, this means that the loop runtime should be short enough to reach the end of loop() and likewise nexLoop() before the serial buffer has be filled.


You have the means to investigate such will debugging techniques using a loop counter, microSeconds(), millis(), and Serial.print.  A loop counter when nothing is occurring should be well able to hit above 100,000 loop iterations per second.


1 person likes this

Thanks a lot for the quick reply!! I think i understand what you getting at, im just not sure how to go around solving my issue in my code then. From my understanding my issue is B) from your reply! I just learnt that putting in a 50ms delay with multiple text commands makes the touch screen work okay-ish, obviously with longer delay it works great! But i cannot have such slow update rates to my screen :/ Do you possibly have a better solution other than using a delay.


And then im also still stuck with the baudrate frequency, i have no idea how to get the touch event to work with a baudrate above 19200. Even only using a touch event in my code i.e get touch event ---> update text.


******************************************************************************

#include <Wire.h>

#include "Nextion.h"

#include <SoftwareSerial.h>

NexButton b1 = NexButton(0, 6, "b1");

NexTouch *nex_listen_list[] =

{

    &b1,

    NULL

};

NexText t0 = NexText(0, 1, "t0");

NexText t1 = NexText(0, 10, "t1");

NexText t2 = NexText(0, 11, "t2");

NexText t3 = NexText(0, 12, "t3");

NexText t4 = NexText(0, 13, "t4");

NexText t5 = NexText(0, 18, "t5");

NexText t6 = NexText(0, 19, "t6");

NexText t7 = NexText(0, 20, "t7");

NexText t8 = NexText(0, 21, "t8");

void setup()

{

  nexInit();

  b1.attachPop(b1PopCallback, &b1);

}

void loop()

{

  nexLoop(nex_listen_list);

  t1.setText("greetings");     // Usually analog signal being read and sent

  t2.setText("greetings");     // Usually analog signal being read and sent

  t3.setText("greetings");     // Usually analog signal being read and sent

  t4.setText("greetings");     // Usually analog signal being read and sent

  t5.setText("greetings");     // Usually analog signal being read and sent

  t6.setText("greetings");     // Usually analog signal being read and sent

  t7.setText("greetings");     // Usually analog signal being read and sent

  t8.setText("greetings");     // Usually analog signal being read and sent

 

  delay(50);                       //Using this delay makes the touch event work fine

}

void b1PopCallback(void *ptr)

{

    t0.setText("hello");

    delay(1000);

    t0.setText("bye");

}


*******************************************************************


The code above that im using for testing is as simple as it gets for me lol 


********************************************************************

#include <Wire.h>

#include "Nextion.h"

#include <SoftwareSerial.h>

NexButton b1 = NexButton(0, 6, "b1");

NexTouch *nex_listen_list[] =

{

    &b1,

    NULL

};

NexText t0 = NexText(0, 1, "t0");

void setup()

{

  nexInit();

  b1.attachPop(b1PopCallback, &b1);

}

void loop()

{

  nexLoop(nex_listen_list);

  delay(100);

}

void b1PopCallback(void *ptr)

{

    t0.setText("hello");

    delay(1000);

    t0.setText("bye");

}


************************************************************************

The code above is what i use to test the touch function at different baudrates.


I really hope im just being dumb and missing something!


Thanks again!

ok look at loop() code  

void loop()
{ 
  nexLoop(nex_listen_list);
  t1.setText("greetings");     
  t2.setText("greetings");    
  t3.setText("greetings");    
  t4.setText("greetings"); 
  t5.setText("greetings");
  t6.setText("greetings");
  t7.setText("greetings");
  t8.setText("greetings");
  delay(50); 
}

This is what I call unbridled unconditionally sending every loop() iteration.

   parses out to t1.txt="greetings"ÿÿÿ  21 bytes at baudrate ... 210-bits

Sent eight times from t1 to t8 ... 1680 bits out of 9600bps. (assumed as default)

These eight take 175ms to do with a 50ms delay ...

  before bytes from end of loop() bytes on line is read into buffer

This is 225ms roughly per loop, and then start over again at top where

  nexLoop() can once again try to collect bytes and process from buffer.


Now try to realize that an idle loop() should be in the 100,000s iterations/sec

You have this sending unconditionally unbridled every single loop iteration.

(Comparison is 1680 bytes at 115200 is ~15ms + 50ms delay = ~65ms per loop)


Now what does delay(100); actually mean to a sequential single threaded code?

It means stand on this spot (code line) and do not move until time has elapsed.

Every delay you are using HALTS your code in place like a pause button.

And is only released when the time is up then a resume button.


Your code (example code) only listens for the b1 release Nextion side.

This is processed on loop() line nexLoop(nex_listen_list);

 - sends the corresponding 0x65 0x00 0x6 0x00 0xFF 0xFF 0xFF to your MCU.

 - Where touch::iterate triggers your callback function

 (This is conditional and only triggered in a loop if and when it occurs).


Your touch event as shown above

  sends more text  t0.txt="hello"ÿÿÿ 170-bits

  delay(1000); halting the code for another 1000ms

     (1000ms at 115200bps, up to 11520 bytes can go by ... or even bye-bye);

  and sends out t0.txt="bye"ÿÿÿ for another 150 bits

before going back to nexLoop() where it can continue.


Using delay in code is most often a design flaw

  - you are not really looking for code to halt.

such delays fall into category A - code segment takes too long.


The sending out in loop() is category B - unbridled unconditional.

If loop had something like

   if myFlag == 1 then {

     send out

     myFlag = 0;

   }

then this would be conditional, only occurring when myFlag is set to 1 then cleared.

 

So your example above

  sends out every loop regardless of what occurs

  this perhaps should only be on a condition



 


uint32_t now;

void setup() {
  now = millis();
}

void loop(void) {
   nexLoop(nex_listen_list);
   if (millis() > (now+1000)) {
      t1.setText("greetings");
      t2.setText("greetings");
      t3.setText("greetings");
      now = millis();
  }
}
The above keeps track or milliseconds passed.
 - sets now at start
 - loop to send only enters when 1000 such ms have elapsed
 - sets at the end of sending a new marker
 - will not trigger for another 1000ms after the new marker
   (note: time to send is not included, so NOT a 1s timer replacement)
This is conditional and not unbridled
Test with this kind of methodology and see performance increase


You, are a flipping champion!! Thank you so much!! Really helped a lot, and thank you for taking so much time out to explain it! Really really appreciated!!


Im sorry but im still stuck on the baudrate lol I honestly have no idea how make the touch event work with baudrate higher than 19200. At 19200 it works perfectly now. When trying 57600 or higher it doesnt work >><<. 19200 baudrate works perfectly fine for just updating text, my issue is when it comes to the graphs, it just updates way to slow even at 57600 baudrate. 115200 baudrate works amazingly for the graphing! Sorry I should have given some background, im using this device to read sensors from my car (pressure, egt, afr, etc). The graphing capabilities from nextion are just too amazing!!! So so simple!

What MCU are you using, baudrate may be a limit of

Currently the arduino micro, with 4.3" display.


It displays text and graphs etc perfectly at 115200, just no touch event picked up.

Steps for touch events


HMI side Send Component ID

    Checking Send Component ID  checkbox in Touch Press Event

     - this will require an .attachPush assignment in setup()

    Checking Send Component ID  checkbox in Touch Release Event

     - this will require an .attachPop assignment in setup()


Arduino side code


-   Component used to touch press/released declared at top of script

    // NexComponent mcuside = NexComponent(pageno, comp.id, ".objname");

    NexButton  pg1b2 = NexButton(1,14,"b2");


-   Component must be in nex_listen_list[] for touch to be caught, NULL end.

    NexTouch * nex_listen_list[] = {

      &pg1b2, NULL

    }


-   Component needs .attachPush or .attachPop in setup();

    pg1b2.attachPush(myfunc_onb2Press, &pg1b2);

    pg1b2.attachPop(myfunc_onb2Release, &pg1b2);


-   functions introduced in .attach need to be made


    void myfunc_onb2Press (void * ptr) {

    }

    void myfunc_onb2Release (void * ptr) {

    }


- last nexLoop() must be in loop()

   nexLoop(nex_listen_list);


Beaware of

   when reference and dereference is needed

   component pageno and id is accurate matching HMI componnent

   all steps listed here are ensured to have been taken

   loop is not overloaded and time allows for incoming


IF a press/release event is going to take a long time

  send a status to HMI on start of function to show busy

  send a status to HMI on end of function to show finished

Perhaps the user needs to wait and not press right now.

  nothing wrong, just coordinate such


But if loop is NOT unbridled - then touch should be coming through flawless

  comment out lines with //

  test to see where your loop is bogging down

Put all your touch events in as shown above with simple .setTexts or .setValues used

  you should be able to see that without other things happening, touch is almost flawless


 

Thank you VERY much!! I will give it a go and report back!

Actually thats exaclty how i have the code. And the code definitely works as the touch event is registered with baudrates 9600 and 19200. 



if (millis() > (now+1000)) --->>> I can increase that 1000 value as much as i like, it doesnt make a difference. Still no touch even registered.

can you provide HMI and ino?

I will do so tomorrow evening if thats ok. I used the hardware ports on my mega, and the touch event works perfectly at 115200 bauds. So now im bummed, means it has to do with software serial. Ive already designed and ordered the pcb based on the uno chip for my nextion device. If i cant get the touch event to work at 115200 bauds with software serial,  then my whole pcb design is a flop lol


To make things easier now, the issue is just with software serial, and receiving a touch event above 19200 baud rate.

Ahhh, the fat lady hasn't sung yet, just might need a more detail look at.


1 person likes this

So once the design is debugged, what would be wrong with using the hardware serial for Nextion?

What design? Also ive just followed the sheep, going to do some research now as to why people dont use the hardware port on the uno.

Login or Signup to post a comment