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

  

 

  
1
  
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文件，就得添加几个。

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

component.mk

GUN Make中使用的文件，通过CMake构建时文件都可以不需要，和上面的 顶层Makefile 一样。

现在版本的IDF（4.3+）不需要这个文件，可以删除，不用修改。

Kconfig.projbuild

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

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

app_main.c

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

需要说明的是，在上面示例中有自己的驱动代码：

我们规范的做法是放在 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 的核心，我们必须要学会如何修改，才能完善自己的工程，所以对于组件依赖我们需要但是介绍，这里官方的讲解比较详细，借用官网介绍截图说明：

组件依赖示例：

VScode下添加组件

在我们使用 VScode 插件中，可以通过指令快速添加组件，方法如下：

可以看到添加的标准组件架构。

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

二、工程调整示例

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

2.1 删除不需要的文件

第一步，把上面说的component.mk 和 顶层Makefile删除, readme也删除了，至少整体看上去，没有开始那么乱，然后编译正常：

2.2 组件调整

LED驱动新建组件

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

现在我们要把他移出来，单独作为一个组件led_strip，其实还是复制过来，如下图：

完成以后编译正常！

按键驱动放至对应组件

把主函数下面的按键驱动my_button.c和my_button.h文件放置 button 组件文件夹下面，去他该去的地方：

完成以后编译正常！

温湿度驱动新建组件

按照标准的组件模板，把温湿度的驱动程序放在新建的 sht21 组件文件夹中：

完成以后编译正常！

2.3 调整完成

完成上面步骤，对于示例的调整就算完成了，看看最后的工程结构（和以前比起来感觉漂亮多了，我都不忍心写任何注释上去~）：

结语

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

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

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

谢谢！

文章来源: blog.csdn.net，作者：矜辰所致，版权归原作者所有，如需转载，请联系作者。

原文链接：blog.csdn.net/weixin_42328389/article/details/123476507