ESP32 开始主推以 FreeRTOS 为基础的 IDF 框架，
我还没有深入考察其源代码。
【 在 feiy (万事皆相通) 的大作中提到: 】
: 标 题: Re: 主题:小白弱问: ESP32比STM32差吗？
: 发信站: 水木社区 (Thu May 21 08:38:51 2020), 站内 [累计积分奖励: 2000/0]
:
: esp32和esp8266其实是一脉相承的，其代码执行架构都是
:
: (1)片上ROM由芯片厂家预制一段代码，存放第一步启动代码，进行启动模式判断选择(从FLASH启动/SDIO启功/UART启动?)(如果是从外部FLASH加载代码，就会负责从外部FLASH搬运代码到iRAM里执行；若是从SDIO或UART启动，就会启动相应的协议接受指令，或进行代码搬运，或套接响应基本命令)，以及一些厂家认为用户不用改可直接用的标准库函数，诸如os_strcpy()，这些函数会被/可被用户SDK和外部用户程序调用。
:
: 片上ROM的代码，厂家不对外公开，但可反汇编。实际也可改写，但一般人弄不到改写的方法。所以实际等同于MaskROM。
:
: 风险：有一定比例的基于esp8266和esp32芯片的模块，突然会出现异常，特征表现为串口输出提示在片上ROM启动阶段异常，就是因为片上ROM里的固件损坏了，只有/只要换个芯片就好了。其实，刷一下片上ROM也可以修复。
:
: (2) 若从外部FLASH加载代码，在外部FLASH里存放用户代码。当然，这里所谓的“外部FLASH”说的是用户可用的FLASH，SOC化现在许多芯片也将过去常放在主芯片封装之外的FLASH给封装进来。比如esp8285=esp8266+SPI FLASH。
:
: 用户代码包括两类，一类是乐鑫提供的SDK库，实现诸如网络射频等核心操作，这类是真正库形式存在的文件，和STM32的源码可见的库不同，用户是直接看不见这些库的源码的；另一类是用户自己基于SDK库提供的API编写应用层的代码。
:
: 乐鑫所提供的SDK库的特点是：(1)内容 不可见 (2)留给用户的可调试可诊断接口极其匮乏有限 (3)BUG极多
:
: 如此特征SDK库的存在，导致了两个问题：(1)用户的开发，不仅对寄存器隔离，甚至对中间层也隔离，若出了意外，用户的调试定位将会很困难；(2) 使用esp8266和esp8266的产品，大多数性能稳定性很差，BUG很多(业界有种共识，芯片本身还不错，可能可以打75分-80分，但SDK库太烂，只能打40-50分，结果导致产品差，只能降维使用。用得较好的极少部分人，多是舍弃其SDK自己重来的)。
:
: 回到主题，作单片机开发为何选STM32而不用ESP32？除了楼上诸位提到的几点，我这里补充几点：
: (1) esp32和esp8266一样，发热量高，厂存在一些芯片级的致命BUG。毕竟不如标准化且通过几十年几代演变无数用户应用的大厂方案，来得成熟稳定。
: (2) IO资源和标准接口相对少，功能模块基本较少，非通用型单片机，若单厂子作为一款单片机来衡量，考虑点较少，属较次排尾的一档。
:
: (3) 开发环境与调试接口不方便，主流是linux(或eclips变种)及串口打印调试，“JTAG”不支持或使用不方便，暂时还没法象单片机开发那样单调试
: (4) SDK库封装不可见且可诊断性极差，要命的是存在较多的BUG，用户没法改只有靠定位到属SDK的BUG后自己想办法规避，不如普通通用型单片机透明到底(寄存器级别)，数据手册也不透明(只到API级别，少数寄存器被公开也多是极客们反向工程的结果)。
:
: 这样的芯片方案，和STM32之类的通用单片机通用场合对照，许多人不会用也很自然了。除非是专用场合，比如WIFI，其他功能较少，只是基本的串口和几个IO控制，若想省个单片机，那么可以试一试让其作单片机主机。
:
: 【 在 intron 的大作中提到: 】
: : 手册说得很明白：
: :
: : ROM 是用来存放“程序启动和内核功能调用”，
: : ...................
: --来自微水木3.5.1
: --
: ※ 修改:·feiy 于 May 21 09:35:04 2020 修改本文·[FROM: 115.171.25.*]
: ※ 来源:·水木社区
http://m.newsmth.net·[FROM: 115.171.25.*]
--
修改:feiy FROM 115.171.25.*
FROM 111.196.243.*