乐鑫科技代理公司蓝牙wifi二合一模块ESP32内存分析案例研究，内存对硅片成本以及芯片尺寸具有重大影响，因此从硬件角度看，优化内存尺寸很重要，从软件角度来看，能够充分利用内存资源也至关重要。
在本文中，我们将讨论 ESP-IDF 中的一些即将推出的功能和常用配置选项（可调项），以允许 终端应用程序 以佳方式利用各个内部存储区域。
重要提示
这里我们将重点介绍乐鑫科技代理公司蓝牙wifi二合一模块ESP32 的单核模式，因为该模式下可以适用更多内存优化功能；
我们将在这里考虑典型的 IoT 用例，在该用例下牺牲性能获得内存是可以接受的准则；
我们将以典型的云应用程序为研究用例，该应用需要具有相互认证支持的 TLS 连接；
这里使用的 ESP-IDF 功能分支可查阅 http://github.com/mahavirj/esp-idf/tree/feature/memory_optimizations 。

ESP32：内部存储器分解

从存储器布局可以看出，芯片内部存在各种具有不同时钟速度的存储器区域；
对于单核用例，我们获得了额外的 32K 指令存储空间（IRAM），否则（双核模式）该区域会作为 APP CPU 内核的 cache；
对指令 RAM 的访问，地址和空间大小应始终 32 位对齐；
对于终端应用程序的业务逻辑来说，总是希望有更多的 DRAM，它是访问速度快的内存且没有任何访问限制。
案例研究— AWS IoT 示例应用程序
我们将使用来自 ESP-AWS-IoT 的 subscribe_publish 示例作为研究案例，来分析内存利用率；
乐鑫科技代理公司蓝牙wifi二合一模块ESP-IDF 提供了一个 API ，可以使用 heap_caps_get_minimum_free_size() 获取小空闲堆或者说系统中可用的动态内存大小。我们的目标是大化这个数字（进行相对分析），从而增加终端应用程序特定业务逻辑的可用内存数量（特别是 DRAM 区域）。
默认内存利用率
我们将在 subscribe_publish 示例之上添加以下代码补丁来记录动态内存的统计信息。
开始，我们将分别记录 DRAM 和 IRAM 区域如上所述的系统小空闲堆大小；
其次，我们将使用堆任务跟踪功能，该功能提供了基于每个任务的动态内存使用信息。修改此功能后，还可以记录每个任务 DRAM 和 IRAM 区域的峰值使用量；
我们将分别为 aws_iot_task ，tiT (tcpip) 和 wifi 任务记录这些信息 （因为这些任务定义了从应用层到物理层的数据传输通道，反之亦然）。还应该注意的是，网络任务的峰值内存使用量会受到环境因素（如 Wi-Fi 连接，网络等待时间）的影响而变化。
注意 : 任务创建过程中对 core-id 的更改（代码补丁如下）是针对单核的配置，这里我们仅用于此特殊示例。
diff --git examples/subscribe_publish/main/subscribe_publish_sample.c examples/subscribe_publish/main/subscribe_publish_sample.c
index c5b48ae..1982375 100644
--- examples/subscribe_publish/main/subscribe_publish_sample.c
+++ examples/subscribe_publish/main/subscribe_publish_sample.c
@@ -157,6 +157,28 @@ void disconnectCallbackHandler(AWS_IoT_Client *pClient, void *data) {
     }
 }

