Repository contains IoT device and infrastructure source code. Main purpose of the project is to learn MCU programming concepts.
Detailed description of sensors is in device project.
- common - Contains common device/host components
- device - Contains firmware source code
- host - Contains device source code that can be run on host: unit-tests or test applications for firmware source code
- server - Contains server source code
- OS Linux (debian based). For example: Ubuntu 22.04, PopOS 22.04 etc.
Repository is using symbolic links.
Main style is lowercase snake case, but dashed style also appropriate.
Examples:
control_application
hw-description
long_file_name.cpp
- For feature development create new branch
<your account name>/<feature/ticket name>
of "main" - Create merge request for "main"
- Merge after successful review
- Delete feature branch (usually it is done automatically after merge)
All code that committed into repository should be passed through auto-formatter:
- For C/C++ use clang-format
- For Python use Black
- For JS, CSS use Prettier
Exceptions can be only for third-party code like: CMSIS, mongoose etc. This will simplify sync/merge updates. To add exceptions:
- Add exceptions into "exclude" section of ".pre-commit-config.yaml"
- Run
pre-commit install
Auto-formatter must be enabled via git pre-commit hooks to apply automatically before every commit.
sudo apt install clang-format-14
pip install pre-commit==3.3.1
pip install black==22.3.0
cd <git repo root>
pre-commit install
- Use spaces instead of tabs
- Tab width is 4
- Code line width is 120
See Black code style for details. For docstrings use Google Style.
C++ code version is limited by C++11.
Code style is based on Google C++ Style Guide
- Snake case for all except class names
void my_func(int8_t my_param);
class MyClass;
- Local functions and definitions should have "_" prefix
#define _MY_LOCAL_MACRO()
static int _get_length();
Docstrings should use Doxygen style
/**
* Description
* @param[in,out] state Device driver state
* @param[in] len Length
* @param[out] data Output date
* @return Value
*/
Docstrings and comments should be written only where they are useful. Do not forget that comments are usually becomes outdated and useless after some time, due to refactoring, renaming and development in general.
Best practice to document code is right and intuitive naming!