2020-12-23 22:02:11 -04:00
|
|
|
# The CUBE Yellow is a variant of The CUBE Black from ProfiCNC/Hex
|
2018-07-04 08:18:23 -03:00
|
|
|
# with a STM32F777 MCU
|
2018-06-05 19:13:38 -03:00
|
|
|
|
|
|
|
# MCU class and specific type
|
|
|
|
MCU STM32F7xx STM32F777xx
|
|
|
|
|
|
|
|
# we set a specific HAL_BOARD_SUBTYPE, allowing for custom config in
|
|
|
|
# drivers. For this to be used the subtype needs to be added to
|
|
|
|
# AP_HAL/AP_HAL_Boards.h as well
|
|
|
|
define CONFIG_HAL_BOARD_SUBTYPE HAL_BOARD_SUBTYPE_CHIBIOS_FMUV3
|
|
|
|
|
|
|
|
# now we need to specify the APJ_BOARD_ID. This is the ID that the
|
|
|
|
# bootloader presents to GCS software so it knows if this firmware is
|
|
|
|
# suitable for the board. Please see
|
|
|
|
# https://github.com/ArduPilot/Bootloader/blob/master/hw_config.h for
|
|
|
|
# a list of current board IDs. If you add a new board type then please
|
|
|
|
# get it added to that repository so we don't get conflicts.
|
|
|
|
|
|
|
|
# Note that APJ is "ArduPilot JSON Firmware Format"
|
|
|
|
|
|
|
|
# crystal frequency
|
|
|
|
OSCILLATOR_HZ 24000000
|
|
|
|
|
|
|
|
# board ID for firmware load
|
2018-06-16 08:09:31 -03:00
|
|
|
APJ_BOARD_ID 120
|
2018-06-05 19:13:38 -03:00
|
|
|
|
2019-03-10 21:30:22 -03:00
|
|
|
# with 2M flash we can afford to optimize for speed
|
2019-09-27 17:58:51 -03:00
|
|
|
env OPTIMIZE -O2
|
|
|
|
|
2018-06-05 19:13:38 -03:00
|
|
|
# on some boards you will need to also set the various PLL values. See
|
|
|
|
# the defaults in common/mcuconf.h, and use the define mechanism
|
|
|
|
# explained later in this file to override values suitable for your
|
|
|
|
# board. Refer to your MCU datasheet or examples from supported boards
|
|
|
|
# in ChibiOS for the right values.
|
|
|
|
|
|
|
|
# now define the voltage the MCU runs at. This is needed for ChibiOS
|
|
|
|
# to set various internal driver limits. It is in 0.01 volt units
|
|
|
|
|
|
|
|
# this is the STM32 timer that ChibiOS will use for the low level
|
|
|
|
# driver. This must be a 32 bit timer. We currently only support
|
|
|
|
# timers 2, 3, 4, 5 and 21. See hal_st_lld.c in ChibiOS for details
|
|
|
|
|
|
|
|
# ChibiOS system timer
|
|
|
|
STM32_ST_USE_TIMER 5
|
|
|
|
|
|
|
|
# now the size of flash in kilobytes, for creating the ld.script
|
|
|
|
|
|
|
|
# flash size
|
|
|
|
FLASH_SIZE_KB 2048
|
|
|
|
|
|
|
|
# now define which UART is used for printf(). We rarely use printf()
|
|
|
|
# in ChibiOS, so this is really only for debugging very early startup
|
|
|
|
# in drivers.
|
|
|
|
|
|
|
|
# serial port for stdout. This is optional. If you leave it out then
|
2020-04-30 23:57:54 -03:00
|
|
|
# output from printf() lines will be sent to
|
2018-06-05 19:13:38 -03:00
|
|
|
# hal.console->printf() for the ArduPilot console, which is the first
|
2020-04-30 23:57:54 -03:00
|
|
|
# UART in the SERIAL_ORDER list. The value for STDOUT_SERIAL is a
|
2018-06-05 19:13:38 -03:00
|
|
|
# serial device name, and must be for a serial device for which pins
|
|
|
|
# are defined in this file. For example, SD7 is for UART7 (SD7 ==
|
|
|
|
# "serial device 7" in ChibiOS).
|
|
|
|
#STDOUT_SERIAL SD7
|
|
|
|
#STDOUT_BAUDRATE 57600
|
|
|
|
|
|
|
|
# now the USB setup, if you have USB. All of these settings are
|
|
|
|
# option, and the ones below are the defaults. It ends up creating a
|
|
|
|
# USB ID on Linux like this:
|
|
|
|
# /dev/serial/by-id/usb-ArduPilot_fmuv3_3E0031000B51353233343932-if00
|
|
|
|
# if creating a board for a RTF vehicle you may wish to customise these
|
|
|
|
|
|
|
|
# USB setup
|
2018-06-05 22:04:49 -03:00
|
|
|
USB_VENDOR 0x2DAE # ONLY FOR USE BY ProfiCNC / HEX! NOBODY ELSE
|
2018-07-04 08:18:23 -03:00
|
|
|
USB_PRODUCT 0x1012
|
2018-07-04 07:43:17 -03:00
|
|
|
USB_STRING_MANUFACTURER "Hex/ProfiCNC"
|
2018-06-05 19:13:38 -03:00
|
|
|
|
|
|
|
# now define the order that I2C buses are presented in the hal.i2c API
|
|
|
|
# in ArduPilot. For historical reasons inherited from HAL_PX4 the
|
|
|
|
# 'external' I2C bus should be bus 1 in hal.i2c, and internal I2C bus
|
|
|
|
# should be bus 0. On fmuv3 the STM32 I2C1 is our external bus and
|
|
|
|
# I2C2 is our internal bus, so we need to setup the order as I2C2
|
|
|
|
# followed by I2C1 in order to achieve the conventional order that
|
|
|
|
# drivers expect
|
|
|
|
|
|
|
|
# order of I2C buses
|
|
|
|
I2C_ORDER I2C2 I2C1
|
|
|
|
|
|
|
|
# now the UART order. These map to the hal.uartA to hal.uartF
|
|
|
|
# objects. If you use a shorter list then HAL_Empty::UARTDriver
|
|
|
|
# objects are substituted for later UARTs, or you can leave a gap by
|
|
|
|
# listing one or more of the uarts as EMPTY
|
|
|
|
|
|
|
|
# the normal usage of this ordering is:
|
|
|
|
# 1) SERIAL0: console (primary mavlink, usually USB)
|
|
|
|
# 2) SERIAL3: primary GPS
|
|
|
|
# 3) SERIAL1: telem1
|
|
|
|
# 4) SERIAL2: telem2
|
|
|
|
# 5) SERIAL4: GPS2
|
|
|
|
# 6) SERIAL5: extra UART (usually RTOS debug console)
|
|
|
|
|
|
|
|
# order of UARTs (and USB)
|
2020-04-24 08:10:08 -03:00
|
|
|
SERIAL_ORDER OTG1 USART2 USART3 UART4 UART8 UART7 OTG2
|
2018-06-05 19:13:38 -03:00
|
|
|
|
|
|
|
# if the board has an IOMCU connected via a UART then this defines the
|
|
|
|
# UART to talk to that MCU. Leave it out for boards with no IOMCU
|
|
|
|
|
|
|
|
# UART for IOMCU
|
|
|
|
IOMCU_UART USART6
|
|
|
|
|
|
|
|
# now we start on the pin definitions. Every pin used by ArduPilot
|
|
|
|
# needs to be in this file. The format is P+port+pin. So PC4 is portC
|
|
|
|
# pin4. For every pin the 2nd colum is the label. If this is a
|
|
|
|
# peripheral that has an alternate function defined in the STM32
|
|
|
|
# datasheet then the label must be the name of that alternative
|
|
|
|
# function. The names are looked up in the python database for this
|
|
|
|
# MCU. Please see STM32F427xx.py for the F427 database. That database
|
|
|
|
# is used to automatically fill in the alternative function (and later
|
|
|
|
# for the DMA channels).
|
|
|
|
|
|
|
|
# The third column is the peripheral type. This must be one of the
|
|
|
|
# following: UARTn, USARTn, OTGn, SPIn, I2Cn, ADCn, TIMn, SWD, SDIO,
|
|
|
|
# INPUT, OUTPUT, CS
|
|
|
|
|
|
|
|
# the fourth and later columns are for modifiers on the pin. The
|
|
|
|
# possible modifiers are
|
|
|
|
# pin speed: SPEED_VERYLOW, SPEED_LOW, SPEED_MEDIUM, SPEED_HIGH
|
|
|
|
# pullup: PULLUP, PULLDOWN, FLOATING
|
|
|
|
# out type: OPENDRAIN, PUSHPULL
|
|
|
|
# default value: LOW, HIGH
|
|
|
|
|
|
|
|
# Additionally, each class of pin peripheral can have extra modifiers
|
|
|
|
# suitable for that pin type. For example, for an OUTPUT you can map
|
|
|
|
# it to a GPIO number in hal.gpio using the GPIO(n) modifier. For ADC
|
|
|
|
# inputs you can apply a scaling factor (to bring it to unit volts)
|
|
|
|
# using the SCALE(x) modifier. See the examples below for more
|
|
|
|
# modifiers, or read the python code in chibios_hwdef.py
|
|
|
|
|
|
|
|
# now we define UART4 which is for the GPS, which is a GPS. Be careful
|
|
|
|
# of the difference between USART and UART. Check the STM32F427xx.py
|
|
|
|
# if unsure which it is. For a UART we need to specify at least TX and
|
|
|
|
# RX pins.
|
|
|
|
|
|
|
|
# this pins in this file can be defined in any order.
|
|
|
|
|
|
|
|
# UART4 serial GPS
|
|
|
|
PA0 UART4_TX UART4
|
|
|
|
PA1 UART4_RX UART4
|
|
|
|
|
|
|
|
# now define the primary battery connectors. The labels we choose hear
|
|
|
|
# are used to create defines for pins in the various drivers, so
|
|
|
|
# choose names that match existing board setups where possible. Here
|
|
|
|
# we define two pins PA2 and PA3 for voltage and current sensing, with
|
|
|
|
# a scale factor of 1.0 and connected on ADC1. The pin number this
|
|
|
|
# maps to in hal.adc is automatically determined using the datasheet
|
|
|
|
# tables in STM32F427xx.py
|
|
|
|
|
|
|
|
PA2 BATT_VOLTAGE_SENS ADC1 SCALE(1)
|
|
|
|
PA3 BATT_CURRENT_SENS ADC1 SCALE(1)
|
|
|
|
|
|
|
|
# now the VDD sense pin. This is used to sense primary board voltags
|
|
|
|
PA4 VDD_5V_SENS ADC1 SCALE(2)
|
|
|
|
|
|
|
|
# now the first SPI bus. At minimum you need SCK, MISO and MOSI pin
|
|
|
|
definitions. You can add speed modifiers if you want them, otherwise
|
|
|
|
the defaults for the peripheral class are used.
|
|
|
|
|
|
|
|
PA5 SPI1_SCK SPI1
|
|
|
|
PA6 SPI1_MISO SPI1
|
|
|
|
PA7 SPI1_MOSI SPI1
|
|
|
|
|
|
|
|
# this defines an output pin which will default to output LOW. It is a
|
|
|
|
# pin that enables peripheral power on this board
|
|
|
|
|
|
|
|
PA8 VDD_5V_PERIPH_EN OUTPUT LOW
|
|
|
|
|
|
|
|
# this is the pin that senses USB being connected. It is an input pin
|
|
|
|
# setup as OPENDRAIN
|
|
|
|
PA9 VBUS INPUT OPENDRAIN
|
|
|
|
|
|
|
|
# this is a commented out pin for talking to the debug uart on the
|
|
|
|
# IOMCU, not used yet, but left as a comment (with a '#' in front) for
|
|
|
|
# future reference
|
|
|
|
# PA10 IO-debug-console
|
|
|
|
|
|
|
|
# now we define the pins that USB is connected on
|
|
|
|
PA11 OTG_FS_DM OTG1
|
|
|
|
PA12 OTG_FS_DP OTG1
|
|
|
|
|
|
|
|
# these are the pins for SWD debugging with a STlinkv2 or black-magic probe
|
|
|
|
PA13 JTMS-SWDIO SWD
|
|
|
|
PA14 JTCK-SWCLK SWD
|
|
|
|
|
|
|
|
# this defines the PWM pin for the buzzer (if there is one). It is
|
|
|
|
# also mapped to a GPIO output so you can play with the buzzer via
|
|
|
|
# MAVLink relay commands if you want to
|
|
|
|
|
|
|
|
# PWM output for buzzer
|
|
|
|
PA15 TIM2_CH1 TIM2 GPIO(77) ALARM
|
|
|
|
|
|
|
|
# this defines a couple of general purpose outputs, mapped to GPIO
|
|
|
|
# numbers 1 and 2 for users
|
|
|
|
PB0 EXTERN_GPIO1 OUTPUT GPIO(1)
|
|
|
|
PB1 EXTERN_GPIO2 OUTPUT GPIO(2)
|
|
|
|
|
|
|
|
# this defines some input pins, currently unused
|
|
|
|
PB2 BOOT1 INPUT
|
|
|
|
PB3 FMU_SW0 INPUT
|
|
|
|
|
|
|
|
# this defines the pins for the 2nd CAN interface, if available
|
|
|
|
PB6 CAN2_TX CAN2
|
|
|
|
PB12 CAN2_RX CAN2
|
|
|
|
|
|
|
|
# now the first I2C bus. The pin speeds are automatically setup
|
|
|
|
# correctly, but can be overridden here if needed.
|
|
|
|
PB8 I2C1_SCL I2C1
|
|
|
|
PB9 I2C1_SDA I2C1
|
|
|
|
|
|
|
|
# now the 2nd I2C bus
|
|
|
|
PB10 I2C2_SCL I2C2
|
|
|
|
PB11 I2C2_SDA I2C2
|
|
|
|
|
|
|
|
# the 2nd SPI bus
|
|
|
|
PB13 SPI2_SCK SPI2
|
|
|
|
PB14 SPI2_MISO SPI2
|
|
|
|
PB15 SPI2_MOSI SPI2
|
|
|
|
|
|
|
|
# this input pin is used to detect that power is valid on USB
|
2020-02-13 04:06:12 -04:00
|
|
|
PC0 VBUS_nVALID INPUT PULLUP
|
2018-06-05 19:13:38 -03:00
|
|
|
|
|
|
|
# this defines the CS pin for the magnetometer and first IMU. Note
|
|
|
|
# that CS pins are software controlled, and are not tied to a particular
|
|
|
|
# SPI bus
|
|
|
|
PC1 MAG_CS CS
|
|
|
|
PC2 MPU_CS CS
|
|
|
|
|
|
|
|
# this defines more ADC inputs
|
|
|
|
PC3 AUX_POWER ADC1 SCALE(1)
|
|
|
|
PC4 AUX_ADC2 ADC1 SCALE(1)
|
|
|
|
|
|
|
|
# and the analog input for airspeed (rarely used these days)
|
|
|
|
PC5 PRESSURE_SENS ADC1 SCALE(2)
|
|
|
|
|
|
|
|
# this sets up the UART for talking to the IOMCU. Note that it is
|
|
|
|
# vital that this UART has DMA available. See the DMA settings below
|
|
|
|
# for more information
|
|
|
|
|
|
|
|
# USART6 to IO
|
|
|
|
PC6 USART6_TX USART6
|
|
|
|
PC7 USART6_RX USART6
|
|
|
|
|
|
|
|
# now setup the pins for the microSD card, if available
|
|
|
|
PC8 SDMMC_D0 SDMMC1
|
|
|
|
PC9 SDMMC_D1 SDMMC1
|
|
|
|
PC10 SDMMC_D2 SDMMC1
|
|
|
|
PC11 SDMMC_D3 SDMMC1
|
|
|
|
PC12 SDMMC_CK SDMMC1
|
|
|
|
PD2 SDMMC_CMD SDMMC1
|
|
|
|
|
|
|
|
# more CS pins for more sensors. The labels for all CS pins need to
|
|
|
|
# match the SPI device table later in this file
|
|
|
|
PC13 GYRO_EXT_CS CS
|
|
|
|
PC14 BARO_EXT_CS CS
|
|
|
|
PC15 ACCEL_EXT_CS CS
|
|
|
|
PD7 BARO_CS CS
|
|
|
|
PE4 MPU_EXT_CS CS
|
|
|
|
|
|
|
|
# the first CAN bus
|
|
|
|
PD0 CAN1_RX CAN1
|
|
|
|
PD1 CAN1_TX CAN1
|
|
|
|
|
|
|
|
# Another USART, this one for telem1. This one has RTS and CTS lines
|
|
|
|
# USART2 serial2 telem1
|
|
|
|
PD3 USART2_CTS USART2
|
|
|
|
PD4 USART2_RTS USART2
|
|
|
|
PD5 USART2_TX USART2
|
|
|
|
PD6 USART2_RX USART2
|
|
|
|
|
|
|
|
# the telem2 USART, also with RTS/CTS available
|
|
|
|
# USART3 serial3 telem2
|
|
|
|
PD8 USART3_TX USART3
|
|
|
|
PD9 USART3_RX USART3
|
|
|
|
PD11 USART3_CTS USART3
|
|
|
|
PD12 USART3_RTS USART3
|
|
|
|
|
|
|
|
# the CS pin for FRAM (ramtron). This one is marked as using
|
|
|
|
# SPEED_VERYLOW, which matches the HAL_PX4 setup
|
|
|
|
PD10 FRAM_CS CS SPEED_VERYLOW
|
|
|
|
|
|
|
|
# now we start defining some PWM pins. We also map these pins to GPIO
|
|
|
|
# values, so users can set BRD_PWM_COUNT to choose how many of the PWM
|
|
|
|
# outputs on the primary MCU are setup as PWM and how many as
|
|
|
|
# GPIOs. To match HAL_PX4 we number the GPIOs for the PWM outputs
|
|
|
|
# starting at 50
|
|
|
|
PE14 TIM1_CH4 TIM1 PWM(1) GPIO(50)
|
|
|
|
PE13 TIM1_CH3 TIM1 PWM(2) GPIO(51)
|
|
|
|
PE11 TIM1_CH2 TIM1 PWM(3) GPIO(52)
|
|
|
|
PE9 TIM1_CH1 TIM1 PWM(4) GPIO(53)
|
|
|
|
PD13 TIM4_CH2 TIM4 PWM(5) GPIO(54)
|
|
|
|
PD14 TIM4_CH3 TIM4 PWM(6) GPIO(55)
|
|
|
|
|
2019-03-29 09:09:12 -03:00
|
|
|
# Pin for PWM Voltage Selection
|
2019-04-01 05:16:01 -03:00
|
|
|
PB4 PWM_VOLT_SEL OUTPUT HIGH GPIO(3)
|
2019-03-29 09:09:12 -03:00
|
|
|
|
2018-06-05 19:13:38 -03:00
|
|
|
# this is the invensense data-ready pin. We don't use it in the
|
|
|
|
# default driver
|
|
|
|
PD15 MPU_DRDY INPUT
|
|
|
|
|
|
|
|
# now the 2nd GPS UART
|
|
|
|
# UART8 serial4 GPS2
|
|
|
|
PE0 UART8_RX UART8
|
|
|
|
PE1 UART8_TX UART8
|
|
|
|
|
|
|
|
# now setup SPI bus4
|
|
|
|
PE2 SPI4_SCK SPI4
|
|
|
|
PE5 SPI4_MISO SPI4
|
|
|
|
PE6 SPI4_MOSI SPI4
|
|
|
|
|
|
|
|
# this is the pin to enable the sensors rail. It can be used to power
|
|
|
|
# cycle sensors to recover them in case there are problems with power on
|
|
|
|
# timing affecting sensor stability. We pull it high by default
|
|
|
|
PE3 VDD_3V3_SENSORS_EN OUTPUT HIGH
|
|
|
|
|
|
|
|
# UART7 maps to uartF in the HAL (serial5 in SERIALn_ parameters)
|
|
|
|
PE7 UART7_RX UART7
|
|
|
|
PE8 UART7_TX UART7
|
|
|
|
|
|
|
|
# define a LED, mapping it to GPIO(0)
|
|
|
|
PE12 FMU_LED_AMBER OUTPUT GPIO(0)
|
|
|
|
|
|
|
|
# power flag pins. These tell the MCU the status of the various power
|
|
|
|
# supplies that are available. The pin names need to exactly match the
|
|
|
|
# names used in AnalogIn.cpp.
|
2020-02-13 04:06:12 -04:00
|
|
|
PB5 VDD_BRICK_nVALID INPUT PULLUP
|
|
|
|
PB7 VDD_BRICK2_nVALID INPUT PULLUP
|
|
|
|
PE10 VDD_5V_HIPOWER_nOC INPUT PULLUP
|
|
|
|
PE15 VDD_5V_PERIPH_nOC INPUT PULLUP
|
2018-06-05 19:13:38 -03:00
|
|
|
|
|
|
|
# now the SPI device table. This table creates all accessible SPI
|
|
|
|
# devices, giving the name of the device (which is used by device
|
|
|
|
# drivers to open the device), plus which SPI bus it it on, what
|
|
|
|
# device ID will be used (which controls the IDs used in parameters
|
|
|
|
# such as COMPASS_DEV_ID, so we can detect when the list of devices
|
|
|
|
# changes between reboots for calibration purposes), the SPI mode to
|
|
|
|
# use, and the low and high speed settings for the device
|
|
|
|
|
|
|
|
# You can define more SPI devices than you actually have, to allow for
|
|
|
|
# flexibility in board setup, and the driver code can probe to see
|
|
|
|
# which are responding
|
|
|
|
|
|
|
|
# The DEVID values and device names are chosen to match the PX4 port
|
|
|
|
# of ArduPilot so users don't need to re-do their accel and compass
|
|
|
|
# calibrations when moving to ChibiOS
|
|
|
|
|
2019-03-10 21:17:38 -03:00
|
|
|
SPIDEV ms5611 SPI1 DEVID3 BARO_CS MODE3 20*MHZ 20*MHZ
|
2018-06-05 19:13:38 -03:00
|
|
|
SPIDEV ms5611_ext SPI4 DEVID2 BARO_EXT_CS MODE3 20*MHZ 20*MHZ
|
2019-03-10 21:17:38 -03:00
|
|
|
SPIDEV mpu6000 SPI1 DEVID4 MPU_CS MODE3 2*MHZ 8*MHZ
|
|
|
|
SPIDEV icm20608-am SPI1 DEVID2 ACCEL_EXT_CS MODE3 4*MHZ 8*MHZ
|
|
|
|
SPIDEV mpu9250 SPI1 DEVID4 MPU_CS MODE3 4*MHZ 8*MHZ
|
2018-06-05 19:13:38 -03:00
|
|
|
SPIDEV mpu9250_ext SPI4 DEVID1 MPU_EXT_CS MODE3 4*MHZ 8*MHZ
|
2019-03-10 21:17:38 -03:00
|
|
|
SPIDEV icm20948 SPI1 DEVID4 MPU_CS MODE3 4*MHZ 8*MHZ
|
|
|
|
SPIDEV icm20948_ext SPI4 DEVID1 MPU_EXT_CS MODE3 4*MHZ 8*MHZ
|
2018-06-05 19:13:38 -03:00
|
|
|
SPIDEV hmc5843 SPI1 DEVID5 MAG_CS MODE3 11*MHZ 11*MHZ
|
2019-03-10 21:17:38 -03:00
|
|
|
SPIDEV lsm9ds0_g SPI1 DEVID1 GYRO_EXT_CS MODE3 11*MHZ 11*MHZ
|
|
|
|
SPIDEV lsm9ds0_am SPI1 DEVID2 ACCEL_EXT_CS MODE3 11*MHZ 11*MHZ
|
|
|
|
SPIDEV lsm9ds0_ext_g SPI4 DEVID4 GYRO_EXT_CS MODE3 11*MHZ 11*MHZ
|
|
|
|
SPIDEV lsm9ds0_ext_am SPI4 DEVID3 ACCEL_EXT_CS MODE3 11*MHZ 11*MHZ
|
|
|
|
SPIDEV icm20602_ext SPI4 DEVID4 GYRO_EXT_CS MODE3 4*MHZ 8*MHZ
|
|
|
|
SPIDEV ramtron SPI2 DEVID10 FRAM_CS MODE3 8*MHZ 8*MHZ
|
2018-06-05 19:13:38 -03:00
|
|
|
SPIDEV external0m0 SPI4 DEVID5 MPU_EXT_CS MODE0 2*MHZ 2*MHZ
|
|
|
|
SPIDEV external0m1 SPI4 DEVID5 MPU_EXT_CS MODE1 2*MHZ 2*MHZ
|
|
|
|
SPIDEV external0m2 SPI4 DEVID5 MPU_EXT_CS MODE2 2*MHZ 2*MHZ
|
|
|
|
SPIDEV external0m3 SPI4 DEVID5 MPU_EXT_CS MODE3 2*MHZ 2*MHZ
|
|
|
|
SPIDEV pixartPC15 SPI4 DEVID13 ACCEL_EXT_CS MODE3 2*MHZ 2*MHZ
|
|
|
|
|
|
|
|
# Now some commented out SPI device names which can be used by
|
|
|
|
# developers to test that the clock calculations are right for a
|
|
|
|
# bus. This is used in conjunction with the mavproxy devop module
|
|
|
|
|
|
|
|
# for SPI clock testing
|
|
|
|
#SPIDEV clock500 SPI4 DEVID5 MPU_EXT_CS MODE0 500*KHZ 500*KHZ # gives 329KHz
|
|
|
|
#SPIDEV clock1 SPI4 DEVID5 MPU_EXT_CS MODE0 1*MHZ 1*MHZ # gives 657kHz
|
|
|
|
#SPIDEV clock2 SPI4 DEVID5 MPU_EXT_CS MODE0 2*MHZ 2*MHZ # gives 1.3MHz
|
|
|
|
#SPIDEV clock4 SPI4 DEVID5 MPU_EXT_CS MODE0 4*MHZ 4*MHZ # gives 2.6MHz
|
|
|
|
#SPIDEV clock8 SPI4 DEVID5 MPU_EXT_CS MODE0 8*MHZ 8*MHZ # gives 5.5MHz
|
|
|
|
#SPIDEV clock16 SPI4 DEVID5 MPU_EXT_CS MODE0 16*MHZ 16*MHZ # gives 10.6MHz
|
|
|
|
|
2020-12-23 22:02:11 -04:00
|
|
|
# three IMUs, but allow for different variants. First two IMUs are
|
2019-05-29 22:16:32 -03:00
|
|
|
# isolated, 3rd isn't
|
|
|
|
IMU Invensense SPI:mpu9250_ext ROTATION_PITCH_180
|
|
|
|
|
|
|
|
# the 3 rotations for the LSM9DS0 driver are for the accel, the gyro
|
2020-12-23 22:02:11 -04:00
|
|
|
# and the H variant of the gyro
|
2019-05-29 22:16:32 -03:00
|
|
|
IMU LSM9DS0 SPI:lsm9ds0_ext_g SPI:lsm9ds0_ext_am ROTATION_ROLL_180_YAW_270 ROTATION_ROLL_180_YAW_90 ROTATION_ROLL_180_YAW_90
|
|
|
|
|
|
|
|
# 3rd non-isolated IMU
|
|
|
|
IMU Invensense SPI:mpu9250 ROTATION_YAW_270
|
|
|
|
|
|
|
|
# alternative IMU set for newer cubes
|
|
|
|
IMU Invensense SPI:icm20602_ext ROTATION_ROLL_180_YAW_270
|
|
|
|
IMU Invensensev2 SPI:icm20948_ext ROTATION_PITCH_180
|
|
|
|
IMU Invensensev2 SPI:icm20948 ROTATION_YAW_270
|
|
|
|
|
2019-07-10 20:11:47 -03:00
|
|
|
define HAL_DEFAULT_INS_FAST_SAMPLE 5
|
2019-05-29 22:16:32 -03:00
|
|
|
|
|
|
|
# two baros
|
|
|
|
BARO MS56XX SPI:ms5611_ext
|
|
|
|
BARO MS56XX SPI:ms5611
|
|
|
|
|
|
|
|
# two compasses. First is in the LSM303D
|
|
|
|
COMPASS LSM303D SPI:lsm9ds0_ext_am ROTATION_YAW_270
|
|
|
|
# 2nd compass is part of the 2nd invensense IMU
|
|
|
|
COMPASS AK8963:probe_mpu9250 1 ROTATION_YAW_270
|
|
|
|
|
|
|
|
# compass as part of ICM20948 on newer cubes
|
|
|
|
COMPASS AK09916:probe_ICM20948 0 ROTATION_ROLL_180_YAW_90
|
|
|
|
|
|
|
|
# also probe for external compasses
|
|
|
|
define HAL_PROBE_EXTERNAL_I2C_COMPASSES
|
|
|
|
|
2018-06-05 19:13:38 -03:00
|
|
|
# this adds a C define which sets up the ArduPilot architecture
|
|
|
|
# define. Any line starting with 'define' is copied literally as
|
|
|
|
# a #define in the hwdef.h header
|
|
|
|
define HAL_CHIBIOS_ARCH_FMUV3 1
|
|
|
|
|
|
|
|
# now some defines for logging and terrain data files
|
|
|
|
define HAL_BOARD_LOG_DIRECTORY "/APM/LOGS"
|
|
|
|
define HAL_BOARD_TERRAIN_DIRECTORY "/APM/TERRAIN"
|
|
|
|
|
|
|
|
# we need to tell HAL_ChibiOS/Storage.cpp how much storage is
|
|
|
|
# available (in bytes)
|
2021-03-17 02:55:45 -03:00
|
|
|
define HAL_STORAGE_SIZE 32768
|
2018-06-05 19:13:38 -03:00
|
|
|
|
2018-08-13 17:21:55 -03:00
|
|
|
# allow to have have a dedicated safety switch pin
|
|
|
|
define HAL_HAVE_SAFETY_SWITCH 1
|
|
|
|
|
2018-06-05 19:13:38 -03:00
|
|
|
# this enables the use of a ramtron device for storage, if one is
|
|
|
|
# found on SPI. You must have a ramtron entry in the SPI device table
|
|
|
|
|
|
|
|
# enable RAMTROM parameter storage
|
|
|
|
define HAL_WITH_RAMTRON 1
|
|
|
|
|
2018-06-05 22:04:49 -03:00
|
|
|
# setup for the possibility of an IMU heater as the The CUBE has
|
2018-06-05 19:13:38 -03:00
|
|
|
# an IMU header
|
|
|
|
define HAL_HAVE_IMU_HEATER 1
|
|
|
|
|
|
|
|
# enable FAT filesystem support (needs a microSD defined via SDIO)
|
|
|
|
define HAL_OS_FATFS_IO 1
|
|
|
|
|
|
|
|
# now setup the default battery pins driver analog pins and default
|
|
|
|
# scaling for the power brick
|
|
|
|
define HAL_BATT_VOLT_PIN 2
|
|
|
|
define HAL_BATT_CURR_PIN 3
|
|
|
|
define HAL_BATT_VOLT_SCALE 10.1
|
|
|
|
define HAL_BATT_CURR_SCALE 17.0
|
2019-03-29 09:09:12 -03:00
|
|
|
define HAL_GPIO_PWM_VOLT_PIN 3
|
2020-07-17 19:09:51 -03:00
|
|
|
define HAL_GPIO_PWM_VOLT_3v3 1
|
2018-06-05 19:13:38 -03:00
|
|
|
|
|
|
|
# this defines the default maximum clock on I2C devices.
|
|
|
|
define HAL_I2C_MAX_CLOCK 100000
|
|
|
|
|
|
|
|
# we can't share IO UART (USART6)
|
|
|
|
DMA_NOSHARE USART6_TX USART6_RX ADC1
|
|
|
|
DMA_PRIORITY USART6*
|
|
|
|
|
2018-06-16 08:09:31 -03:00
|
|
|
# start on 4th sector (1st sector for bootloader, 2 for extra storage)
|
|
|
|
FLASH_RESERVE_START_KB 96
|
|
|
|
|
|
|
|
# fallback storage in case FRAM is not populated
|
|
|
|
define STORAGE_FLASH_PAGE 1
|
2018-06-05 19:13:38 -03:00
|
|
|
|
|
|
|
# list of files to put in ROMFS. For fmuv3 we need an IO firmware so
|
|
|
|
# we can automatically update the IOMCU firmware on boot. The format
|
|
|
|
# is "ROMFS ROMFS-filename source-filename". Paths are relative to the
|
|
|
|
# ardupilot root
|
2019-07-21 23:51:13 -03:00
|
|
|
ROMFS io_firmware.bin Tools/IO_Firmware/iofirmware_highpolh.bin
|
2020-12-30 02:44:19 -04:00
|
|
|
|