ustccw commented 3 years ago

ESP-AT New Features Collection

A. Brief Introduction

Currently, many AT commands have been added to the esp-at project, but esp-at still does not meet the requirements of all products.
Here, we are committed to extracting some common features and adding them to the general esp-at firmware to reduce the cost of customer development, accelerate the landing of customer products and inject fresh blood into the esp-at project at the same time.

So...o, suggest any feature request for this project would be welcomed!

B. Code of Conduct

Please navigate to ESP-AT User Guide and search features to avoid creating duplicates before you comment on the feature request.
Please describe the feature you'd like, as clear and understandable as possible.

C. Sample of New Feature Request

[MQTT][ALPN] Hope AT+MQTT command support ALPN Short Description: As the AWS Device communication protocols designed, clients that connect on port 443 with X.509 client certificate authentication must implement the Application Layer Protocol Negotiation (ALPN) TLS extension and use the ALPN protocol name listed in the ALPN ProtocolNameList sent by the client as part of the ClientHello message.

D. Feature Statistics

Status	Feature Description	Plan	Note
Done	[MQTT][ALPN] MQTT supports ALPN configuration	/	supported after d16e75f
Done	[SNTP] support the synchronization interval setting	/	supported after e8d4c34
Done	[BLE] support BLE 5.0	v2.4.0.0	supported after 19b48fe
Won't Do	[USB] ESP32-C3 supports USB interface	/	it's unstable if Wi-Fi and USB are used together
TODO	[BT] support passive read for bluetooth data	v2.4.0.0+	/
Won't Do	[Wi-Fi] support Wi-Fi roaming	/	1. Roaming has to be initiated by AP; 2. `802.11r` only make sure that we will skip 4 way handshake during roam; 3. Device may get disconnected for various reasons, right now we don't initiate roaming automatically based on disconnection; 4.It was more a request from customer in mesh solutions in which they expect devices to move automatically between the APs as APs wants and timing should be pretty low.
TODO	[TCP/IP] AT+CIPSERVER supports more servers	v2.4.0.0+	/
Won't Do	[MQTT over WS] Customize HTTP header	/	not common

MaJerle commented 3 years ago

I've been asking for better AT+CIPSTART implementation with AT+CIPSTARTEX, where application doesn't set connection number by itself. Instead, we should do it like that:

-> AT+CIPSTARTEX="TCP",and_other_thingsCRLF
<- +CIPSTARTEX:0,conn_num_assigned_by_ESP
<- +CIPSTARTEX:1,1 (if connect OK)
<- +CIPSTARTEX:1,0 (in case of failure)
<- OK

In this case we have well defined strategy when we use client and server at the same time. Otherwise we may have race conditions.

However all pushes have been well defined w/o proper argument.

como-221e commented 3 years ago

[MQTT][ALPN] ALPN support within the MQTT client. Short description: It would be useful to have ALPN enabled within the SSL layer of the MQTT client in such a way that MQTT connections can be established with ports typically used for other protocols (e.g. port 443). This may come handy with AWS (see here).

como-221e commented 3 years ago

[MQTT over WS][HTTP header] Customized HTTP header with MQTT over web socket client. Short description: It would be useful to customize the header of the HTTP request related to the opening of a web-socket based MQTT client, in order to pass over to the server additional info, like token authentication parameters. Currently this can be done by adding the parameters to the "path" field of the AT+MQTTUSERCFG but this is limited to the 32 bytes max length of such field and therefore not much useful.

ustccw commented 3 years ago

I've been asking for better AT+CIPSTART implementation with AT+CIPSTARTEX, where application doesn't set connection number by itself. Instead, we should do it like that:
-> AT+CIPSTARTEX="TCP",and_other_thingsCRLF
<- +CIPSTARTEX:0,conn_num_assigned_by_ESP
<- +CIPSTARTEX:1,1 (if connect OK)
<- +CIPSTARTEX:1,0 (in case of failure)
<- OK
In this case we have well defined strategy when we use client and server at the same time. Otherwise we may have race conditions.

However all pushes have been well defined w/o proper argument.

Hi @MaJerle, esp-at has the command AT+SYSMSG, enable BIT1 of the command could get detailed connection prompt information. I am not sure if this meets your requirements.

ustccw commented 3 years ago

[MQTT][ALPN] ALPN support within the MQTT client. Short description: It would be useful to have ALPN enabled within the SSL layer of the MQTT client in such a way that MQTT connections can be established with ports typically used for other protocols (e.g. port 443). This may come handy with AWS (see here).

@como-221e Thanks for the feedback, had added to the esp-at TODO list.

ustccw commented 3 years ago

[MQTT over WS][HTTP header] Customized HTTP header with MQTT over web socket client. Short description: It would be useful to customize the header of the HTTP request related to the opening of a web-socket based MQTT client, in order to pass over to the server additional info, like token authentication parameters. Currently this can be done by adding the parameters to the "path" field of the AT+MQTTUSERCFG but this is limited to the 32 bytes max length of such field and therefore not much useful.

@como-221e In fact, the path parameter configured by the AT+MQTTUSERCFG command will be passed to the "GET %s HTTP/1.1" of the websocket connection establishment request, which indicates the resource path, other than authentication item.

Generally speaking, authorization is implemented through wss certificate or subprotocol of websocket. It is recommended that use username and password parameter of MQTT to authorize.

If authorization is mandatory in websocket request, user can modify the implement of websocket here. https://github.com/espressif/esp-idf/blob/master/components/tcp_transport/transport_ws.c#L147 Furthermore, could you please submit an issue in esp-idf to request the authorization function of webwocket.

JAndrassy commented 3 years ago

[TCP-IP] AT+CIPSERVER - please add support for more TCP servers. servers can be identified with port. what is the reason for the one server limit? a TCP server has no overhead.

RomeliFeng commented 3 years ago

About Wi-Fi roaming feature.

ustccw commented 3 years ago

About Wi-Fi roaming feature.

Thank you. We have this plan in v2.3.0.0.

MaJerle commented 3 years ago

How to make UDP server to be discovered by Alexa?

ustccw commented 3 years ago

[TCP-IP] AT+CIPSERVER - please add support for more TCP servers. servers can be identified with . what is the reason for the one server limit? a TCP server has no overhead.

This is not easy to add this feature to ESP-AT common firmware. Because:

Based on compatibility consideration. AT commands were designed without considering multiple servers, not for memory reasons, but for convenience and maintenance.
The work may not be easy, it may involve almost all the TCP/IP AT commands.

Here, it is suggested that the user carry out the secondary development based on AT framework, this is a recommended way.

ustccw commented 3 years ago

How to make UDP server to be discovered by Alexa?

AFAIK, udp may not have the concept of server. udp can receive the data from the port which it listens, or send the data to the port. Maybe you can take a look:

MaJerle commented 3 years ago

Indeed, but ESP AT syntax is forcing me to use one IP. So which one should I use to get discovered by someone on known port?

Is there a way for "any" IP?

ustccw commented 3 years ago

Indeed, but ESP AT syntax is forcing me to use one IP. So which one should I use to get discovered by someone on known port?

Is there a way for "any" IP?

emmm, i am not sure what is "any ip". As far as udp is concerned, it is based on IP network, any udp packet should have an IP address, whatever unicast, multicast or broadcast. In fact, AT command supports all of them.

MaJerle commented 3 years ago

Indeed, but ESP AT syntax is forcing me to use one IP. So which one should I use to get discovered by someone on known port? Is there a way for "any" IP?

emmm, i am not sure what is "any ip". As far as udp is concerned, it is based on IP network, any udp packet should have an IP address, whatever unicast, multicast or broadcast. In fact, AT command supports all of them.

Thanks. What is the AT command sequence to get UDP packets in local network on port (let's say) 1234?

JAndrassy commented 3 years ago

[TCP-IP] AT+CIPSERVER - please add support for more TCP servers. servers can be identified with . what is the reason for the one server limit? a TCP server has no overhead.

This is not easy to add this feature to ESP-AT common firmware. Because:
1. Based on compatibility consideration. AT commands were designed without considering multiple servers, not for memory reasons, but for convenience and maintenance.

2. The work may not be easy, it may involve almost all the TCP/IP AT commands.
Here, it is suggested that the user carry out the secondary development based on AT framework, this is a recommended way.

servers are identified by ports. incoming clients have local port information in CIPSTATUS. so no AT commands need to be changed. ~~as bonus AT+CIPDINFO could configure local port info into +IPD~~ EDIT: CONNECT announces a new connection, not +IPD

ustccw commented 3 years ago

Indeed, but ESP AT syntax is forcing me to use one IP. So which one should I use to get discovered by someone on known port? Is there a way for "any" IP?

emmm, i am not sure what is "any ip". As far as udp is concerned, it is based on IP network, any udp packet should have an IP address, whatever unicast, multicast or broadcast. In fact, AT command supports all of them.

Thanks. What is the AT command sequence to get UDP packets in local network on port (let's say) 1234?

I am not sure what kind of udp packet type Alexa sends out. let's say it is the udp broadcast. so the AT commands like the following:

AT+RESTORE
AT+CWMODE=1
AT+CWJAP="ssid","password"
AT+CIPSTART="UDP","255.255.255.255",1234

more see as: https://docs.espressif.com/projects/esp-at/en/latest/AT_Command_Set/TCP-IP_AT_Commands.html#establish-udp-transmission.

ustccw commented 3 years ago

[TCP-IP] AT+CIPSERVER - please add support for more TCP servers. servers can be identified with . what is the reason for the one server limit? a TCP server has no overhead.

This is not easy to add this feature to ESP-AT common firmware. Because:
1. Based on compatibility consideration. AT commands were designed without considering multiple servers, not for memory reasons, but for convenience and maintenance.

2. The work may not be easy, it may involve almost all the TCP/IP AT commands.
Here, it is suggested that the user carry out the secondary development based on AT framework, this is a recommended way.
servers are identified by ports. incoming clients have local port information in CIPSTATUS. so no AT commands need to be changed. as bonus AT+CIPDINFO could configure local port info into +IPD
[TCP-IP] AT+CIPSERVER - please add support for more TCP servers. servers can be identified with . what is the reason for the one server limit? a TCP server has no overhead.

This is not easy to add this feature to ESP-AT common firmware. Because:
1. Based on compatibility consideration. AT commands were designed without considering multiple servers, not for memory reasons, but for convenience and maintenance.

2. The work may not be easy, it may involve almost all the TCP/IP AT commands.
Here, it is suggested that the user carry out the secondary development based on AT framework, this is a recommended way.
servers are identified by ports. incoming clients have local port information in CIPSTATUS. so no AT commands need to be changed. as bonus AT+CIPDINFO could configure local port info into +IPD

i can understand what you expected, there is always a way to be as compatible as possible with previous AT commands. esp-at will consider this feature when esp-at updates to an incompatible large version in the future.

lukegluke commented 3 years ago

Classic Bluetooth SPP - improve receiving.

Currently on data receiving there is URC filled with data: +BTDATA:4,test Length of data is not limited by anything and could exceed limited resources of external MCU and/or can be reported in not appropriate times. It is quite bad strategy to demand external MCU to receive all data immediately once ESP is received it wirelesslly. Also bluetooth data in general and useful cases is binary and parsing raw binary data that can be received at any times inconvenient and demands modification of common AT line parsers.

It would be more convenient to have only a notification (indicator) about new data receiving in URC (+BTSPPRCV:). And then user can use additional command something like AT+BTSPPREAD=0,255 (read data from SPP id 0, max length is 255 bytes).

AT+BTSPPREAD response:

+BTSPPREAD:<data_len>
<data>
OK

This way it would be much easier to parse raw binary data that can includes <0>, <CR>, <LF>. Also it would be convenient to support request about length of data available in buffer: AT+BTSPPREAD=0,0

+BTSPPREAD:<totalreceivelength>,<havereadlength>,<unreadlength>
OK

This way is similar to Quectel M66 GSM module with Bluetooth, I like how they implemented it. And as I see ESP32 TCP-IP commands already use this approach with notification +IPD, so it is doubly sad that bluetooth receiving doesn't follows common practice.

Please pay attention that other URCs must not interpose between +BTSPPREAD and OK.

TakashiKusachi commented 3 years ago

[SNTP] Setting the synchronization interval https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/system/system_time.html?highlight=sntp#sntp-time- synchronization The URL above shows that you can add the ability to set the update interval. I would like to have this feature.

Another possible feature would be to force the time to synchronize.

As an additional question, in the current version (2.2.0), this synchronization interval is (https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/kconfig.html# config-lwip-sntp-update-delay) of 3600000?

Translated with www.DeepL.com/Translator (free version)

ustccw commented 3 years ago

[SNTP] Setting the synchronization interval https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/system/system_time.html?highlight=sntp#sntp-time- synchronization The URL above shows that you can add the ability to set the update interval. I would like to have this feature.

Another possible feature would be to force the time to synchronize.

As an additional question, in the current version (2.2.0), this synchronization interval is (https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/kconfig.html# config-lwip-sntp-update-delay) of 3600000?

Translated with www.DeepL.com/Translator (free version)

@TakashiKusachi Thanks for your suggestion. we will add the feature to the next version.

foldl commented 2 years ago

BLE 5.x features

AT commands for BLE 5.x features, such as extended advertising, PHY management, etc.

ustccw commented 2 years ago

BLE 5.x features

AT commands for BLE 5.x features, such as extended advertising, PHY management, etc.

@foldl ESP32-C3 supports BLE 4.2 now, and will supports BLE 5.0 in the next few months. we planed to release v2.4.0.0 for ESP32-C3 in March 2022, which includes BLE 5.0.

ustccw commented 2 years ago

@foldl ESP32-C3 supports BLE 5.0 now, please get the latest code. esp-at plans to release v2.4.0.0 for ESP32-C3 in April 2022.

matt-wood-ct commented 2 years ago

[INTERFACE][USB] Support for USB VCP as an at command interface
Short description:
Many hosts which use at command radios communicate using USB VCP rather then uart directly, it would be useful to either support USB VCP in parallel with the UART/SDIO or as a configuration option. Specifically on the ESP32-C3 Series where the VCP is a core feature of the IC/Module

xcguang commented 2 years ago

@matt-wood-ct We has finished it, but it will output some logs to USB from ROM API, unfortunately, these logs cannot be masked. We can evaluate it again.

matt-wood-ct commented 2 years ago

@matt-wood-ct We has finished it, but it will output some logs to USB from ROM API, unfortunately, these logs cannot be masked. We can evaluate it again.

I think for me this would be OK, is there a branch or bin I can try?

Many Thanks, Matt

xcguang commented 2 years ago

@matt-wood-ct C3 USB need IDF v4.4 or later, we have not ported AT to this IDF. After release v2.4.0.0, we will do this. Pray to be released in two weeks.

lippit commented 2 years ago

[CWSTAPROTO][WIFI_PROTOCOL_LR] Support for long range protocol Short description: ESP IDF supports the proprietary Espressif WiFi long range protocol, defined in esp_wifi_types.h: #define WIFI_PROTOCOL_LR 8 Unfortunately, setting this value with AT+CWSTAPROTO results in an error. Please add support for this protocol in AT firmware.

MaJerle commented 2 years ago

What about ability to set private key and public certificate for SSL connection via file operation commands like Quectel LTE modems? https://www.quectel.com/wp-content/uploads/2021/03/Quectel_BG96_SSL_Application_Note_V1.1.pdf

ustccw commented 2 years ago

[CWSTAPROTO][WIFI_PROTOCOL_LR] Support for long range protocol Short description: ESP IDF supports the proprietary Espressif WiFi long range protocol, defined in esp_wifi_types.h: #define WIFI_PROTOCOL_LR 8 Unfortunately, setting this value with AT+CWSTAPROTO results in an error. Please add support for this protocol in AT firmware.

thanks for the feature request. will add this in one month.

ustccw commented 2 years ago

What about ability to set private key and public certificate for SSL connection via file operation commands like Quectel LTE modems? https://www.quectel.com/wp-content/uploads/2021/03/Quectel_BG96_SSL_Application_Note_V1.1.pdf

it's not a bad idea, we had considered it before. but file operation will cost massive flash space and ram space, so it is not that common for all esp chips. such as ESP8266 and ESP32-C2 has a relatively less flash and ram so that esp-at disabled the FS commands.

btw, esp-at has a light private key and certificate update steps here: https://docs.espressif.com/projects/esp-at/en/latest/esp32/Compile_and_Develop/how_to_generate_pki_files.html

MaJerle commented 2 years ago

@ustccw - what if we use AT+SYSFLASH commands to hardcode load information there? Can we do it? I simply want to avoid modify official AT command firmware coming from Espressif. I want to load everything through AT commands.

ustccw commented 2 years ago

@MaJerle yeah, AT+SYSFLASH command can update the private key bin and certificate bin: https://docs.espressif.com/projects/esp-at/en/latest/esp32/Compile_and_Develop/how_to_generate_pki_files.html#update-with-commands. this action will not modify esp-at.bin, no worry about function issues.

MaJerle commented 2 years ago

@MaJerle yeah, AT+SYSFLASH command can update the private key bin and certificate bin: https://docs.espressif.com/projects/esp-at/en/latest/esp32/Compile_and_Develop/how_to_generate_pki_files.html#update-with-commands. this action will not modify esp-at.bin, no worry about function issues.

I don't think so, actually. In the AT+SYSFLASH command, I see:

Please make sure that you have downloaded at_customize.bin before using this command. For more details, please refer to How to Customize Partitions.

So it means I have to build on my own, no?

ustccw commented 2 years ago

@MaJerle yeah, AT+SYSFLASH command can update the private key bin and certificate bin: https://docs.espressif.com/projects/esp-at/en/latest/esp32/Compile_and_Develop/how_to_generate_pki_files.html#update-with-commands. this action will not modify esp-at.bin, no worry about function issues.

I don't think so, actually. In the AT+SYSFLASH command, I see:

Please make sure that you have downloaded at_customize.bin before using this command. For more details, please refer to How to Customize Partitions.

So it means I have to build on my own, no?

in the released firmware: https://docs.espressif.com/projects/esp-at/en/latest/esp32/AT_Binary_Lists/ESP32_AT_binaries.html there should already include the at_custommize.bin.

ustccw commented 2 years ago

[CWSTAPROTO][WIFI_PROTOCOL_LR] Support for long range protocol Short description: ESP IDF supports the proprietary Espressif WiFi long range protocol, defined in esp_wifi_types.h: #define WIFI_PROTOCOL_LR 8 Unfortunately, setting this value with AT+CWSTAPROTO results in an error. Please add support for this protocol in AT firmware.

this commit should include it: https://github.com/espressif/esp-at/commit/5435e9aa074e38ab5a3eebcabfe7f6fe24093d06 could you please give it a try.

Jacques-Zhao commented 1 year ago

@matt-wood-ct When we tested USB AT, we found a serious problem, because WiFi and USB share the phy clock, the USB output could get stuck when WiFi and USB are used together, which caused the ESP32-C3 to not support the USB AT solution.

Jacques-Zhao commented 1 year ago

@matt-wood-ct I've uploaded the patch that implements USB AT, which can be used for testing. It should be noted that this patch cannot be used for production. 0001-feat-support-ESP32-C3-using-USB.patch

DynamicLoader commented 1 year ago

Hi, I would like to suggest a new communication method. Today's firmware transport events,network data,commands over a single path,UART/SPI. I wonder that if the data transfer from SPI, and command from UART;when there is an event, use a GPIO to inform the host instead of directly print on the UART. The host could query the events with a new command(let's say AT+CEVT and AT+SYSEVT). It's a method for the improvement of stability and speed, which will also simplify the programing on the host side. Best wishes!

MaJerle commented 1 year ago

@ustccw @FayeY,

AT+CIPSTARTEX is super when system uses several connections active at a time and on top also uses server mode. In this way ESP is in charge of providing the connection.

When dealing with SSL connections, today the only way is to use AT+CIPSSLCCONF to set key parameters. This command requires connection ID, which is somewhat contra-intuitive comparing to AT+CIPSTARTEX command. The whole point of EX is lost if before that I have to set the SSL config to exact link ID only. When using several operations, server, MQTT, client, ..., each may use different config for SSL (auth, client pki, index).

A proposal is to extend AT+CIPSTARTEX command, that can directly support all SSL parameters in a single call. These parameters are only valid if conn type is SSL.

Or, maybe even better, make a AT+CIPSTARTSSLEX command, that has only write+execute commands. It works exactly as AT+CIPSTARTEX but can set all parameters in single call. This includes client pre-shared key, certification slots, PKI numbers, ...

ustccw commented 1 year ago

Hi, I would like to suggest a new communication method. Today's firmware transport events,network data,commands over a single path,UART/SPI. I wonder that if the data transfer from SPI, and command from UART;when there is an event, use a GPIO to inform the host instead of directly print on the UART. The host could query the events with a new command(let's say AT+CEVT and AT+SYSEVT). It's a method for the improvement of stability and speed, which will also simplify the programing on the host side. Best wishes!

@DynamicLoader May I ask why you didn't consider using SPI interface for both AT commands and data? Are there any specific limitations?

To be honest, ESP-AT did consider supporting multiple medium interfaces (including UART, SPI, SDIO, socket, etc., similar to netif on the PC side, managed through routing). However, this feature was later abandoned mainly due to the following reasons:

From a product perspective, having multiple medium interfaces would increase hardware costs and require more PCB wiring.
The existing design already fulfills the functionality of the majority of products.

Therefore, the general firmware does not support this feature. If you indeed require commands to be sent/recv via UART and data to be sent/recv via SPI, you can modify the code (located in the https://github.com/espressif/esp-at/tree/master/main/interface directory) to redirect the SPI interface's command transmission and reception to UART.

ustccw commented 1 year ago

@ustccw @FayeY,

AT+CIPSTARTEX is super when system uses several connections active at a time and on top also uses server mode. In this way ESP is in charge of providing the connection.

When dealing with SSL connections, today the only way is to use AT+CIPSSLCCONF to set key parameters. This command requires connection ID, which is somewhat contra-intuitive comparing to AT+CIPSTARTEX command. The whole point of EX is lost if before that I have to set the SSL config to exact link ID only. When using several operations, server, MQTT, client, ..., each may use different config for SSL (auth, client pki, index).

A proposal is to extend AT+CIPSTARTEX command, that can directly support all SSL parameters in a single call. These parameters are only valid if conn type is SSL.

Or, maybe even better, make a AT+CIPSTARTSSLEX command, that has only write+execute commands. It works exactly as AT+CIPSTARTEX but can set all parameters in single call. This includes client pre-shared key, certification slots, PKI numbers, ...

@MaJerle thanks for your proposal. will discuss it internally and feedback here within one week.

ustccw commented 1 year ago

@ustccw @FayeY,

AT+CIPSTARTEX is super when system uses several connections active at a time and on top also uses server mode. In this way ESP is in charge of providing the connection.

When dealing with SSL connections, today the only way is to use AT+CIPSSLCCONF to set key parameters. This command requires connection ID, which is somewhat contra-intuitive comparing to AT+CIPSTARTEX command. The whole point of EX is lost if before that I have to set the SSL config to exact link ID only. When using several operations, server, MQTT, client, ..., each may use different config for SSL (auth, client pki, index).

A proposal is to extend AT+CIPSTARTEX command, that can directly support all SSL parameters in a single call. These parameters are only valid if conn type is SSL.

Or, maybe even better, make a AT+CIPSTARTSSLEX command, that has only write+execute commands. It works exactly as AT+CIPSTARTEX but can set all parameters in single call. This includes client pre-shared key, certification slots, PKI numbers, ...

sorry for late reply. We have had an in-depth internal discussion regarding this requirement, and we believe that AT+CIPSTARTEX is not very suitable for scenarios with multiple connections (AT+CIPMUX=1). Typically, AT+CIPSTARTEX is more suitable for single connections (AT+CIPMUX=0). If used in a multi-connection scenario, it only supports one connection with the link_id == 0.

MaJerle commented 1 year ago

Then we can remove cipstartex command, no?

ustccw commented 1 year ago

Then we can remove cipstartex command, no?

i'm afraid not. For compatibility reasons, we have to keep this command. However, we do not highly recommend using this command in multi-connection mode.

mrx23dot commented 1 year ago

Allow scanning in BLEINIT 2 (dual role) https://github.com/espressif/esp-at/issues/743

MaJerle commented 1 year ago

What about supporting SHA-256 (or similar algo) for flash/manuf_data integrity check?

As it is flash underlying system, it has its maximum write/erase cycles. Especially for large binary entries, it would make sense to do a integrity check, mainly to verify if the data you have on your host side matches the one on the device. If it does, no need for erase/write operation.

Typical case would be certificates, that you may have in the MCU and want them to upload to ESP for TCP SSL connection. You can do erase/write only if integrity on the host doesn't match the one on the MCU. Today the solution is to read everything and compare. Quite a long time to do it.

Integrity should have partition, offset and length options. Or just partition, or just partition + offset (up to the end).

mrx23dot commented 1 year ago

What about supporting SHA-256 (or similar algo) for flash/manuf_data integrity check?

As it is flash underlying system, it has its maximum write/erase cycles. Especially for large binary entries, it would make sense to do a integrity check, mainly to verify if the data you have on your host side matches the one on the device. If it does, no need for erase/write operation.

Typical case would be certificates, that you may have in the MCU and want them to upload to ESP for TCP SSL connection. You can do erase/write only if integrity on the host doesn't match the one on the MCU. Today the solution is to read everything and compare. Quite a long time to do it.

Integrity should have partition, offset and length options. Or just partition, or just partition + offset (up to the end).

crc32, not SHA-256 on embedded

MaJerle commented 1 year ago

Add option to receive +CIPSNTPTIME: reply in yyyy-mm-dd hh:mm:ss, rather than in user friendly format.

ESP-AT is used by dedicated host, not for "user friendly" day in a week. Option can be done with SYSMSG if we need backward compatibility. It can reduce the processing on HOST and it is generally not needed in the format as we have today.

espressif / esp-at