+#include "esp_heap_task_info.h"
+static void esp_dump_per_task_heap_info(void)
+{
+    heap_task_stat_t tstat = {};
+    bool begin = true;
+    printf("Task Heap Utilisation Stats:\n");
+    printf("||\tTask\t\t|\tPeak DRAM\t|\tPeak IRAM\t|| \n");
+    while (1) {
+        size_t ret = heap_caps_get_next_task_stat(&tstat, begin);
+        if (ret == 0) {
+            printf("\n");
+            break;
+        }
+        const char *task_name = tstat.task ? pcTaskGetTaskName(tstat.task) : "Pre-Scheduler allocs";
+        if (!strcmp(task_name, "wifi") || !strcmp(task_name, "tiT") || !strcmp(task_name, "aws_iot_task")) {
+            printf("||\t%-12s\t|\t%-5d\t\t|\t%-5d\t\t|| \n",
+                        task_name, tstat.peak[0], tstat.peak[1]);
+        }
+        begin = false;
+    }
+}
+
 void aws_iot_task(void *param) {
     char cPayload[100];

@@ -278,6 +300,16 @@ void aws_iot_task(void *param) {
         }

         ESP_LOGI(TAG, "Stack remaining for task '%s' is %d bytes", pcTaskGetTaskName(NULL), uxTaskGetStackHighWaterMark(NULL));
+
+        const int min_free_8bit_cap = heap_caps_get_minimum_free_size(MALLOC_CAP_INTERNAL|MALLOC_CAP_8BIT);
+        const int min_free_32bit_cap = heap_caps_get_minimum_free_size(MALLOC_CAP_INTERNAL|MALLOC_CAP_32BIT);
+
+        esp_dump_per_task_heap_info();
+        printf("System Heap Utilisation Stats:\n");
+        printf("||   Miniumum Free DRAM\t|   Minimum Free IRAM\t|| \n");
+        printf("||\t%-6d\t\t|\t%-6d\t\t||\n",
+                    min_free_8bit_cap, (min_free_32bit_cap - min_free_8bit_cap));
+
         vTaskDelay(1000 / portTICK_RATE_MS);
         sprintf(cPayload, "%s : %d ", "hello from ESP32 (QOS0)", i++);
         paramsQOS0.payloadLen = strlen(cPayload);
@@ -328,5 +360,5 @@ void app_main()
     ESP_ERROR_CHECK( err );

     initialise_wifi();
-    xTaskCreatePinnedToCore(&aws_iot_task, "aws_iot_task", 9216, NULL, 5, NULL, 1);
+    xTaskCreatePinnedToCore(&aws_iot_task, "aws_iot_task", 9216, NULL, 5, NULL, 0);
 }

在订阅发布示例之上打补丁

使用默认配置（并启用了堆任务跟踪功能），我们得到以下堆利用率统计信息（所有值以字节为单位）：
任务的内存使用率统计：
 || 任务名       | 峰值 DRAM |峰值 IRAM||
 || aws_iot_task | 63124   |     0   ||
 || tiT          | 3840    |     0   ||
 || wifi         | 31064   |     0   ||

 系统的内存使用率统计：
 || 小可用 DRAM | 小可用 IRAM ||
 || 152976        | 40276        ||
单核配置
如前所述，我们将在所有实验中使用单核配置。请注意，即使在单核模式下，乐鑫科技代理公司蓝牙wifi二合一模块ESP32 仍具有足够的处理能力（接近 300 DMIPS），足以满足典型的 IoT 用例的需求。
在应用程序中启用相应的配置:
CONFIG_FREERTOS_UNICORE = y
重新运行应用程序之后更新的堆利用率统计信息如下所示：
任务的内存使用率统计：
 || 任务名       | 峰值 DRAM |峰值 IRAM||
 || aws_iot_task | 63124   |     0   ||
 || tiT          | 3892    |     0   ||
 || wifi         | 31192   |     0   ||

 系统的内存使用率统计：
 || 小可用DRAM | 小可用IRAM ||
 || 162980      | 76136       ||
