When I first started CRSF for Arduino, I had to learn how to use PlatformIO. At the same time, I decided to make a project that integrates with PlatformIO and the Arduino IDE, and have it interoperate between both environments. I also wanted to make the project cool and interesting. Thus, CRSF for Arduino was born.
Fast forward a few months, and I have learned a lot. I now know how to properly configure PlatformIO to suit my own needs and my projects.
Now, the time has come to clean up CRSF for Arduino's janky mess that is its folder structure.
To-Do List
[x] Change all *.h file extensions in CRSF for Arduino to *.hpp.
[x] Streamline folder structure.
[x] Fix Arduino IDE compilation errors.
[x] Rewrite information in README.md to be more concise.
[x] Refactor platformio.ini configuration file.
[x] Put target development boards into their own *.ini file.
[x] Use main platformio.ini file only to decide how the environment should compile (EG "Production", "Debug" etc).
The problem
CRSF for Arduino's folder structure looks like this:
This is far from ideal, because one must go through folder after folder in order to get to anything.
This has implications for some compilers (for different targets) where the linkers freak out whenever a nested structure like this exists. The Arduino IDE is infamous for also completely losing its shit over nested folder structures. Especially one that is as unnecessarily complex as CRSF for Arduino.
It also makes it harder for yours truly to debug.
Plus, it makes it harder for you guys to find anything and read CRSF for Arduino's code base.
To drive the point home, here is a screenshot of the folder structure of another project of mine:
As you can see, despite there being more modules in the project, each folder structure is straightforward and everything is easily accessible.
Even the folder structure for all of my drivers in this project is way more accessible than what I have with CRSF for Arduino:
What I want to achieve
A streamlined folder structure similar to the examples above, that retains compatibility with both the Arduino IDE and PlatformIO.
IIRC, the Arduino IDE prefers a folder structure that looks like this:
I cannot guarantee that CRSF for Arduino will look exactly like this, however I will do all I can to streamline the folder structure.
Keep in mind that this may introduce breaking changes (of which I will list here, as and when they arise).
Additional
I keep referencing PlatformIO because it is now my IDE of choice. CRSF for Arduino is developed in PlatformIO, with Visual Studio Code being my code viewer and editor.
I am also aware that Linguist (GitHub's coding language detection software) has done this:
This is incorrect, because CRSF for Arduino is written exclusively in C++.
When I click on the 'C' component, I get this:
This is CRSF for Arduino's boiler plate. 😆
Hardly C (or any language at all).
This has come about because all of CRSF for Arduino's header files are *.h (which is a C extension) and not *.hpp (which is a C++ extension).
I have found out that it is bad practice to mix-and-match these headers, if it contains pure C++ code (which CRSF for Arduino does).
So, one of the first things I am doing with the restructure is changing the extensions in all of CRSF for Arduino's header files from *.h to *.hpp, and (hopefully) linguist will give a more accurate portrayal of the language that CRSF for Arduino is written in.
Overview
This will take some time to complete.
When I first started CRSF for Arduino, I had to learn how to use PlatformIO. At the same time, I decided to make a project that integrates with PlatformIO and the Arduino IDE, and have it interoperate between both environments. I also wanted to make the project cool and interesting. Thus, CRSF for Arduino was born.
Fast forward a few months, and I have learned a lot. I now know how to properly configure PlatformIO to suit my own needs and my projects.
Now, the time has come to clean up CRSF for Arduino's janky mess that is its folder structure.
To-Do List
*.h
file extensions in CRSF for Arduino to*.hpp
.README.md
to be more concise.platformio.ini
configuration file.*.ini
file.platformio.ini
file only to decide how the environment should compile (EG "Production", "Debug" etc).The problem
CRSF for Arduino's folder structure looks like this:
This is far from ideal, because one must go through folder after folder in order to get to anything.
This has implications for some compilers (for different targets) where the linkers freak out whenever a nested structure like this exists. The Arduino IDE is infamous for also completely losing its shit over nested folder structures. Especially one that is as unnecessarily complex as CRSF for Arduino.
It also makes it harder for yours truly to debug.
Plus, it makes it harder for you guys to find anything and read CRSF for Arduino's code base.
To drive the point home, here is a screenshot of the folder structure of another project of mine: As you can see, despite there being more modules in the project, each folder structure is straightforward and everything is easily accessible.
Even the folder structure for all of my drivers in this project is way more accessible than what I have with CRSF for Arduino:
What I want to achieve
A streamlined folder structure similar to the examples above, that retains compatibility with both the Arduino IDE and PlatformIO.
IIRC, the Arduino IDE prefers a folder structure that looks like this:
I cannot guarantee that CRSF for Arduino will look exactly like this, however I will do all I can to streamline the folder structure.
Keep in mind that this may introduce breaking changes (of which I will list here, as and when they arise).
Additional
I keep referencing PlatformIO because it is now my IDE of choice. CRSF for Arduino is developed in PlatformIO, with Visual Studio Code being my code viewer and editor.
I am also aware that Linguist (GitHub's coding language detection software) has done this: This is incorrect, because CRSF for Arduino is written exclusively in C++.
When I click on the 'C' component, I get this: This is CRSF for Arduino's boiler plate. 😆
Hardly C (or any language at all).
This has come about because all of CRSF for Arduino's header files are
*.h
(which is a C extension) and not*.hpp
(which is a C++ extension).I have found out that it is bad practice to mix-and-match these headers, if it contains pure C++ code (which CRSF for Arduino does).
So, one of the first things I am doing with the restructure is changing the extensions in all of CRSF for Arduino's header files from
*.h
to*.hpp
, and (hopefully) linguist will give a more accurate portrayal of the language that CRSF for Arduino is written in.