ESP32-C3 学习测试到今天，一直在使用 ESP-IDF 的框架，
但是还从来没有注意过工程结构，遇到复杂一点的项目，工程结构就显得太乱了，
本文就来了解下 ESP-IDF 工程结构。
content
foreword
In addition to the Bluetooth test, we have already made a small IoT application for the use of ESP32-C3:
However, in actual operation, we add application code directly in the main.c file in most cases. When encountering a more complex project with a little more driver files, the project structure is messy, non-standard and inconvenient to transplant. In the project mentioned in the ESP32-C3 application article above, I did encounter the problem of adding files, so in order to avoid this basic problem, I have to have a good understanding of the ESP-IDF project structure.
The purpose of this article is to allow us to add our own engineering codes in a standardized manner through the understanding of the ESP-IDF engineering structure.
This article is based on the engineering structure of the VScode plugin (Ubuntu environment). See the following blog post for the environment setup:
1. Basic framework of ESP-IDF engineering
A standard engineering framework is shown in the following figure:
We will use the project that connects the ONENET platform through the MQTT protocol in the application chapter as a demonstration. Let's take a look at the overall framework first:
1.1 Files in the main project directory
Top-level CMakeLists.txt
The top-level project CMakeLists.txt file, which is the main file used by CMake to learn how to build the project, can set the global CMake variables of the project in
this file. Generally speaking, what we need to modify is the project name.
Top level Makefile
It seems that the content CMakeLists.txtis similar to the one in . In fact, this file is not needed when it is built by CMake. I tested and deleted this file, and it can be compiled normally, so this should be used by the old build method GUN Make. .
The current version of IDF (4.3+) does not need this file and can be deleted without modification.
sdkconfig
Project configuration file. This file is created or updated when idf.py menuconfig is executed, and the configuration information of all components in the project (including ESP-IDF itself) is saved in the file. The sdkconfig file may or may not be added to the project's source code management system.
The settings we need will be configured in menuconfig. This file is automatically updated after menuconfig is executed without modification.
1.2 Files in the main directory
main中的 CMakeLists.txt
The file that guides CMake, tells it .cand .hthe location of the file, there are several .cfiles under the directory, you have to add a few.
We need to modify this file. In the project, under the main folder, I put a few more .c files, and we need to add them all. If we put the header file in the same folder, it also needs to be modified, for example:
component.mk
The files used in GNU Make are not needed when building with CMake, just like the top-level Makefile above.
The current version of IDF (4.3+) does not need this file and can be deleted without modification.
Kconfig.projbuild
This is not a necessary file, its function is that it can be configured with menuconfig, which can be easily transplanted.
If the novice is not familiar with the writing of Kconfig, you can ignore it here for the time being. In the example project, some variables used are written to death without macro definitions.
If you have to learn to understand, you will use menuconfig configuration. After you are familiar with it, you can try to write it to facilitate project transplantation.
app_main.c
This is the main file of this project, and the code can be placed in it.
It should be noted that the above example has its own driver code:
our standard practice is to put it under the componentsdirectory and exist as a component, so we will move these files to the components directory below.
The entry function file is the main function file of the application written by yourself.
1.3 Files in the components directory
As we said before, components contains some custom components of the project, but it helps to build reusable code or import third party (not part of ESP-IDF) components.
Let's look at the overall framework under the components folder. In the example project, there is only one button subfolder (even the driver file of led_strip is placed directly under the button folder, because it was placed in another folder at that time. Compile error = = !):
component.mk
The files used in GUN Make are the same as the above component.mkfiles , and the files are not needed when building with CMake, so I don't care here.
component.mk is not required.
Kconfig
Kconfig.projbuildSame as above .
Learn to read, try to write, to facilitate project transplantation.
CMakeLists.txt in components
It is the main file for CMake to build the project. The rules are the same as CMakeLists.txt in main. This file is the key point.
The point! ! Learn to modify. Understand the component dependencies mentioned below!
component dependencies
The core of the CMakeLists.txt in the component, we must learn how to modify it in order to improve our own project, so we need to introduce the component dependencies, here the official explanation is more detailed, borrow the official website to introduce screenshots:
component dependency example:
Add components under VScode
In our use of the VScode plugin, we can quickly add components through instructions, as follows:
You can see the added standard component architecture.
In future projects, try to install this standard component architecture design.
2. Example of Engineering Adjustment
Through the above detailed introduction, even if we do not know the construction principle, we also have a certain understanding of the ESP-IDF project structure, and we can apply what we have learned.
2.1 Delete unnecessary files
The first step is to delete the above component.mkand the top level Makefile, and the readme is also deleted. At least the overall look is not so messy at the beginning, and then the compilation is normal:
2.2 Component adjustment
LED driver new components
The LED driver was actually used in the previous RMT application teaching blog post, but the official routine used at that time was the component generated by the template, so I didn't care about the structure, but when I wrote the application article, I copied the component directly under this project. There is indeed an error in the compilation, so it will be placed directly under the button folder at that time = =!
Now we need to move it out and use it as a separate component led_strip. In fact, it is still copied, as shown in the figure below:
After completion, the compilation is normal!
The key driver is placed in the corresponding component
Put the button driver my_button.cand my_button.hfiles under the main function under the button component folder, and go to the place where he should go:
the compilation is normal after completion!
Temperature and humidity drive new components
According to the standard component template, put the temperature and humidity driver in the newly created sht21 component folder:
the compilation is normal after completion!
2.3 The adjustment is completed
After completing the above steps, the adjustment of the example is completed. Let's take a look at the final project structure (it feels much more beautiful than before, I can't bear to write any comments~):
Epilogue
In order to reduce boilerplate files, Espressif has actually encapsulated many functions of CMake for the convenience of users.
The purpose of this article is to allow us to improve our engineering structure based on the ESP-IDF framework, and does not explain the construction principle of Cmake. If there is something inappropriate or not in place, please point it out!
After this blog post, the teaching examples of ESP32-C3 will follow this standard framework.
Thanks!