The Bitcraze crazyflie firmware currently contains 5 submodules. Git submodules are a reference to a single commit of a different git repository module, which can be used as a component or sub-project within the parent project itself. Submodules are Static, meaning they will not change or update automatically unless you manually change the commit that the submodule is referencing within the parent project.
Essentially there are three reasons that it may make sense to have git submodules in a project:
- When a component or subproject is changing quickly, and those changes have the potential to break the API of the parent project. In this situation you can lock the code of the subproject to a specific commit to maintain the safety of your parent project.
- When you have a component that is not updated frequently and you want to track it as a vendor dependency.
- When you are delegating a part of the project to a third-party, but you only want to pull in their updates at specific times.
Before continuing, we strongly recommend reading these two articles which is where I obtained all of this information. They do a far better job of explaining submodules and why they may be useful, We merely want to emphasize that they are Very Static.
Atlassian.com | Submodules: Core Concepts, Workflows and Tips
sd-may24 has taken all of these submodules and turned them into actual subdirectories of the parent project. So in our project, they should no longer exist as submodules. If you ever pull in a new version of the crazyflie firmware, you should probably repeat this process
With this in mind, we will now go through the 5 submodules that exist within the crazyflie firmware and provide a justification for their existence. The submodules can be viewed from the MicroCART/.gitmodules directory.
| Submodule | Justification |
|---|---|
| FreeRTOS | This repository contains a FreeRTOS kernel source/header files that are flashed onto the crazyflie drones and the FlyPi. This is the operating system that runs on the drones. It makes sense to me to have this as a submodule, because it does not get updated frequently, but if it did get updated it could have potentially harmful effects on our parent project. Therefore, we want to make sure that this is a Static instance of FreeRTOS |
| CMSIS | This is an open source project that contains a frameworks, tools, APIs, and work flows that are intended to help simplify the process for microcontroller developers. We are using CMSIS - Version 5, and the commit that we are pointing to is to a commit that is 4 years old, and 887 commits behind the most recent commit to the CMSIS_5 project. It also makes sense that if we are using this API in our project and the CMSIS API or framework were to change, this could create problems. Link to commit here: CMSIS_5 @a65b7c9 |
| libdw1000 | This is an open source driver for the Decawave DW1000 UWB radio chip, which is the radio chip that is on the crazyflie drones. The last commit to this project was 2 years ago. This would fall under the vendor dependency criteria. |
| cmock | This is a unit testing package built for C. This has also been described to work together with Unity Test, which is another testing submodule tool that we are using. Specifically, this submodule parses header files and creates interfaces based on the tests they find useful for integration. This most likely would be useful to have a static instance of. |
| unity | Similar to CMock, the Unity framework is a unit testing framework built for C-based embedded toolchains. Likewise for CMock: if we are holding a static instance for that submodule, it may be a good idea to do the same for this one. |