Here we can all chat about fixing the AT+ command structure and the associated responses.

User avatar
By Rodrigonh
#52088 Hello folks!

I'm using latest firmware from ESPRESSIF "esp8266_nonos_sdk_v2.0.0_16_07_19".
The current "AT instructions Set Version 1.5.4" states for AT+CIPSENDEX: '... when data length or "\0" is met, starts transmission of data.
So if sending "\0" is needed, please send it as "\\0"

My problem is that while sending HTTP data, if the content contains REGEX syntax as for example in javascript code like: "c.match(/(?:^|\s+)([!#$%&'*+\-.0-9A-Z^`a-z|~]+)=([!#$%&'*+\-.0-9A-Z^`a-z|~]*|"(?:[\x20-\x7E\x80\xFF]|\\[\x00-\x7F])*")(?=\s*[,;]|$)/g)"

The parts containing \\ whatever will be sent as \ whatever, it just get rid of one of the '\'. It ruins everything while trying to parse REGEX, also brakes the page entirely. Also it goes against what states the AT Instruction Set that informs the escape sequence is "\0".

I cannot use pure CIPSEND because data is dynamically generated.

Any tips or workarounds for this problem?

In time: It's quite disgusting that an appealing and cool piece of hardware like the ESP8266 doesn't have a official channel support. ESPRESSIF Forum is closed for registrations and no contact/email information on the page. If they really want to enter the production market they will need to fix this. Also details like bad translated (sometimes confusing and misleading), translations to English. ESP8266 is quite cool and I can see a nice future for it in the market, seems it just need a bit of corporate maturation technology is there already.

Any help about this problem will be greatly appreciated.

Regards!
Rodrigo
User avatar
By Rodrigonh
#52146 To leave a register about how I deal to fix this issue:

Despite "\0" being the escape sequence for CIPSENDEX accordingly the manual, the ESP firmware handles "\" as escape character, regardless what's coming next, what I think is problematic because a data stream should be capable of sending anything in the usual 0 - 255 range. At the same time I understand that determining what could be a escape sequence, that deals right with CIPSENDEX buffer boundaries is not something easy to find a solution.
Maybe a good idea creating an additional AT command that triggers CIPSENDEX escape by pulling LOW/HIGH one of the ESP GPIO's ? Sounds like a nice option to simplify things interfacing with ESP externally.

Anyway, the fix for this was: Everytime my data to be sent contains a "\" I send two additional "\". As for most compilers "\" is also a escape character then In the source code it ends like sending "\\" and "\\" again for each "\" to be transmitted.