You can now add `DYNAMIC` as an option to `px4_add_module`, which will
cause that module to no longer be compiled into the px4 executable, but
instead produce a separate shared library file, which can be loaded and
executed with the new `dyn` command:
pxh> dyn ./hello.px4mod start
This will load the shared object file `hello.px4mod` if it wasn't
already loaded, and execute its main function with the given arguments.
The threads running commands for clients through the Posix daemon used
to write to a char buffer through snprintf (etc.) which was then written
directly to the file descriptor, whereas in the other case printf
(etc.) was used to write to stdout (FILE*). Both versions used some
macro's and repeated code to have the same output.
This change unifies these two cases by using a FILE* in both cases. The
(line) buffering is done by the standard C library's implementation
(just like with stdout), and px4_log.c now uses the same code in all
cases (using fprintf, etc.) for printing (colored) output.
* attitude and rate setpoint message: use 3D array for thrust demand
* FixedWingAttitudeControl: rework airspeed scaling
* move airspeed and scaling calculation into separate method
* if vtol in hover and airspeed disabled use minimum airspeed instead of trim airspeed
This commit is the groundwork to fix the power LED
blinking on V5
Background:
----------
Early boards only had an AMBER LED that was used to
indicate a High Load condition.
This change defines the new logical inteface
the LED_<color> should not be used in application
code moving forward, only the minipulator macros
should be used.
Logical usage Legacy default
------------------------+-------------
BOARD_OVERLOAD_LED | LED_RED
Later boards defined BOARD_HAS_CONTROL_STATUS_LEDS
and added the use of a BLUE and GREEN LED that were
used as follows:
Logical usage Legacy default
------------------------+-------------
BOARD_ARMED_LED | LED_BLUE
BOARD_ARMED_STATE_LED | LED_GREEN
With this PR a board may now define _only_ a subset
the leds and map them at the board level to the
color LED it wants to use.
Logical usage Legacy default
------------------------+-------------
BOARD_OVERLOAD_LED | LED_RED
when BOARD_HAS_CONTROL_STATUS_LEDS is defined
BOARD_ARMED_LED | LED_BLUE
BOARD_ARMED_STATE_LED | LED_GREEN
If any of the BOARD_{OVERLOAD|ARMED|ARMED_STATE}_LED are not
defined. The code output generates a null action for that
LED.
Mara Bos