> 文档中心 > 认识 ESP-IDF-v4.3+工程结构(带实际工程调整示例)

认识 ESP-IDF-v4.3+工程结构(带实际工程调整示例)

ESP32-C3 学习测试到今天,一直在使用 ESP-IDF 的框架,但是还从来没有注意过工程结构,遇到复杂一点的项目,工程结构就显得太乱了,本文就来了解下 ESP-IDF 工程结构。

目录

  • 前言
  • 一、ESP-IDF工程基本框架
    • 1.1 工程主目录下的文件
      • 顶层 CMakeLists.txt
      • 顶层 Makefile
      • sdkconfig
    • 1.2 main目录下的文件
      • main中的 CMakeLists.txt
      • component.mk
      • Kconfig.projbuild
      • app_main.c
    • 1.3 components目录下的文件
      • 组件中的 CMakeLists.txt
      • 组件依赖
      • VScode下添加组件
  • 二、工程调整示例
    • 2.1 删除不需要的文件
    • 2.2 组件调整
      • LED驱动新建组件
      • 按键驱动放至对应组件
      • 温湿度驱动新建组件
    • 2.3 调整完成
  • 结语

前言

除了蓝牙篇的测试,关于 ESP32-C3 的使用我们都已经做了一个小型的物联网应用了:

ESP32-C3入门教程 应用 篇(实例一、通过MQTT协议连接 ONENET 平台)

但是在实际操作时候,我们大多数情况下都是直接在 main.c 文件中添加应用代码,遇到复杂一点的项目多一点驱动文件,工程结构就显得很乱,不规范并且不方便移植。在上面 ESP32-C3 应用篇提到的工程中,我确实也遇到了文件添加的问题,所以为了避免这种基本问题的困扰,得好好的了解一下 ESP-IDF 工程结构。

本文的目的就在于通过 ESP-IDF 工程结构的认识,让我们可以自已可以规范的添加自己的工程代码。

本文是基于 VScode 插件的工程结构来说明(Ubuntu环境),环境搭建见下面博文:

ESP32-C3 VScode开发环境搭建(基于乐鑫官方ESP-IDF——Windows和Ubuntu双环境)

一、ESP-IDF工程基本框架

一个标准的工程框架如下图所示:
在这里插入图片描述
我们就用在应用篇中通过MQTT协议连接 ONENET 平台的工程来做示范说明,先来看看整体框架:
在这里插入图片描述

1.1 工程主目录下的文件

顶层 CMakeLists.txt

顶层项目 CMakeLists.txt 文件,这是 CMake 用于学习如何构建项目的主要文件,可以在这个文件中设置项目全局的 CMake 变量
在这里插入图片描述在这里插入图片描述
这个文件一般来说我们需要修改的是工程名字。

顶层 Makefile

看上去内容和 CMakeLists.txt 中的差不多,实际上这个文件通过CMake构建时文件都可以不需要,我测试了一下把这个文件删除,也能正常编译,所以这个应该是老的构建方式 GUN Make 需要用到的。
在这里插入图片描述
现在版本的IDF(4.3+)不需要这个文件,可以删除,不用修改。

sdkconfig

项目配置文件,执行 idf.py menuconfig 时会创建或更新此文件,文件中保存了项目中所有组件(包括 ESP-IDF 本身)的配置信息。 sdkconfig 文件可能会也可能不会被添加到项目的源码管理系统中。

我们需要的设置会在 menuconfig 中配置,此文件在执行完 menuconfig 后自动更新,不用修改。

1.2 main目录下的文件

main中的 CMakeLists.txt

给CMake指路的文件,,告诉它.c.h文件的位置,在目录下面有几个.c文件,就得添加几个。
认识 ESP-IDF-v4.3+工程结构(带实际工程调整示例)
在这里插入图片描述

这个文件我们需要修改,工程中在 main 文件夹下面,我多放了几个.c文件,就需要都添加进去。如果我们把头文件放在同一个文件夹里,也需要修改,比如:
在这里插入图片描述

component.mk

GUN Make中使用的文件,通过CMake构建时文件都可以不需要,和上面的 顶层Makefile 一样。
在这里插入图片描述
现在版本的IDF(4.3+)不需要这个文件,可以删除,不用修改。

Kconfig.projbuild

