ESP8266 - AT response termination specification (CR, LF, CR CR LF?)

Question

Hello Colleagues, My question concerns the specification of the ESP8266 modem responses sent to the microcontroller (USART, 115200bps). Does each modem response end with a pair of CR and LF characters, or could it be CR CR and LF or something else? I have written a simple function based on the...

Anonymous · Answer

simply the function does not work as you think, personally I think the error is in line 34 or 35. I don't know if my colleagues agree with me? Added after 31 [minutes]: I wonder why report me to the moderator. How without a code can you help?

robiw · Answer

. I will attach the code tomorrow...robiw

robiw · Answer

Variables: Code: C / C++Log in, to see the code . Function: Code: C / C++Log in, to see the code . Well it doesn't work properly, as I wrote earlier.... robiw

grko · Answer

@robiw Maybe just subsequent data from the ESP8266 overwrites your data in modemReply before you can display it on the serial port.

robiw · Answer

No, because they come infrequently. I've reduced the speed from the standard 115200 to 9600 and it works sort of better, i.e. the whole CONNECT response already comes in, not just CO. The question is, does each line of the modem response end with a sequence of CR+LF bytes? robiw

Anonymous · Answer

No, it isn't.
I used to use LF to detect the end of the line too, but that's not a good way with the ESP8266.
It is better to know what kind of response you are expecting and look for it in the received data with some timeout.

In addition, on startup the ESP sends some binary data to the PC software and some parsers can't cope with that either.

Anonymous · Answer

Cannot be for two reasons. 1. you are in the middle of an interrupt and the sei was not there 2. copying is rather fast One side note. Using a function like strcpy that the compiler knows nothing about in an interrupt can result in putting a lot of registers on the stack (because, after all, it doesn't know what function it's using) and cause an increase in interrupt execution time and code size compared to, say, some loops that copy data. By the way, have you checked if the communication goes as expected?

grko · Answer

@Piotrus_999 Using a for loop instead of the standard memcpy/strcpy functions. Great idea to replace a specially optimised for AVR function in favour of a dull for loop. @robiw You can avoid this copying by making yourself 2 buffers. You fill one in the interrupt and use the other in the main thread. When you receive an end-of-line character, you simply change the pointer to the active buffer.

Anonymous · Answer

@grko Simply in the interrupt as you use the unknown function you have: Code: AVR assemblerLog in, to see the code . and this is what I signalled, remembering the recent discussions about putting a lot of registers on the stack. Perhaps it was the use of the library function that was the problem . Worth taking into account.

Anonymous · Answer

@piotrus When I noticed that it was USART0_RX_vect then I retracted the statement and it is not in my post. @robiw . The Realterm program has the property (probably some other too) that it shows CR and LF characters even colouring them. It is possible to see efficiently which response of the modem is completed with them. It seems to me that the modem at some point sends the newline command itself and then starts writing. This seems to be the difficulty for all these parsers, because they are in the process of analysing after the LF character and new data flow immediately. I'm writing a little from memory, but as I wrote, it's better to look at it with Realterm.

Anonymous · Answer

This is no parser. It just waits for the end of the line. By the way, at this speed, I think you'd be able to do some language tokenisation in an interrupt.

robiw · Answer

I'll check carefully tomorrow, but it seems that after reducing the speed to 9600 bps everything laughs better. The processor is clocked at 11.059MHz, so that 115200 bps wasn't too bad for it, especially as the target interrupt is to parse data into multiple variables gathered into a structure. In Realterm I previewed and the lines are terminated with either a CR+LF sequence or, much more often, LF alone. The exception is OK, which occurs, as a sequence of CR+LF OK CR+LF. Sometimes LF alone also appears in the responses.... robiw

dondu · Answer

. And what display mode did you select Ansi? Ascii? ... Both are wrong, because Realterm does not display all received bytes. Always preview in Hex mode, preferably Hex+Ascii.

ESP8266 - AT response termination specification (CR, LF, CR CR LF?)

Post #1

Post #2

Post #3

Post #4

Post #5

Post #6

Post #7

Post #8

Post #9

Post #10

Post #11

Post #12

Post #13

Post #14

Didn't find an answer? Ask Artificial Intelligence

Topic summary