ESP32 Forum

Is it possible to receive information that data are waiting in module buffer and then read it?
Or data streamed together with commad is the only way?: I think that this form of binary data serving + problem with additional <CR><LF> before "+WS_DATA:" message that appears sometimes and sometimes not, forces additional code in the data reception routine, which reduces performance and prevents from making receive and parse routines completely independent.
1. We don't know if we are receiving command or data before parse occures. Commands are text and data are binary (in my case) so i use different buffers for commands and for data receiving. It would be better to know that data are waiting and read it by command - we could read and save data directly to data_buffer after put something like "READ_DATA" command.
So now, I have to parse begining of received command on-the-fly (in receiving routine) and switch buffer from command buffer to data buffer after detection of "+WS_DATA:" and length parameter.
2. Even worst, there is sometimes:
<CR><LF>+WS_DATA:x,data.....
and sometimes:
+WS_DATA:x,data.....
So if I want very simply check command buffer from position 0 using memcmp (that less reduce performance than strstr), i have to additionaly check if first character is <CR> or <LF> and ignore it, and this is next condition that have to check in receiving routine.

As it can be discussed if getting data by additional command also would reduce performance, simple change in "+WS_DATA" message could significantly improve the situation:
+WS_DATA:data_length,<CR><LF>data.....
Now we could parse "+WS_DATA:length," part natively in parse routine (command ended with <CR><LF> is natively transfered to parse routine) and then receive data to binary data_buffer.

The other issue is this additional <CR><LF> sometimes appears before "+WS_DATA....". Do You know about this or it is rather bug on my side?

@DexterM Hi, this response should not happen. The right format should be: If you do observe a <CR><LF> before +WS_DATA, then one of the following must be true:

• The <CR><LF> belongs to the end of the previous message and was not fully consumed or handled by the MCU side

• There is indeed an issue in the firmware. You can Enable AT Interface Function Debugging to verify this. If you prefer not to build the firmware yourself, you may also download the corresponding *-debug-at firmware for your target chip from GitHub Actions and use it for testing.

Thank You for response.
You are right with “The <CR><LF> belongs to the end of the previous message and was not fully consumed or handled by the MCU side”
I think this is the reason, that I missed: I didn't suspect that there is 0d 0a after data in +WS_DATA:
Thanks for help.

No worries~