* FMUv4pro : allow power monitoring for hipower rail
* FMUv4pro : init temperare calibration EEPROM CS
* FMUv4pro : workaround for safety switch
* FMUv4pro : remove useless and conflicting defines
* FMUv4pro : disable internal pull-up for OC sensing
/FAULT won't achieve VinputLow with internal pull-up resistor so it must
be turned off for both /VDD_5V_PERIPH_OC and /VDD_5V_HIPOWER_OC.
Replaced by external pull-up.
* FMUv4pro : correct safety switch handling
RC02 has a hardware pull-down on this signal
* Revert "FMUv4pro : workaround for safety switch"
This reverts commit 9528ae29b68700fa7c6604c1ac2756c7dac2819c.
- There's no I2C2, so remove it
- Fix alignments everywhere in board_config.h
- Clarify STM32 ADC (not available) and the ADC on the FGPA
- Fix format on some comments
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.
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
The fmu now support the commandline option to be run as a task
or off a work queue.
This reverts the board_config.h changes from commit
e33af23122f5ee3030bb9745bbbf616b24c2a14a.
Conflicts:
src/drivers/px4fmu/fmu.cpp
The maximum number of missions was increased in almost 8 times in
recent commit: 9369262e63 navigator: allow more mission items.
As this board loads missions in RAM, now it don't have enough memory
to allocate causing dataman start to fail, so mark it as a memory
constrained system and reduce the number of maximum missions
supported.
We need to protect access to the param_values array. This is dynamically
allocated and resized (utarray_reserve() calls realloc). If some thread
was iterating the array while another was resizing the array, the first one
would iterate on a freed array, thus accessing invalid memory.
On NuttX this could lead to hardfaults in rare conditions.
Unfortunately we need to initialize the semaphore on startup, by calling
sem_init(). This adds a param_init() method called by every board/config
that uses the params (at least I think I've found all of them)
Sergej Scheiermann