Only receiving first byte of response

[DaanTheoden]

Context

• Microcontroller: DOIT ESP32 DEVKIT V1
• IDE: Arduino 1.8.19
• Baud: 9600
• Configuration: SWSERIAL_8N2

Issue Description

I am trying to send and receive bytes to control a 3rd party device from my ESP32. Sending data works well and the 3rd party device actuates accordingly. However, when trying to receive data, only the first (ACK) bit is returned, but all other response data is ignored.

Relevant Code In order to receive data, the lib's built-in receive handler is used. On setup: mySerial.onReceive(receiveFunc); During loop routine: mySerial.perform_work(); The receiveFunc():

void receiveFunc(int packetSize) {
  if (packetSize == 0)
  {
    return;         
  }
  else
  {
    Serial.print(mySerial.read(), HEX);
    Serial.println();
  }
}

What I Have Tried

• Using the lib's overflow() function to prevent 'stop receiving'
• Forcing the above by replacing all m_overflow = true occurences to m_overflow = false in the lib
• Commenting out all optimistic_yield(10000UL); occurrences to prevent receive timeout
• Not using the lib's receive handler but trying available() and peek() according to documentation
• Passing a buffer into int SoftwareSerial::read(uint8_t* buffer, size_t size) and printing each value

Unfortunately, all of the experiments resulted in the exact same situation. The first response byte is received and then no bytes seem to be available even though we have validated that these were correctly sent from the 3rd party hardware. Is there any method to force the library to keep reading the rX pin without flushing, timeouts, skipping etc.?

Thank you and all the best,

Daan

[avillacis]

@DaanTheoden What version of EspSoftwareSerial did you use in your tests?

I have just reported a regression: https://github.com/plerup/espsoftwareserial/issues/257 . In my case, I use ESP32S2, and version 6.16.1 fails to communicate with my Modbus devices, but 6.15.2 works correctly. If you were using 6.16.x, please revert to 6.15.2 and test whether this fixes your issue. If it does, please report it at https://github.com/plerup/espsoftwareserial/issues/257 as well as here.

[DaanTheoden]

@avillacis Thank you for your response. I used 6.16.1.

I found a solution by initiating 2 SoftwareSerial objects and assigning a non-used pin as tX on the first and a non-used pin as rX on the second. I could then assign a different configuration to them seperately. In my setup routine I now have:

// INITIALIZING MDB SERIALS
mySerial.begin(9600, SWSERIAL_8S1, rX, notConnected1, false);
mySerial2.begin(9600, SWSERIAL_8N2, notConnected2, tX, false);

All the best,

Daan

[dok-net]

@DaanTheoden What makes you use a mix of 8S1 and 8N2? What makes you think using two separate EspSoftwareSerial objects is any different from using a single one? What happens if you don't use the callback method, but poll the SoftwareSerial object in your loop()?

[DaanTheoden]

@DaanTheoden What makes you use a mix of 8S1 and 8N2? What makes you think using two separate EspSoftwareSerial objects is any different from using a single one? What happens if you don't use the callback method, but poll the SoftwareSerial object in your loop()?

It should work with 8N2 using a single object but somehow it does not. By trial and error I came to this solution.

Using the object in loop with, for example, available() and then a read()made no difference.

[dok-net]

@DaanTheoden I'm revisiting your issue report. Is this a duplex communication where the external device is transmitting concurrently to the ESP32? That is prone to fail with SW serial. Most importantly, you must enable interrupts during Tx (enableIntTx()). The use of mixed parity modes still looks suspicious to me. I don't think there is any defect in EspSoftwareSerial behind your problems, though.

[dok-net]

Is this issue stale?

[DaanTheoden]

@DaanTheoden I'm revisiting your issue report. Is this a duplex communication where the external device is transmitting concurrently to the ESP32? That is prone to fail with SW serial. Most importantly, you must enable interrupts during Tx (enableIntTx()). The use of mixed parity modes still looks suspicious to me. I don't think there is any defect in EspSoftwareSerial behind your problems, though.

Hello,

It is indeed a duplex construction with concurrent communication. However, the project is no longer in development so the issue can be closed.

All the best,