2023-06-27 Model CFG

For each aircraft model + board we need to be able to configure all peripherals.

AM access cfg data

Motors

AM cfg data

Safety check

Sensors

Given PRYT values

AM read cfg, determines for each motor which driver to use, and its hardware connection / ID

AM calls PWM or DSHOT driver (subclass of motor driver)

Implementation details:

Want cfg files to be readable, easily modifiable.

Existing solutions:

E.g. devicetree + kconfig

Complicated, probably overkill

Custom cfg files

e.g. json, yaml, ini, (key-value pairs) etc

Could be either static or dynamic

If dynamic, changes do not require recompilation

Needs some script so the c++ code can interpret and access the data

Could use existing libraries for interpretation

Flexible, readable

Simpler for non-firmware members to use

Can be added later on a case-by-case basis if there is a need

Pure C++ cfg

For each model, unique h++, and maybe C++ file

Statically selected and compiled through build script options

C++ project directly uses cfg

Familiar for firmware members

Not as understandable for non-firmware members

Changing any parameter requires recompilation

Should have strong focus on clear documentation (to offset reduced readability)

Decision: Pure C++ cfg

Static vs Dynamic CFG

Static configuration is sufficient for the near future

Soft resets possible using dynamic

Decision:

Static. If neccessary, dynamic cfg can be added gradually.

Future Discussion:

How exactly the header cfg files will look