从上面可以看出，我们在 DRAM 中多获得了约 10KB 的内存，这是由于不再需要第二个 CPU 内核的某些服务（例如，idle, esp_timer 任务等）。此外，也不再需要用于处理器间通信的 IPC 服务，因此我们可以从该服务的堆栈和动态内存中获得额外内存。 IRAM 的增加是由于释放了第二个 CPU 内核的 32KB cache，并且由于禁用了上述服务节省了一些代码空间。
TLS 特定（优化）
非对称 TLS 内容长度
此功能从 v4.0 开始已成为 ESP-IDF 的一部分。此功能允许为 TLS IN/OUT 缓冲区启用非对称的内容长度。因此，应用程序能够将 TLS OUT 缓冲区从默认值 16KB （每个规范的大 TLS 片段长度） 减小到 2KB，从而可以节省 14KB 的动态内存空间。
请注意，不太可能将 TLS IN 的缓冲区长度从默认值 16KB 减小，除非您可以直接控制服务器配置项，或者确保服务器不会出现发送超过某个阈值的入站数据的行为（在握手或实际数据传输阶段）。
在程序中启用相应的配置：
＃启用 TLS 非对称 IN/OUT 内容长度
 CONFIG_MBEDTLS_ASYMMETRIC_CONTENT_LEN = y
 CONFIG_MBEDTLS_SSL_OUT_CONTENT_LEN = 2048
重新运行应用程序以更新堆利用率统计信息，如下所示：
任务的内存使用率统计：
 || 任务         | 峰值 DRAM | 峰值 IRAM ||
 || aws_iot_task | 48784     | 0        ||
 || tiT          | 3892      | 0        ||
 || wifi         | 30724     | 0        ||

系统的内存使用率统计：
 || 小可用 DRAM | 小可用 IRAM ||
 || 177972        | 76136        ||
从上面可以看出，我们从 aws_iot_task 任务中获得了约 14KB 的内存，因此小可用 DRAM 数量也相应的增加了。
动态缓冲区分配特性
在 TLS 连接期间，mbedTLS 堆栈从初始握手阶段开始在整个会话期间保持动态分配功能的开启。这些分配包括 TLS IN/OUT 缓冲区，对端证书，客户端证书，私钥等。在此特性中（即将成为乐鑫科技代理公司蓝牙wifi二合一模块ESP-IDF 的一部分），mbedTLS 内部 API 已被粘合（使用 SHIM 层），因此可以确保只要资源使用（包括数据缓冲区）完成，就会立即释放相关的动态内存。
这大大有助于减少 TLS 连接时堆内存峰值利用率。由于频繁进行动态内存操作（按需资源使用策略），因此对性能有微小的影响。此外，由于与身份验证凭据（证书，密钥等）有关的内存已被释放，因此在 TLS 尝试重新连接（如果需要）期间，应用程序需要确保再次填充 mbedTLS SSL 上下文。
应用程序中启用相应的配置：
＃允许对 mbedTLS 使用动态缓冲策略
 CONFIG_MBEDTLS_DYNAMIC_BUFFER = y
 CONFIG_MBEDTLS_DYNAMIC_FREE_PEER_CERT = y
 CONFIG_MBEDTLS_DYNAMIC_FREE_CONFIG_DATA = y
重新运行应用程序以更新堆利用率统计信息，如下所示：
任务的内存使用率统计：
 || 任务         | 峰值 DRAM | 峰值 IRAM||
 || aws_iot_task | 26268     | 0        ||
 || tiT          | 3648      | 0        ||
 || wifi         | 30724     | 0        ||

系统的内存使用率统计：
 || 少可用DRAM | 小可用IRAM ||
 || 203648       | 76136        ||
