Here's the debug code: void ICACHE_RAM_ATTR ESPeasySoftwareSerial::rxRead() { // Advance the starting point for the samples but compensate for the // initial delay which occurs before the interrupt is delivered pinMode(5, OUTPUT); // DEBUG digitalWrite(5, HIGH); // DEBUG unsigned long wait = m_bitTi...

I just found out (as in this evening) that the Message Delay setting is causing the sendData function to stall for about this time. That is interesting to hear. You cannot call the yield function from within the interrupt handler in the Software Serial routine. But you could do a call to yield when...

If the MQTT routines employ any service interrupts (or disable global interrupts) that take too much time then it would definitely impact software serial. What I have observed is that typical latency into the SoftSerial read function is about 10uS, which is great. At 9600baud, I expect it would stil...

@grovkillen, I'm not sure if you are directing your comments to me. But to offer some feedback, I've already experimented with the MQTT interval. Currently MQTT it is 75mS. I had tried 0mS and other values, none helped solve my problem. That was before I discovered that the problem was due to the in...

I wish I could help with the UART code, but at this point all I can do is cheer you on.
- Thomas

Hopefully you continue with your efforts and successfully get Nextion communication moved over to the hardware UART.

- Thomas

The ESP8266 UART features certainly have a lot of flexibility. But it's frustrating to find that the second UART is crippled (Tx only). Sure there are workarounds to this shortcoming, but two full UARTS would have been a more desirable implementation.

- Thomas

I agree, using hardware serial means disabling the debug and serial command processor. Then turn on the UART's Rx interrupt and point it to a Rx data buffer handler routine that Nextion can access. Seems easy, but "easy" coding is sometimes full of twists and turns. There's only one full h...

Using the hardware UART would be the holy grail.

@BertB * Just curious, is your Wemos using 160MHz CPU clock or the default 80MHz? * Thanks for pointing out that ser2net is using hardware UART. Too bad the existing Nextion Plugin does not support the UART as an optional implementation. If I get desperate I may take on the challenge, but so far my ...

Thanks for the link to the NextionMqtt code. It also uses Soft Serial. But its single purpose (Nextion->MQTT) avoids the Serial Rx corruption because it does not have any overhead interrupts to process. Simply changing ESP Easy to use Pins 13 RDX2 and 15 TDX2 won't solve the problem since it would c...

Is the entire data packet skewed, or only the first byte mangled? The ESP can corrupt any softserial character in the received string. That is to say, you could have zero, one, or more corrupted characters in the message sentence string. Due to the background interrupts (they're the culprit) the ch...

After some debugging I found the explanation to my ESP's corrupted Rx data. The Nextion<->ESP communication uses the ESPeasySoftwareSerial plugin which is an emulated UART. This function will sometimes produce corrupted serial data due to the ESP's background interrupts. The issue is random and only...

{Continued from previous post.}

Nextion Screenshots:

The ESP Easy's Nextion Plugin is ideal for my project. Thank you for creating it! Issue: My project is nearly done but I have one nagging issue to resolve. The problem is that the ESP is randomly corrupting the data packet message received from the Nextion display. The good news is that only RxD dat...