-
Notifications
You must be signed in to change notification settings - Fork 706
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
+IPD design issue #22
Comments
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!
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, |
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的串口配置为流控方式 在host端通过定期硬件流控 虽然+IPD是可控制了 但是我收到的数据不完整 内部存在bug? |
@MaJerle @kuldeepdhaka @akotowski @CamelShoko Thanks for your valuable advice! I'm not sure if you can still notice this issue.
See TCP/IP AT Commands for more details about |
我尝试自己编译了一个at版本 做了如下修改目前可以满足使用 通过这些修改之后我的应用层代码可以正常运行了 下载了几个大小不一的文件 都是完整的 |
+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:
AT+IPD=<link ID>,<len>
<available-length>[,<remote IP>,<remote port>]
>
<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.
The text was updated successfully, but these errors were encountered: