如果当前的通信方式是建立连接的，可以开一个服务用于获取设备的MAC地址。如果是不建立连接的，则可以在广播包数据中包含设备的MAC地址信息，这两部分都可以由程序实现，并不需要定制芯片。关于广播数据修改和服务示例代码可以参考例程esp-idf/examples/bluetooth/bluedroid/ble/gatt_server和esp-idf/examples/bluetooth/bluedroid/ble/ble_ibeacon

key 长不建议改，建议修改命名风格。但使用 IDF v5.1.2 + ESP32 进行复现未出现不能正常读写问题。复现过程中，基于 nvs_rw_value 例程加长了namespace_name 和 key 的长度，并修改了 nvs.h 中的 NVS_PART_NAME_MAX_SIZE 与 NVS_KEY_NAME_MAX_SIZE。

1. 这是由信道特性决定的，相邻信道的数据是有可能被读取到的。如果在程序中配置了辅助信道，比如相邻的信道被用作发送和接收时，分别配置了 WIFI_SECOND_CHAN_ABOVE 和 WIFI_SECOND_CHAN_BELOW，因为信道交叠更会出现所提到的情况。 2. ESP-NOW 没有自动重传。 3. 有关 send_cb： 调用 :cpp:func:`esp_now_send()` 发送 ESP-NOW 数据，调用 :cpp:func:`esp_now_register_send_cb` 注册发送回调函数。如果 MAC 层成功接收到数据，则该函数将返回 `ESP_NOW_SEND_S...

RGB 接口屏幕的话，开 bounce buffer 可以满足 25M 的 PCLK 要求，具体可见：https://docs.espressif.com/projects/esp ... s/lcd.html 中 Bounce Buffer with Single PSRAM Frame Buffer 相关内容。
现在 RGB 接口建议使用 S3 。

推荐一些视频及文档资源：
1. Bilibili / ESP_Friends（https://space.bilibili.com/349329671848 ... 33.337.0.0）
2. ESP-IDF 编程指南 / 快速入门（https://docs.espressif.com/projects/esp ... index.html）
3. Bilibili / 乐鑫信息科技（https://space.bilibili.com/538078399）

根据 log 中的信息，这意味着应用程序正尝试解引用一个 NULL 指针。
更多可以参考：严重错误（https://docs.espressif.com/projects/esp ... s.html#id1）

的确此管脚应该可以进行I2C配置的。看贴出来的程序没有观察到什么问题，管脚状态配置后状态错误可能是因为引脚功能冲突或者其他硬件问题等。

经过复现我们的确观察到了这一问题，我们正在着手修复中，谢谢您的反馈。

当返回ESP_OK时，数据是正确的。但是当返回ESP_ERR_TIMEOUT时，数据是不可用的。
为了处理这种情况可以：1. 延长等待时间 2. 应用层判断超时后进行重发

可以修改 idf/tools/idf_py_actions/serial_ext.py 下 BAUD_RATE 中 'default' 的值。