For the process usage: we need to measure over a certain period of time,
then we can use the results. To avoid blocking, this does:
- after log is started, initialze the load counters, then one second later
add the results to the log
- after disarming: continue logging for one more second, then add the process
load to the log and stop logging.
- to avoid a delay, 'logger stop' will stop immediately and not log
postflight process usage.
perf_counters is read from and written to by different threads and thus
requires synchronization. Without it we risk accessing invalid memory.
There are still remaining issues (see comment in code), they will not lead
to a crash however.
Instead of printing to an fd, this prints to a buffer and calls a callback
for each line. To avoid code duplication, the print_load has been refactored
to print to a buffer first, then print to an fd. The overhead is not
noticable, and the behavior of print_load is unchanged.
what could have gone wrong before? A scheduling switch during the printload
could have led to a task exit, rendering the tcb invalid. After switching
back, printload would access invalid memory.
This keeps the sched_lock() section as small as possible, just grabbing the
tcb variables we need.
FMUv4 PRO HW does not have a controlable V3.3 on the connector
it therefore can not support the SPEKTUM binding.
This PR removes the Power switch controls or binding control
interfaces from the board config
Removed the legacy FMUv4 define that was activating a nonexistent
pull up and on some HW driving the PPM_IN aka RC_IN aka SPEKTRUM_RX
to VDD.
Also detailed the connections of this pins for the board.
The simplest connection is RC_IN to a timer capture pin
and a UART.
In this case the UART_RX pin and just be left as is.
While the pin can be configured as the PPM_IN (Timer capture)
or as SPEKTRUM_RX_AS_GPIO_OUTPUT to use it as and GPIO to
facilitate binding.
Renamed the macros and defines to be more explicit as to what
Is being done and the sense of the parameters
Removed the legacy FMUv4 define that was activating a nonexistent
pull up and on some HW driving the PPM_IN aka RC_IN aka SPEKTRUM_RX
to VDD.
Also detailed the connections of this pins for the board.
The simplest connection is RC_IN to a timer capture pin
and a UART.
In this case the UART_RX pin and just be left as is.
While the pin can be configured as the PPM_IN (Timer capture)
or as SPEKTRUM_RX_AS_GPIO_OUTPUT to use it as and GPIO to
facilitate bindin
Renamed the macros and defines to be more explicit as to what
Is being done and the sense of the parameters
Removed the legacy FMUv4 define that was activating a nonexistent
pull up and on some HW driving the PPM_IN aka RC_IN aka SPEKTRUM_RX
to VDD.
Also detailed the connections of this pins for the board.
The simplest connection is RC_IN to a timer capture pin
and a UART.
In this case the UART_RX pin and just be left as is.
While the pin can be configured as the PPM_IN (Timer capture)
or as SPEKTRUM_RX_AS_GPIO_OUTPUT to use it as and GPIO to
Renamed the macros and defines to be more explicit as to what
Is being done and the sense of the parameters
Removed the legacy FMUv4 define that was activating a nonexistent
pull up and on some HW driving the PPM_IN aka RC_IN aka SPEKTRUM_RX
to VDD.
Also detailed the connections of this pins for the board.
The simplest connection is RC_IN to a timer capture pin
and a UART.
In this case the UART_RX pin and just be left as is.
While the pin can be configured as the PPM_IN (Timer capture)
or as SPEKTRUM_RX_AS_GPIO_OUTPUT to use it as and GPIO to
facilitate binding.
Renamed the macros and defines to be more explicit as to what
Is being done and the sense of the parameters
Removed the legacy FMUv4 define that was activating a nonexistent
pull up and on some HW driving the PPM_IN aka RC_IN aka SPEKTRUM_RX
to VDD.
Also detailed the connections of this pins for the board.
The simplest connection is RC_IN to a timer capture pin
and a UART.
In this case the UART_RX pin and just be left as is.
While the pin can be configured as the PPM_IN (Timer capture)
or as SPEKTRUM_R
facilitate binding.
Renamed the macros and defines to be more explicit as to what
Is being done and the sense of the parameters
Removed the legacy FMUv4 define that was activating a nonexistent
pull up and on some HW driving the PPM_IN aka RC_IN aka SPEKTRUM_RX
to VDD.
Also detailed the connections of this pins for the board.
The simplest connection is RC_IN to a timer capture pin
and a UART.
In this case the UART_RX pin and just be left as is.
While the pin can be configured as the PPM_IN (Timer capture)
or as SPEKTRUM_RX_AS_GPIO_OUTPUT to use it as and GPIO to
facilitate binding.
Renamed the macros and defines to be more explicit as to what
Is being done and the sense of the parameters
Removed the legacy FMUv4 define that was activating a nonexistent
pull up and on some HW driving the PPM_IN aka RC_IN aka SPEKTRUM_RX
to VDD.
Also detailed the connections of this pins for the board.
The simplest connection is RC_IN to a timer capture pin
and a UART.
In this case the UART_RX pin and just be left as is.
While the pin can be configured as the PPM_IN (Timer capture)
or as SPEKTRUM_RX_AS_GPIO_OUTPUT to use it as and GPIO to
facilitate binding.
Renamed the macros and defines to be more explicit as to what
Is being done and the sense of the parameters
Removed the legacy FMUv4 define that was activating a nonexistent
pull up and on some HW driving the PPM_IN aka RC_IN aka SPEKTRUM_RX
to VDD.
Also detailed the connections of this pins for the board.
The simplest connection is RC_IN to a timer capture pin
and a UART.
In this case the UART_RX pin and just be left as is.
While the pin can be configured as the PPM_IN (Timer capture)
or as SPEKTRUM_RX_AS_GPIO_OUTPUT to use it as and GPIO to
facilitate binding.
Renamed the macros and defines to be more explicit as to what
Is being done and the sense of the parameters
Removed the legacy FMUv4 define that was activating a nonexistent
pull up and on some HW driving the PPM_IN aka RC_IN aka SPEKTRUM_RX
to VDD.
Use the abstaction SPEKTRUM_POWER to enable the interface not
the define for the GPIO pin.
Removed the legacy FMUv4 define that was activating a nonexistent
pull up and on some HW driving the PPM_IN aka RC_IN aka SPEKTRUM_RX
to VDD.
Also detailed the connections of this pins for the board.
The simplest connection is RC_IN to a timer capture pin
and a UART.
In this case the UART_RX pin and just be left as is.
While the pin can be configured as the PPM_IN (Timer capture)
or as SPEKTRUM_RX_AS_GPIO_OUTPUT to use it as and GPIO to
facilitate binding.
Renamed the macros and defines to be more explicit as to what
Is being done and the sense of the parameters
Just to make sure that it will never be used on NuttX. This is not an
architectural limitation, just a memory optimization, since we call
clearenv() on NuttX.
Returned the fmu mixer code to where it updated the HW once
it has a mixer. But only signals a up_pwm_update() for
onshots on actual control update.
Before this change the hw outpuse were not updated.
A recent change in in the fmu stops the instance when a
xxxx_reset command is used issued if the fmu was not
already running.
That change left publications published and then on the
next creation created a new publications was created.
This change calls orb_unadvertise to mark the publication
as un published so that on the next instantiations of the
fmu it resumes publishing on the same publication.
