- make the selected parameter a template argument. This
enables type-checking at compile-time.
- move things to src/platforms.
This provides consistent includes with ModuleBase
- add ModuleParams base class (replaces Block & SuperBlock)
- drop the Block* prefix from the class names
Generates an enum with all params & additional type information for static
type checking
The generated public param header is required to build the modules using
the new BlockParam classes.
On the Intel Aero and probably also other specific platforms
the first measured voltage values despite connected battery are unuasable.
The solution here is to start filtering and determining warning
only after a measurement above 2.1V was received.
In rare circumstances, the buffer size was too small by 1 byte, leading
to a param export failure. And leading to a reset of all params!
This could only happen when the last saved param was a float.
Also the realloc_ok initialization is not needed.
Some modules call this (and maybe in rare circumstances), which could lead
to stack overflows. With our current headroom of >= 300bytes, 256 should
be ok.
This increases the export time from ~28ms to ~34ms in my case (on a
Pixracer)
Volatile parameters are ones that do not represent a fundamental configuration change but rather than incrementally changing settings. These include logged flight hours or sensor offsets. Marking them as volatile avoids these parameters forcing time-consuming telemetry updates.
This helps subscribers to understand if they should update their parameters or not. We will extend this with other flags such as the current save status and alike.
Most of the incompatitbilities are luckily similar to the darwin build.
- New target OS __PX4_CYGWIN added because in other build environments on Windows defines will very likely be completely different
- added all necessary exeptions to the defines
- disabled priorities completely because on Windows they are defined 1-32 and with all the arbitrary +40 -40 priority settings there were a lot of problems
not only did some threads/"virtual tasks" not start because of out of bound priorities but also the resulting scheduling was totally random and inadequate
with default priorities it ran toally fine during my first tests, should be rethought when windows is used onboard in the future
