watchrobot/libraries/AP_HAL_ChibiOS/hwdef/CubeYellow/hwdef.dat

# The CUBE Yellow is a varient of The CUBE Black from ProfiCNC/Hex
# with a STM32F777 MCU

# 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

define STM32_LSECLK 32768U
define STM32_LSEDRV (3U << 3U)
define STM32_PLLSRC STM32_PLLSRC_HSE
define STM32_PLLM_VALUE 24
define STM32_PLLN_VALUE 432
define STM32_PLLP_VALUE 2
define STM32_PLLQ_VALUE 9

# board ID for firmware load
APJ_BOARD_ID 120

# with 2M flash we can afford to optimize for speed
env OPTIMIZE -O2

# 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

# board voltage
STM32_VDD 330U

# 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
# output from printf() lines will be thrown away (you can stil use
# hal.console->printf() for the ArduPilot console, which is the first
# UART in the UART_ORDER list). The value for STDOUT_SERIAL is a
# 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
USB_VENDOR 0x2DAE # ONLY FOR USE BY ProfiCNC / HEX! NOBODY ELSE
USB_PRODUCT 0x1012
USB_STRING_MANUFACTURER "Hex/ProfiCNC"
USB_STRING_PRODUCT "CubeYellow"
USB_STRING_SERIAL  "%SERIAL%"

# 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)
UART_ORDER OTG1 UART4 USART2 USART3 UART8 UART7 OTG2

# 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
PC0 VBUS_VALID INPUT

# 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)

# Pin for PWM Voltage Selection
PB4 PWM_VOLT_SEL OUTPUT HIGH GPIO(3)

# 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. 
PB5 VDD_BRICK_VALID INPUT PULLUP
PB7 VDD_SERVO_VALID INPUT PULLUP
PE10 VDD_5V_HIPOWER_OC INPUT PULLUP
PE15 VDD_5V_PERIPH_OC INPUT PULLUP

# 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

SPIDEV ms5611         SPI1 DEVID3  BARO_CS      MODE3 20*MHZ 20*MHZ
SPIDEV ms5611_ext     SPI4 DEVID2  BARO_EXT_CS  MODE3 20*MHZ 20*MHZ
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
SPIDEV mpu9250_ext    SPI4 DEVID1  MPU_EXT_CS   MODE3  4*MHZ  8*MHZ
SPIDEV icm20948       SPI1 DEVID4  MPU_CS       MODE3  4*MHZ  8*MHZ
SPIDEV icm20948_ext   SPI4 DEVID1  MPU_EXT_CS   MODE3  4*MHZ  8*MHZ
SPIDEV hmc5843        SPI1 DEVID5  MAG_CS       MODE3 11*MHZ 11*MHZ
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
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

# three IMUs, but allow for different varients. First two IMUs are
# 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
# and the H varient of the gyro
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

define HAL_DEFAULT_INS_FAST_SAMPLE 5

# 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

# 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)
define HAL_STORAGE_SIZE 16384

# allow to have have a dedicated safety switch pin
define HAL_HAVE_SAFETY_SWITCH 1

# 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

# setup for the possibility of an IMU heater as the The CUBE has
# 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

# enable RTSCTS support. You should define this if you have any UARTs
with RTS/CTS pins
define AP_FEATURE_RTSCTS 1

# enable SBUS_OUT on IOMCU (if you have an IOMCU)
define AP_FEATURE_SBUS_OUT 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
define HAL_GPIO_PWM_VOLT_PIN 3

# this defines the default maximum clock on I2C devices.
define HAL_I2C_MAX_CLOCK 100000

# uncomment the lines below to enable strict API
# checking in ChibiOS
# define CH_DBG_ENABLE_ASSERTS TRUE
# define CH_DBG_ENABLE_CHECKS TRUE
# define CH_DBG_SYSTEM_STATE_CHECK TRUE
# define CH_DBG_ENABLE_STACK_CHECK TRUE

# we can't share IO UART (USART6)
DMA_NOSHARE USART6_TX USART6_RX ADC1
DMA_PRIORITY USART6*

# 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

# 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
ROMFS io_firmware.bin Tools/IO_Firmware/iofirmware_highpolh.bin