Nextion display missed display call backs

Firmware
1

Hi,

I am using a Nextion NX8048K070_011 touch display with Particle Argon. I am using this display to show some values and also used to toggle buttons from the display.
Currently, I am using the ITEAD Nextion library and the issue I am facing right now is that. When I am updating the display using Argon, I am not getting the callbacks triggered for the dual state button.

I have a long loop that takes up to a second to complete. So that I am using a software timer of 50 ms to call nexloop(). I am able to get callbacks for even the fastest toggles that I can to with my hand using the touch display. But while I am updating some values to display, these callbacks are not triggered.

I tried calling nexoop() manually before each update and still, it didn’t work.

2

Due to the nature of the Nextion communication the library is designed to unconditionally flush the RX buffer whenever a new command is sent to the device - potentially removing any already arrived feedback from the display.

You may want to reconsider/restructure this then.

3

Hi @ScruffR. Thanks for your time. But I have a complex task running in the loop already so I am afraid I can’t restructure that. This loop will normally take less than 100 ms to complete. But in case of some API calls it will take upto one second.

Another point is that I have tried inserting delays of more than a second like 3 second and 5 second in the program. Even if I specify these delays in the loop, the callbacks are still working fine as my timer is clearing the Nextion buffer every 50ms. But the only issue is while updating data and receiving callback at the same time.

The reason, as you suggested will be the auto flushing of Rx data. Is there some workaround I can adapt so that I won’t miss any of the callbacks.

I also tried directly reading from the button using a function inside the loop. But some times it is not giving the correct value. It is returning a high even if the button is low. And if I toggle some other button ( i have 16 dual-state buttons), some times many other button values suddenly changes and after a second or two they return to the correct reading. So this is not working as well.

4

Since I don't know which APIs that might be, are there any asynchronous versions of these APIs?
Can an FSM be used to break up the blocking loop()?

Delays would potentially cause the UX to rather become less responsive than help eleviate the issue itself.

How much and which data are you updating?
Updating on the display or somewhere else?

Without knowing the answers to the above questions it's hard to tell, but my first aproach would be to wrap the outgouing commands in a batch transfer with response disabled.

What button and how?

Have you considered offloading some logic onto the display itself?

Since this display seems to be an enhanced version, have you considered using any of the GPIOs?

5

. These are cloud API calls. Basically get requests and all. REST API.

I just wanted to imply that I tried with increased delays also just in case to know if making loops faster can solve this problem. But I found out that whatever the delay is the system worked fine on all the times except while updating. So I have a small hunch that making loops even faster will solve the problem. I don't know. But I think so. Any advice here is much appreciated.

The data is text fields. It's a history data it contains a start time relay number and duration. And we have 10 items in history. So 30 text fields are updated. I am updating the data on the display itself.

I am using a dual state button and used bt13.getValue(&dual_state); function to read data from the button.
This is my sample callback function

void bt4_callback(void *ptr)
{
    uint32_t dual_state;
    // NexDSButton *btn = (NexDSButton *)ptr;
    // memset(buffer, 0, sizeof(buffer));
    bt4.getValue(&dual_state);
    if (dual_state)
    {
        //log.info("Button 4 on");
        buttonVal[3] = true;
        Relay[3]->isToggledManually = true;
    }
    else
    {
        //log.info("Button 4 off");
        buttonVal[3] = false;
    }
}

The display is connected to Argon via UART and I am afraid that currently we only can support such a mode.

I didn't understand what you meant.

Hope this gave you some more insight into my problem.

6

At what baudrate are you talking with the display?
Have you tried 115200?

These displays feature a set of HW I/O pins you might be able to facilitate as a way to sync your code with the goings-on on the display.
e.g. set the pin HIGH in the touch event and LOW on release and on the Argon side wire this up with an interrupt that can "pause" the update to allow attending to the button press and then carry on when the data was collected.
Alternatively you could use that pin state as indicator that something has changed since last time and then request a status update of all buttons on the display.

There are plenty more possible strategies to mitigate your problems.

From that I'd deduce that they actually could be made asynchronous.

So potentially a lot of communication going back and forth for relatively little data. Which would well fit a batch transfer. But when you say historic data, does that by any chance mean you may be resending data that's already available on the display?
If so, this would be an ideal candidate for offloading management of already known data to the display.

7

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.