这不是一个必须的文件,它的作用就是可以配合 menuconfig 进行配置,可以方便移植。

如果新手不太熟悉 Kconfig 的书写,这里暂时可以不关注,在示例工程中,一些用到的变量就自己写死,而不用宏定义。
在这里插入图片描述 有了要学会看懂,会使用 menuconfig 配置。熟悉了以后,可以尝试书写,方便项目移植。

app_main.c

这就是这个项目工程的main文件,代码放里面就行了。

需要说明的是,在上面示例中有自己的驱动代码:
认识 ESP-IDF-v4.3+工程结构(带实际工程调整示例)
我们规范的做法是放在 components 目录下面,作为组件形式存在,所以下面会把我们会把这几个文件移动到 components 目录下面。

入口函数文件,就是自己写应用的main函数文件。

1.3 components目录下的文件

我们以前说过,components 包含了项目的部分自定义组件,但它有助于构建可复用的代码或者导入第三方(不属于 ESP-IDF)的组件。

再看看 components 文件夹下面的整体框架,在示例项目中,只有一个 button 子文件夹(就连led_strip的驱动文件我都直接放置button文件夹下面,因为当时放在另外一个文件夹编译出错= =!):
在这里插入图片描述

component.mk

和上面的 component.mk 文件一样GUN Make中使用的文件,通过CMake构建时文件都可以不需要,所以这里不管。

component.mk 不需要。

Kconfig

和上面的 Kconfig.projbuild 一样。
在这里插入图片描述
学会看懂,尝试书写,方便项目移植。

组件中的 CMakeLists.txt

是 CMake 构建项目的主要文件,规则和 main 中 CMakeLists.txt 一样,这个文件是重点。
在这里插入图片描述
重点!!学会修改。理解下面说的组件依赖!

组件依赖

组件中的 CMakeLists.txt 的核心,我们必须要学会如何修改,才能完善自己的工程,所以对于组件依赖我们需要但是介绍,这里官方的讲解比较详细,借用官网介绍截图说明:
在这里插入图片描述
组件依赖示例:
在这里插入图片描述
在这里插入图片描述
认识 ESP-IDF-v4.3+工程结构(带实际工程调整示例)

VScode下添加组件

在我们使用 VScode 插件中,可以通过指令快速添加组件,方法如下:
在这里插入图片描述
可以看到添加的标准组件架构。

在以后自己的工程中,尽量安装这个标准组件架构设计。

二、工程调整示例

通过上面的详细介绍,即便不知道构建原理,我们也对 ESP-IDF工程结构有了一定的认识,学以致用,我们通过上面的认识,来对上面示例工程进行一定的修改。

2.1 删除不需要的文件

第一步,把上面说的component.mk 和 顶层Makefile删除, readme也删除了,至少整体看上去,没有开始那么乱,然后编译正常:
在这里插入图片描述

2.2 组件调整

LED驱动新建组件

LED驱动其实在前面 RMT应用 教学博文中使用过,不过当时是使用的官方例程为模板生成的组件,所以并没有关心结构,但是在我写应用篇的时候,把组件拷贝到本项目下面直接编译确实有错误,所以当时才会直接放置 button 文件夹下面 = =!

现在我们要把他移出来,单独作为一个组件led_strip,其实还是复制过来,如下图:
在这里插入图片描述
完成以后编译正常!

按键驱动放至对应组件

把主函数下面的按键驱动my_button.cmy_button.h文件放置 button 组件文件夹下面,去他该去的地方:
在这里插入图片描述
完成以后编译正常!

温湿度驱动新建组件

按照标准的组件模板,把温湿度的驱动程序放在新建的 sht21 组件文件夹中:
在这里插入图片描述
完成以后编译正常!

2.3 调整完成

完成上面步骤,对于示例的调整就算完成了,看看最后的工程结构(和以前比起来感觉漂亮多了,我都不忍心写任何注释上去~):
在这里插入图片描述

结语

乐鑫官方为了减少样板文件,其实也封装了 CMake 的许多功能,目的在于给与用户方便。

本文的目的在于让我们能够基于 ESP-IDF 框架,完善自己的工程结构,并没有对 Cmake 的构建原理做说明。如果有不妥当,不到位的地方,还请指出!

在本博文之后,ESP32-C3 的教学实例,都会按照这个标准框架进行。

谢谢!