从上面可以看出，我们从 aws_iot_task 任务中获得了约 22KB 的内存，因此小可用 DRAM 数量也相应增加。
网络特定（优化）
Wi-Fi / LwIP 配置
我们可以进一步优化 Wi-Fi 和 LwIP 配置以减少内存使用，但以牺牲一些性能为代价。我们将减少 Wi-Fi TX 和 RX 缓冲区，并且通过将一些关键代码路径从网络子系统迁移到指令存储器（IRAM）来尝试平衡二者。
​从性能方面考虑，在默认网络配置下，平均 TCP 吞吐量接近 〜20Mbps，但在下面的配置下，它将接近 〜4.5Mbps，这仍然足以满足典型的 IoT 用例。
应用程序中启用相应的配置：
＃小的 Wi-Fi / lwIP 的配置
 CONFIG_ESP32_WIFI_STATIC_RX_BUFFER_NUM = 4
 CONFIG_ESP32_WIFI_DYNAMIC_TX_BUFFER_NUM = 16
 CONFIG_ESP32_WIFI_DYNAMIC_RX_BUFFER_NUM = 8
 CONFIG_ESP32_WIFI_AMPDU_RX_ENABLED =
 CONFIG_LWIP_TCPIP_RECVMBOX_SIZE = 16
 CONFIG_LWIP_TCP_SND_BUF_DEFAULT = 6144
 CONFIG_LWIP_TCP_WND_DEFAULT = 6144
 CONFIG_LWIP_TCP_RECVMBOX_SIZE = 8
 CONFIG_LWIP_UDP_RECVMBOX_SIZE = 8
 CONFIG_ESP32_WIFI_IRAM_OPT = Y
 CONFIG_ESP32_WIFI_RX_IRAM_OPT = Y
 CONFIG_LWIP_IRAM_OPTIMIZATION = Y
重新运行应用程序以更新堆利用率统计信息，如下所示：
任务的内存使用率统计：
 || 任务         | 峰值 DRAM | 峰值 IRAM||
 || aws_iot_task | 26272     | 0        ||
 || tiT          | 4108      | 0        ||
 || wifi         | 19816     | 0        ||

 系统的内存使用率统计：
 || 少可用DRAM | 小可用 IRAM ||
 || 213712       | 62920        ||
从上面的日志可以看出，我们获得了大约 9KB 的额外 DRAM 供应用程序使用。对总 IRAM 的影响（减少）是因为我们将关键代码路径从网络子系统移到了该区域。
系统特定（优化）
使用 RTC（快速）内存（仅单核）
从前述的内存分解图可以看到，有一个有用的 8KB RTC 快速内存（相当快），它一直处于空闲状态并且没有被充分利用。ESP-IDF 很快将具有启用 RTC 快速内存以进行动态分配的功能。该选项存在于单核配置中，因为 RTC 快速内存只能由 PRO CPU 访问。
已经确定的是 RTC 快速内存将用作第一个动态存储范围，并且大多数启动，预调度程序代码/服务都将占据该范围。这样就不会因为内存的时钟速度（稍微慢一点）而影响应用程序代码的性能。
由于对该区域没有访问限制，因此从功能上我们以后将其称为 DRAM 。
让我们使用此功能重新运行我们的应用程序并收集内存数据。
应用程序中启用相应的配置：
＃将RTC内存添加到系统堆中
 CONFIG_ESP32_ALLOW_RTC_FAST_MEM_AS_HEAP = y
重新运行应用程序以更新堆利用率统计信息，如下所示：
任务的内存使用率统计：
 || 任务         | 峰值 DRAM | 峰值 IRAM||
 || aws_iot_task | 26272     | 0 ||
 || tiT          | 4096      | 0 ||
 || wifi         | 19536     | 0 ||

 系统的内存使用率统计：
 || 少可用 DRAM | 小可用 IRAM ||
 || 221792        | 62892         ||
