硬件开发手记

主题

ESP32-C3的相关知识 ​

ESP32-C3技术规格书
ESP32-C3技术参考手册
esp32-c3-wroom-02模组手册

ESP32-C3简介 ​

FreeRTOS相关的知识 ​

ESP-IDF开发方法 ​

主要是采用示例程序中用得着的代码,进行复制粘贴,并修改到自己的项目中去,如果用得多个示例中的代码,那就多个示例中复制粘贴。不用太纠结是如何实现的.只要会用,好用就可以了.

ESP-IDF开发注意点 ​

添加新的需要编译的文件时,需要在main目录下的CMakeLists.txt文件中添加对应的 "SRCS" 中,对于 "头文件",则需要添加至 "INCLUDE_DIRS" 中。如果用到示例中一些组件,可以还需要学着示例的样子添加至 PRIV_REQUIRES 中。

如果感觉有些参数需要调整,也可以自己编写一下'Kconfig.projbuild'文件(参考),然后通过menuconfig进行配置。 这样以后要使用的时候,就会非常方便.

如果有些模块没有对应的示例代码,那就想办法找第三方的代码,也是非常好的.多数情况下都不需要自己写驱动程序.

ESP-IDF开发环境 ​

ESP-IDF官方组件的使用方法 ​

  • 使用一个组件，首先要根据API文档，添加对应的REQUIRES 或是 PRIV_REQUIRES
    在对应的项目的main目录下的CMakeLists.txt文件中添加REQUIRES。例如：
    cmake
    idf_component_register(SRCS "main.c"
INCLUDE_DIRS "."
PRIV_REQUIRES esp_http_client esp_wifi)
  • 在自已的项目中，添加对应的头文件(如#include "esp_wifi.h")，然后就可以使用了。如果上一步，没有做的话，这一步的头文件就不会被识别。
  • 编译系统会把 esp_wifi 组件的公共头文件路径添加到当前组件的编译环境里。这样，在当前组件的源文件里就能直接包含 esp_wifi 组件的头文件，而无需指定完整路径。
  • 编译时，会自动下载对应的组件。

说明:

  • 编译系统会把 esp_wifi 组件纳入到当前组件的私有依赖列表中。这意味着在编译当前组件时，esp_wifi 组件的源文件会被编译，并且其生成的目标文件会被链接到当前组件里。
  • 在 CMakeLists.txt 中使用 PRIV_REQUIRES esp_wifi 主要是为了在编译和链接阶段让当前组件能够使用 esp_wifi 组件的功能，包括访问其头文件和链接其库文件，而不是为了让 menuconfig 显示配置选项。

REQUIRES 和 PRIV_REQUIRES 的区别： ​

  • REQUIRES：用于声明组件的公共依赖，这些依赖会被传递给依赖当前组件的其他组件。
  • PRIV_REQUIRES：用于声明组件的私有依赖，这些依赖仅用于当前组件的编译和链接，不会被传递给其他组件。

通过一个具体的例子来说明 REQUIRES 和 PRIV_REQUIRES 在 ESP-IDF 中的实际应用。 示例项目结构 假设我们有一个简单的项目，包含以下组件： driver 组件：负责硬件驱动功能。 sensor 组件：负责传感器数据采集功能。 app 组件：主应用程序组件，使用了 driver 和 sensor 组件的功能。 项目结构如下：

project/
├── components/
│   ├── driver/
│   │   ├── CMakeLists.txt
│   │   ├── driver.h
│   │   └── driver.c
│   ├── sensor/
│   │   ├── CMakeLists.txt
│   │   ├── sensor.h
│   │   └── sensor.c
│   └── app/
│       ├── CMakeLists.txt
│       ├── app.h
│       └── app.c
└── CMakeLists.txt

组件功能和依赖关系
driver 组件：提供硬件驱动功能。 公共头文件 driver.h 提供了驱动的接口函数。
源文件 driver.c 实现了这些接口函数。没有依赖其他组件。

sensor 组件：负责传感器数据采集。
公共头文件 sensor.h 提供了传感器数据采集的接口函数。
源文件 sensor.c 实现了这些接口函数，并且在实现过程中调用了 driver 组件的功能。依赖于 driver 组件。

app 组件：主应用程序。
公共头文件 app.h 提供了应用程序的接口函数。 源文件 app.c 实现了这些接口函数，并且在实现过程中调用了 sensor 组件的功能。依赖于 sensor 组件。 CMakeLists.txt 文件的编写

driver/CMakeLists.txt

cmake
idf_component_register(
    SRCS "driver.c"
    INCLUDE_DIRS "."
)

driver 组件没有依赖其他组件，因此没有使用 REQUIRES 或 PRIV_REQUIRES。

sensor/CMakeLists.txt

cmake
idf_component_register(
    SRCS "sensor.c"
    INCLUDE_DIRS "."
    PRIV_REQUIRES driver
)

sensor 组件在 sensor.c 中调用了 driver 组件的功能，但 sensor.h 中没有包含 driver.h。 因此，sensor 组件对 driver 的依赖是私有的，使用 PRIV_REQUIRES 声明。

app/CMakeLists.txt

cmake
idf_component_register(
    SRCS "app.c"
    INCLUDE_DIRS "."
    REQUIRES sensor
)

app 组件在 app.c 中调用了 sensor 组件的功能，并且 app.h 中可能包含了 sensor.h。因此，app 组件对 sensor 的依赖是公共的，使用 REQUIRES 声明。

依赖关系的传递 app 组件通过 REQUIRES sensor 声明了对 sensor 组件的依赖。
sensor 组件通过 PRIV_REQUIRES driver 声明了对 driver 组件的依赖。

在编译时： app 组件的编译器会包含 sensor 组件的头文件路径。sensor 组件的编译器会包含 driver 组件的头文件路径，但 app 组件不会直接包含 driver 组件的头文件路径。

总结 REQUIRES：用于声明组件的公共依赖，这些依赖会被传递给依赖当前组件的其他组件。 PRIV_REQUIRES：用于声明组件的私有依赖，这些依赖仅用于当前组件的编译和链接，不会被传递给其他组件。 通过合理使用 REQUIRES 和 PRIV_REQUIRES，可以确保项目的依赖关系清晰，同时优化编译效率。

ESP32-C3的烧录方法 ​

  • 在开发中进行烧录，直接使用openOCD进行烧录。
  • 在生产过程中进行烧录，使用JTAG接口进行烧录。（这是重点）
  • 生产中烧录，一般在windows系统下，所以采用的工具也都是在windows下的。
  • 使用USB转TTL工具进行烧录，如果是官方的开发板，内置了usb转ttl工具，也支持自动烧录模式转换，所以使用起来非常方便。
  • 使用ESP32-C3芯片内置了JTAG接口，所以可以直接将USB的四芯线(VCC,GND,D+,D-)连接到ESP32-C3(18,19脚)上，然后使用JTAG工具进行烧录。这种模式下不需要进入烧录模式。

ESP32-C3 USB-JTAG接口的使用
参考文档
视频教程-烧录方法
使用云烧录方案

云烧录方案 可以在没有开发环境的情况下，查看设备的运行信息。也可以用来烧录数据。非常方便。

  • 先连接设备
  • 再打开终端
  • 就可以查看设备的运行信息。

烧录的重点 ​

要将烧录的bin文件的烧录地址写对了。

序号名称地址
1bootloader.bin0x0
2partitions.bin0x8000
3开发程序.bin0x10000

以上三个，不能错误，否则烧录会报错。这三个文件，是烧录的要点，一个都不能少。文件保存于build文件夹下。可以搜索一下开发目录下，一定可以找到。

烦死人的红色波浪线 ​

有时候会出现很多的波浪线,但是编译不受影响,但是很烦人. 其实原因是vscode编译eps32使用的是cmake的进行编译,出现波浪线是因为cmake编译的时候,没有找到对应的头文件. 主要是因为.vscode下而把 c_cpp_properties.json 的文件里面,没有将esp-idf的相关头文件添加进去. 但是编译器知道这个事,所以编译不会出错.只是显示错误. 解决方法: 在c_cpp_properties.json文件中添加以下内容:

json
{
"configurations": [
  {
    "name": "ESP-IDF",
    "compilerPath": "${config:idf.toolsPath}/tools/xtensa-esp-elf/esp-14.2.0_20241119/xtensa-esp-elf/bin/xtensa-esp32-elf-gcc",
    "compileCommands": "${config:idf.buildPath}/compile_commands.json",
    "includePath": [
      "${config:idf.espIdfPath}/components/**",
      "${config:idf.espIdfPathWin}/components/**",
      "${config:idf.toolsPath}/tools/xtensa-esp-elf/esp-14.2.0_20241119/xtensa-esp-elf/xtensa-esp-elf/include/**",
      "${config:idf.toolsPath}/tools/xtensa-esp-elf/esp-14.2.0_20241119/xtensa-esp-elf/lib/gcc/xtensa-esp-elf/14.2.0/include/**",
      "${workspaceFolder}/**"
    ],
    "browse": {
      "path": [
        "${config:idf.espIdfPath}/components",
        "${config:idf.espIdfPathWin}/components",
        "${config:idf.toolsPath}/tools/xtensa-esp-elf/esp-14.2.0_20241119/xtensa-esp-elf/xtensa-esp-elf/include",
        "${config:idf.toolsPath}/tools/xtensa-esp-elf/esp-14.2.0_20241119/xtensa-esp-elf/lib/gcc/xtensa-esp-elf/14.2.0/include",
        "${workspaceFolder}"
      ],
      "limitSymbolsToIncludedHeaders": true
    },
    "defines": [
      "ESP_PLATFORM",
      "IDF_VER=\"${config:idf.espIdfVersion}\""
    ],
    "cStandard": "c17",
    "cppStandard": "c++17"
  }
],
"version": 4
}

修改后,重新编译,就没有波浪线了.

小知识: ​

在VSCode的C/C++配置文件中，"browse" 设置是用来控制IntelliSense的浏览功能的。让我详细解释一下它的作用：

"browse" 的作用 ​

"browse" 配置主要用于：

  1. 符号导航 - 当你点击某个函数或变量跳转到定义时，VSCode会搜索这些路径
  2. 代码补全 - 提供更准确的代码补全建议
  3. 错误检测 - 在这些路径中查找符号，帮助识别未定义的变量或函数
  4. 代码索引 - IntelliSense后台建立索引时会扫描这些路径

"browse" 与 "includePath" 的区别 ​

  • "includePath"：仅指定预处理器 #include 指令可以找到头文件的路径，影响头文件包含
  • "browse"：指定IntelliSense进行符号查找和索引的路径，影响代码导航功能

使用场景 ​

"browse" 在以下情况特别有用：

  1. 大型项目 - 当项目包含大量头文件，但只有一部分会被实际包含时
  2. 第三方库 - 需要在其中查找函数定义但不一定直接包含头文件
  3. 符号导航 - 当你想让F12（跳转到定义）等功能能够定位到特定路径的符号
  4. 性能优化 - 限制IntelliSense扫描范围，提高性能

在你的ESP-IDF项目中，"browse" 配置确保VSCode可以在ESP-IDF组件和工具链目录中找到系统头文件的定义，即使这些文件不会被直接包含在你的项目中。

你当前配置中的"limitSymbolsToIncludedHeaders"设为true意味着IntelliSense只会对那些被实际包含的头文件进行符号解析，这可以提高性能，但也可能导致某些符号无法被正确解析。