fmu-v5: Updated board config to RC01 of FMUv5 Spec #7219

FMU_CH7/8 use timer 12 ch1/2 FMU_CAP use timer 2 Buzzer use timer 9

Allows Anaode of LEDs to be tied to V5 or V3.3

Moving forward we want all the board configs to drive the configuration. This is just cleanup to give a clear example of how ADC should be defined by a simple list, based on ADC pin number as related to the GPIO and channel number. Then the xxx_CHANNEL bit are used to form the ADC_CHANNELS (mask). The GPIO will are used to for a list for initalization.

Per https://docs.google.com/spreadsheets/d/1-n0__BYDedQrc_2NHqBenG1DNepAgnHpSGglke-QQwY/edit#gid=730959725 Usage of the PWM UI led is optional and if used it's polaity may be set ot Active low or high.

When BOARD_NUMBER_BRICKS exists it will enable multiple power source testing and reporting.

…c RC01 Removed extra V GPIO_VDD_3V3[V]_SD_CARD_EN and it is active High

Define the GPIO pin list use the board_gpio_init

GPIO_nVDD_5V_PERIPH_EN is Active low. board_peripheral_reset need to tune it OFF then ON

board_spi_reset is used to reset the internal SPI bus. therefore GPIO_SPI5_DRDY7_EXTERNAL1 should not have been minipulated, as it is on SPI5

Since Hardware flow control has not been enabled this typo survived.

The LTC4417 provides a valid signal for USB. This change configures the GIOP and provides 1) True logic macro to read the pin and the IOCTL defines to read it from the FMU. The macro will return true when the signal is active (low on the LTC4417). The IOCTL will read be the actual pin state.

The V4 HW replaced the LTC4417 provided valid signal for USB. with an active high, version. This commit configures the GIOP and provides 1) a MACRO to read the pin and the IOCTL defines to read it from the FMU. The macro result true logic: true when the signal is high. The IOCTL read would be the actual pin state.

The LTC4417 provides a valid signals for brick1, brick 2 and USB This change configures the GIOP and provides 1) a MACRO to read the pin and 2) the IOCTL defines to read it from the FMU. The macro's result is true logic: It is true when the signal is active. (Active low on the the LTC4417). The IOCTL read would be the actual pin state.

As done on fmuV4 on resets invoked from system (not boot) insure we establish a low output state (discharge the pins) on PWM pins before they become inputs as a result of the pending reset. We also delay the reset by 400 MS to insure the 3.1 Ms pulse is not too close to the last PWM pulse.

Added comments to ADC defines with Pin numbers. Added the GPIO_HW_{REV:VER}_DRIVE signals Define the GPIO_nPOWER_IN_{A:C] and assign them to BRICK1, BRICK2 and USB Valid. Regroupped power signals and defined true logic Power Control macros in the arch agnostic form. Defined the same IOCTL defines for FMU GPIO IOCTL Use the power Control macros on board_app_initialize

Dispite what the ref manaul says. Some HW needs the added pull down to insure the pin reads low when not plugged in to USB.

The PX4IO is an population option on some varients. To have 1) FMU only control 2) IO Only control 3) FMU fall back control These pins need to come up as inputs, until the configuration is determined.

system_source - This battery status is for the brick that is supplying VDD_5V_IN priority - Zero based, This battery status is for the brick that is connected to the Power controller's N-1 priority input. V1..VN. 0 would normally be Brick1, 1 for Brick2 etc Battery now assigns connected from the api in the updateBatteryStatus, as well as system_source and priority

FMUv4Pro and FMUv5 Spec added multi brick support FMUv5 added SCALED_VDD_3V3_SENSORS This change provides legacy (FMUv2) defaults for Power Bricks and Sensor rail volatage source.

This change implements the publishing of batery_status messages for each brick on the system, using multi-pub. Backward compatiblity is achived by always publishing the batery_status of the bick that has been selected by the HW Power Controller (PC) on instance 0. The batery_status.system_source will be true in one and only one batery_status publication when a valid bit is set in system_power.brick_valid. However, if USB is connected, and both brikcs are not providing voltages to the PC that are in the Under/Over Voltage Window (set in HW) the system_source may be false in all publications.

voltage3V3_v - the sensor 3.3V voltage rail v3v3_valid - the value of voltage3V3_v may be 0. This field is a 1 when the HW provides voltage3V3_v brick_valid - is now a bit mask. A 1 in the postion inticate the Power controler HW has a valid supply voltage present (in V window) on that priority (channel V1..Vn). The mapping is formed by 1<<battery_status.msg.priority or using the manifest constanst BRICKn_VALID_MASK usb_vaild - is now indicated from the Power controler HW or the usb_connected if Power controler is not present. brick_valid == 0 and usb_vaild = 1 implies the FMU is powered from USB only brick_valid != 0 and usb_vaild = 1 implies the FMU is powered from the higest priority brick, providing a 1 bit in brick_valid and from USB

Removed unused headers and placed the __BEGIN_DECLS where it belonged

BOARD_HAS_LTC44XX_VALIDS - 0 -> No LTC44xx IC, N is the number of Power Bricks connected to the LTC44xx For a LTC4417 this would be 2 as the third prioriy is used for USB BOARD_HAS_USB_VALID - If defied as 1 imples that infact the USB has a priority connection on the LTC44XX BOARD_HAS_NBAT_V - the number of battery voltage sensing chennels on the ADC BOARD_HAS_NBAT_I - the number of battery current sensing chennels on the ADC A super simple (non FMUv5 compliant) board with no LTC44xx and just one battery that have no current sense: BOARD_HAS_LTC44XX_VALIDS = 0 BOARD_HAS_USB_VALID = 0 BOARD_HAS_NBAT_V = 1 BOARD_HAS_NBAT_0 = 0 A fully FMUv5 compliant design would use: BOARD_HAS_LTC44XX_VALIDS = 2 BOARD_HAS_USB_VALID = 1 BOARD_HAS_NBAT_V = 2 BOARD_HAS_NBAT_0 = 2 These setting properly condition the ADC channles and all the Power module valid sensing logic in the ADC module.

Both PX4Test and Beat noted if only Brick to was connected battery_status Intance 0 voltage was 0V for Brick2 The priority selection logic is run prior to the subscription creation and only updated the priority on a change. Before the subscriotions were created. _battery_pub_intance0ndx is suposed track the location in the _battery_pub array that is instance 0. It is then used to associate (move) instance 0 with (to) the lowest brick (highest priority in HW) brick that is selected in HW. The Bug was that before the subscriptions are created, _battery_pub_intance0ndx set to 1. And then and never updated. The fix was to only run the priority selection logic once the subscriptions are created.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

fmu-v5: Updated board config to RC01 of FMUv5 Spec #7219

fmu-v5: Updated board config to RC01 of FMUv5 Spec #7219

Commits on Jul 17, 2017