gzxb1995的博客

esp sleep又可以进一步细分为两层，分别是软件sleep flow以及最终落实到硬件寄存器的rtc sleep。这套电源管理在软件层面怎么使用呢？更具体的内容将在后续章节介绍。

【代码】【无标题】

idle task，顾名思义，就是在系统空闲，也即没有任何任务就绪的情况下执行的任务。为什么需要idle task呢，就我的理解来看，RTOS（不仅限于freeRTOS）跑起来之后，某个固定的时刻要么在中断上下文，要么在任务上下文（这里不考虑更复杂支持特权分离的操作系统）。如果没有idle task，那么在所有task都处于非就绪态时，RTOS的调度器将陷入没有task可调度的困境。idf在启动阶段会进行一系列的初始化，并最终启动freeRTOS。这里我们主要关注的是idle task。

先概括的介绍一下IDF电源管理组件中的电源锁与动态频率切换。对主机CPU有了解的都知道，像Intel的酷睿处理器有个功能，CPU非常聪明，可以在繁忙（需要高性能）的时候抬高频率，在不忙的时候降低频率，这样在保证用户体验的同时还节省了能耗、降低了对散热系统的要求。Intel的CPU的睿频功能主要是硬件完成的，esp系列芯片当然没有这么强大的功能，不过IDF通过软件实现了类似的功能（当然和睿频比是比较粗浅的）。实现动态频率切换的关键在于。到底什么是电源锁呢？不妨举个具体的例子来说明。

RTC硬件并无deep sleep/light sleep之分。这两个sleep分类只是软件上的，软件通过下电的电源域不同来区分，但实际上，两者的本质区别在于现场是否可恢复。light sleep是现场可恢复的sleep，因此从哪里睡下去就会在哪里醒来继续运行。deep sleep是现场不可恢复的sleep，包括内存在内的大多数电路都会掉电，因此醒来只能从头开始跑。简单的看一下deep sleep的接口......*//* 软件意义上开始deep sleep的点 */

当我们为芯片设计外围电路时，必然会设计供电电路，这是芯片能正常工作的前提。通常是电源电压通过一个稳压电路之后给到芯片的供电引脚。以S3为例，下面是S3的引脚图：其中以VDD打头的就是供电引脚。比如VDD3P3VDDA等。供电引脚不止一个，这些供电引脚有什么区别呢？不难猜到，不同的供电引脚为芯片内部不同的硬件模块供电，比如VDDA是给芯片中的模拟电路供电的，而VDD3P3则是给数字电路供电的。我不是十分肯定这样设计的原因，猜测这种区分是为了供电的稳定。

目录1 堆调试功能的使能1.1 通过Kconfig使能1.2 使能之后源码层面的变化2 堆调试功能——POISONING3 堆调试功能——TRACE4 堆调试功能的使用经验参考1 堆调试功能的使能1.1 通过Kconfig使能idf提供了两种堆调试机制，POISONING以及TRACE。默认情况下，堆调试是未使能的。可以在menuconfig中配置使能，位置在：Component configHeap memory debuggingPOISONING默认是no poisoning，但

目录1 堆的初始化概览2 堆的初始化源码分析2.3.2.2 堆的初始化3 归还启动栈参考1 堆的初始化概览2 堆的初始化源码分析2.3.2.2 堆的初始化do_core_init会调用heap_caps_init初始化堆。简单浏览一遍这个函数：void heap_caps_init(void){ /* 获取所有可以作为堆的memory regions */ size_t num_regions = soc_get_available_memory_region_max_count

目录1 最初还不是tlsf2 为什么要引入tlsf3 idf中使用的tlsf算法的设计与实现4 源码走读参考1 最初还不是tlsf2 为什么要引入tlsf3 idf中使用的tlsf算法的设计与实现4 源码走读参考[1] 半文钱的博客[2] upstream所在的github地址注意事项放到内存调试去说：用户需要关注的：内存的硬件特性（caps）内存的访问速度内存是否支持原子操作内存是否可以由CPU直接访问用户在使用时：用户自己也要对自己的应用需要使用的内存做一些安排，有的内存比

目录1 内存的分类2 内存的特性3 软件对内存的描述4 参考1 内存的分类2 内存的特性3 软件对内存的描述4 参考[1] esp系列芯片的TRM[2] esp-idf源码

目录1 为什么要封装2 先看结构2.1 multi heapnote1note22.2 heap caps2.3 层次关系3 再看接口3.1 内存的申请3.2 内存的释放3.2 堆完整性检测3.3 其它参考1 为什么要封装封装通常会降低效率，但能够带来诸如通用性提升等好处，idf在tlsf的基础上增加封装，其作用可以概括为以下两点：上下层接口分离，上层接口和底层实际使用的内存管理算法无关，这样，以后有更优秀的算法，也可以很方便移植单纯的tlsf没办法满足idf的需要，比如不支持内存的caps，没有

1 目标相关博客的目标：理清楚idf的内存管理组件——设计与实现使自己能够熟练使用idf的内存管理机制为对此感兴趣的后来人提供一个高效的引导2 规划所有内容分为5部分：esp-idf的内存管理——esp系列芯片的内存：内存管理是用来管理内存的，当然有必要了解esp系列芯片使用的内存都有怎样的特性，这是进一步介绍如何管理内存的前提。esp-idf的内存管理——tlsf算法：idf最初使用内存管理算法并非tlsf，因此有必要关注一下为什么转向tlsf，以及tlsf本身的设计与实现。esp

目录1 esp32 series的中断控制器2 基于riscv和xtensa的芯片中断模块的区别3 使用esp32 series的中断3.1 中断的配置3.2 中断的处理3.2 中断的清除1 esp32 series的中断控制器和一些中断控制器固定了中断连线不同，esp32 series采用中断矩阵来连接中断源和中断输入引脚。这样做的好处是可以灵活配置中断源对应的中断号。至于中断控制器的内部实现，难以探究，且对于软件来说，也无需知道，通常我们关心的也就是中断控制器在逻辑上的等效，如下图所示：需要说明

1 目标写关于esp-idf的中断和异常管理的博客有两个目标：使自己能够熟练使用idf的中断和异常管理机制并了解其背后的实现帮助后来人节省时间，为esp-idf的推广做点微不足道的事情2 规划所有内容分为4部分：esp-idf的中断和异常管理——esp32 series的中断控制器，机制是用来管理硬件的，因此理解机制之前应该先理解硬件，本篇用于讲解esp32系列芯片的中断控制器。esp-idf的中断和异常管理——中断和异常的处理流程，本篇关注从中断或异常产生时会跳转到哪里，怎么一步步执行

目录1 中断/异常向量表1.1 xtensa1.2 riscv2 中断/异常的处理流程2.1 xtensa2.1.1 中断2.1.2 异常2.2 riscv2.2.1 中断2.2.2 异常3 注册中断/异常的handler3.1 xtensa3.1.1 异常3.1.2 中断3.2 riscv4 IDF的中断管理机制1 中断/异常向量表1.1 xtensa对于xtensa，中断/异常向量表借助链接脚本来实现。具体的说，中断/异常的入口（含最初的处理程序，不仅仅是一个地址）被等间隔的链接，以s3的链接脚本