从上面的日志可以看出，我们获得了 8KB 的额外 DRAM 供应用程序使用。
使用指令存储器（IRAM，仅单核）
​到目前为止，我们已经看到了允许终端应用程序从 DRAM（数据内存）区域获得更多内存的不同配置选项。沿着类似的路线继续，应该注意到的是 IRAM（指令内存）还剩余充足的空间，但是由于 32 位地址和大小对齐的限制，它不能被用作通用目的。
如果访问（加载或存储）来自 IRAM 区域且大小未按字对齐，则处理器将生成 LoadStoreError(3) exception 异常；
如果访问（加载或存储）来自 IRAM 区域且地址未字对齐，则处理器将生成 LoadStoreAlignmentError(9) exception 异常。
在 ESP-IDF 的此特殊特性中，上面提到的未对齐访问异常已通过相应的异常处理程序进行了修复，因此程序能够正确的执行。但是，对于每个（受限制的）加载或存储操作，这些异常处理程序多可能消耗 167 个 CPU 周期。因此，使用此功能时可能会导致性能显著下降（与 DRAM 访问相比）。
可以按以下方式使用此内存区域：
先通过使用堆分配器中称为MALLOC_CAP_IRAM_8BIT 的 API，以使用特殊功能区域；
其次使用提供的链接器属性 IRAM_DATA_ATTR 和 IRAM_BSS_ATTR 将 DATA/BSS 重定向到此区域。
局限性：
该存储区预不能用于 DMA 目的；
该内存区域不能用于分配任务堆栈。
​在讨论该内存区域的使用以及理解性能损失的同时，发现 TLS IN/OUT（根据我们的配置值缓冲区可以是 16KB/2KB）缓冲区是从该区域分配的潜在候选对象之一。在其中一项实验中，将 TLS IN/OUT 缓冲区移至 IRAM 后，通过 TLS 连接传输 1 MB 文件的时间从约 3 秒增加到 5.2 秒。
也可以将所有 TLS 分配重定向到 IRAM 区域，但这可能会对性能产生更大的影响，因此此功能仅重定向大小大于或等于 TLS IN 或 OUT 小缓冲区的缓冲区（在我们的示例中，阈值为 2 KB）。
让我们使用此功能重新运行并收集内存数据
应用程序中启用相应的配置：
＃允许将 IRAM 用作 8 位可访问区域
 CONFIG_ESP32_IRAM_AS_8BIT_ACCESSIBLE_MEMORY = y
 CONFIG_MBEDTLS_IRAM_8BIT_MEM_ALLOC = y
重新运行应用程序中更新的堆利用率统计信息，如下所示：
任务的内存使用率统计：
 || 任务         | 峰值 DRAM | 峰值 IRAM||
 || aws_iot_task | 17960     | 21216    ||
 || tiT          | 3640      | 0        ||
 || wifi         | 19536     | 0        ||

系统的内存使用率统计：
 || 少可用DRAM | 小可用IRAM ||
 || 228252       | 40432        ||
从上面的日志可以看出，我们为应用程序又增加了约 7KB 的额外 DRAM 。请注意，即使我们已将所有超过 2KB 阈值的分配重定向到 IRAM ，但 DRAM 区域（另一个局部大值）仍发生许多较小的（同时发生的）分配，因此有效增益低于实际值。如果附加的性能影响是可以接受的，则可以将所有 TLS 分配重定向到 IRAM ，并从 DRAM 区域获得至少 10-12KB 的内存。
总结
通过配置选项对各种功能进行选择从而实现对应用程序的完全控制，是 ESP-IDF 的重要功能之一；
通过上述实践，我们系统地评估了乐鑫科技代理公司蓝牙wifi二合一模块ESP-IDF 中的各种特性和配置选项，从而将终端应用程序的 DRAM （快的内存）预算提高了63 KB （小空闲 DRAM 大小从 ~160KB 增加到 ~223KB）；
其中一些配置选项仅适用于单核配置（在标题本身中已进行了标记），但即使在双核配置中，其余选项也可用于节省内存；
对性能无严格要求的模块（如终端应用程序的日志记录和诊断），还可以将指令存储器（IRAM）用作 8 位可访问区域；
一旦实现了所需的系统特性后，建议禁用上面实践中使用的某些调试功能，例如堆任务跟踪，以减少元数据开销（并进一步增加内存预算）。
引用
修改后的 subscription_publish 示例以及终 sdkconfig.defaults 文件可以在 这里 找到；
这个应用程序应该基于此处 ESP-IDF 副本和特性分支来构建。