Maybe a disigning mistake of me, or didn't find the correct answer in the forum or samples... But behind the scenes:
I'm working on a stepper motor controller project. After finishing the project for a 4 x 20 LCD, I preferred to use a Nextion Enh. 5" TFT. My logic is, that I make first the whole GUI on Nextion, and the most of logic is placed inside the Nextion. It's ready. My Arduino (Mega) has practically nothing to do, as to control the stepper as the user over the GUI wishes. (f.e. rotate 72°). I wanted to build in the 3-4 "entry points" sending a string as a command to Arduino, and wait blocking the GUI -maybe a progress bar or any informations over the state - until the processing succeded.
And here is my problem: Until the processing time in the Arduino's authority is ready, I have to "stop" the GUI on the Nextion. The easiest method seems to wait in a while loop until over the UART is a command received. But I'm unable to check the size of the buffer, even if any command or a special value is there.
(I don't find any UART related functions in the Nextion script.)
First made everything only over the Simulator...
My loop is in an event:
I tried to send the command
to interrupt the loop. It seems, that the commands are not executed (I know, it's no multithreading, but I hoped, that com_star and doevents are making, what I'm awaiting...)
Now my only solution until this time is
in the right place. If the controller is ready, send tsw 255,1 and ref_star.
But I'm interesting, is any better (maybe trivial) solution? (ref_stop is making unable to show a progress bar...)
P.S. I'm a newbie, sorry.
Redo on answer
- ref_star and ref_stop are useful only in Waveform during addt command
- tsw 255,0 and tsw 255,1 is not a bad means to accomplish
Question becomes for how much time is this done for
- the interpreted time to cycle through all components and enable/disable touch
is already in most cases more time than what you wish to block for
Consider that 115200 baud is 11520 bytes per sec
- we are speaking in milliseconds to prevent touch from occurring.
- rapid human touch is already beyond this ms interval before next occurs.
UART buffers on STM32 is 128 bytes, and near same or larger on Mega
As both are sequential processing and not multitasking
- any touch would be buffered for next sequential processing
One needs to study timings of - in many cases already overkill to prevent.
My goal is to give the user no possibility to make anything on the Nextion, as long the the stepper motor rotates to the next indexer position. This time is a wide range instervall depending on the number of steps/microsteps, etc. On the Arduino side I know the time definitely. I plan to make a nice progress bar for this time, if it takes longer as X (?) seconds.
To stop any user interaction, there are actually 4 components on the page to disable. I think, it will take not a lot of time, I can "tsw" them by id also.
I found in german from a Nextion distributor a very good instruction:
Here stands: "während sich das Programm in einer while-Schleife befindet, werden die Events nicht abgefragt"
=as long the program is in a while-cicle, are events not "fired".
It seems be logical in a single thread enviroment. Is it thru? (Should...)
My idea is (have actually no time to test), to make a timer f.e. with 100 msec and let fire as long, until a Nextion-variable "ready" is set from 0 to 1. Then I simple disable the timer, and enable the components disabled before.
From Arduino site under processing the rotation (in the loop) can be made the progress bar also visible and adjust the progress state. Because - I assume -, that the timer is fired from the "main Nextion loop", are commands coming over UART also processed.
It seems to be a little complicated... What is Your opinion? (My problem: Waiting on the Nextion site - which "masters" the progress - seems to be a basic requirement, which would be already solved in an elegant way, but "my solution /?/" is not a nice one.)
To go a step - not in a physical manner - forward, would be enough to have a function, giving back the number of bytes waiting in the incoming buffer or let proceed them from inside a loop.
Maybe no sense, but if I not ask...