espressif
+IPD design issue
+IPD — Receives Network Data this is a command (including packet-data) send by ESP32 in which the other side uC (or whatever) have no control of when will be send.
Since this is async (uC cannot control), this could cause problem to uC when comes at unexpected time.
The number of bytes that will be transmitted also isnt controlled at all by the uC.
Where as ESP32 AT+CIPSEND command have provision on number of bytes that can be transmitted (2KB max) and ESP32 get to send '>' to tell when it is ready to enter packet acceptance stage.
Due to the poor AT command design (+IPD), it will not be possible to use DMA properly with UART in uC side.
It would have been better that, the +IPD should have been similar to AT+CIPSEND. the uC would poll at interval to fetch data.
something like would be better:
- uC send
AT+IPD=<link ID>,<len> - ESP32 send
<available-length>[,<remote IP>,<remote port>] - uC send
> - ESP32 send the
<packet data bytes....>
Though this is a complex negotiation but far better to use for uC interrupt driven processing and when bulk data is there uC can utilized DMA too.
In general, with current (poor) approach, MCU DMA configuration is hard, but newer MCUs support IDLE line detection where you can also handle DMA by software.
In general, ESP should notify you (automatically, no polling from MCU!) about new data available, specially when you are in server mode!
- ESP sends `+IPDREADY=<link ID>,
[,<remote IP>,<remote PORT>] - uC send
AT+IPD=<link ID>,<desired len> - ESP response with
actual data here...
In this case, MCU is aware that we have available data to read and will read it when need. If ESP got buffer overflow internally, this is then user's problem for slow read of data.
For backward compatibility, this feature could be enabled by AT command if required!
PS: Why are Espressif guys trying to ignore messages like this?
Hi,
The official demo code maybe cannot meet all requirements.
But I think it can be achieved by modifying at_port_write_data and customizing AT command in at_task.c. You can check the prefix +IPD: in at_port_write_data and put the data into a buffer, Then add a command like AT+IPD=<link ID>,<desired len> to read it.
There is a room for ESP improvements. I think Espressif should add this feature just like it is implemented in Sim800/900 where you have option to choose how to work.
I agree, for AT mode to be robust it needs to support polling by the uc for receiving data. Asking users to modify the AT code does not help because the purpose of the AT code is to avoid needing to program the 8266. It would really help me to use the 8266 if this feature were implemented.
确实是一个糟糕的设计 我用esp32下载一个1MB的文件 因为是at封装的socket上层是ftp协议 结果触发到下载之后 esp32源源不断的给我 +IPD 携带数据 我用的host是stm32h7很强的mcu 我仍然处理不过来 。。 我尝试修改at指令 但是发现这个是一个lib 应该如何修改呢
另外我做了一些测试 将esp32的串口配置为流控方式 在host端通过定期硬件流控 虽然+IPD是可控制了 但是我收到的数据不完整 内部存在bug？
@MaJerle @kuldeepdhaka @akotowski @CamelShoko Thanks for your valuable advice! I'm not sure if you can still notice this issue.
ESP-AT added this feature in May 2019. you can get them at version >= v2.0.0.0, such as latest v2.2.0.0.
AT Commands usage like:
// set passive receive mode
AT+CIPRECVMODE=1
// lookup the buffered size
AT+CIPRECVLEN?
// fetch data
AT+CIPRECVDATA=<link_id>,<len>
See TCP/IP AT Commands for more details about AT+CIPRECVMODE, AT+CIPRECVLEN, AT+CIPRECVDATA.
我尝试自己编译了一个at版本 做了如下修改目前可以满足使用 1）修改串口收发缓存的大小 2）在at_port_write_data中匹配+IPD指令 如果匹配到则根据上一次的IPD指令间隔适当random延时
通过这些修改之后我的应用层代码可以正常运行了 下载了几个大小不一的文件 都是完整的