Developer question -- where are target hardware boards defined?

ChrisAlbertson · August 18, 2018, 5:49pm

I guess someone must have to approve posting to the development list as “New Topic” is greyed out there. But it seems I can post here.

I’m completely new to ArduPilot software development, but not to software development. I just forked the source from Github and built it from source. I was impressed how easy this was.

Now I have a question: How are the various hardware target beads defined? I mean when I type “./waf list_boards” where does that list come from?

Next question: how do I know which physical flight controller board matches up to which was target. It should be clear but I don’t want to guess.

Some place there must be a big table that defines the characteristic of each target. I’d like to learn to add new targets.

LuisVale · August 18, 2018, 7:53pm

Hi, and welcome

ArduPilot is transitioning to Chibios and that has enabled easier ways to add support for new board. Here is a good example of what is required

github.com

ArduPilot/ardupilot/blob/master/libraries/AP_HAL_ChibiOS/hwdef/fmuv3/hwdef.dat

# hw definition file for processing by chibios_hwdef.py
# for FMUv3 hardware (ie. for Pixhawk1, Pixhawk2 cube, XUAV2.1 etc)

# This hwdef.dat file contains a lot of comments so it can act as a
# reference for developers adding new boards.

# The hwdef.dat file defines all the hardware peripherals and pins for
# a port of ArduPilot to a board using the ChibiOS HAL. You should be
# able to write the hwdef.dat file for a new board with just the
# schematic for the board.

# This file is processed by chibios_hwdef.py to create hwdef.h for
# this board. You may find it useful to run chibios_hwdef.py manually
# when building this file for a new board. The resulting hwdef.h file
# is formatted to make it quite readable. It is strongly suggested
# that you read the resulting hwdef.h file when porting to a new board
# to make sure it has resulted in what you want.

# You should read this file in conjunction with the schematic for your
# board, the datasheet for the MCU for your board and the python

This file has been truncated. show original

If you join the gitter channels you have a very active community on the Chibios channel, adding and optimising several new boards

james_pattison · August 18, 2018, 9:29pm

To expand a little, whilst the legacy/nuttx builds/targets are included in the waf make files, for ChibiOS the list is generated from the hwdef directory.
This means if you add a new target, you can simply ./waf configure board=new_target (where new_target is a folder in hwdef) without having to explicitly add new_target to the build system.
If your new board uses an MCU that is already supported (F412, F405, F427, F745, F767, maybe a couple of others), adding a new hwdef.dat is all that is necessary. If you need to add a new MCU it’s a bit more involved but a bunch of that is automated too.

ChrisAlbertson · August 19, 2018, 8:21am

Thanks. That is most of what I need to know. The file is called “hwdef.dat” and “Gitter”.

I have an idea I want to explore. A python program called maybe “beta2ardu” Give it a working Betaflight configuration for a board and it makes the files needed to support that board on ArduPilot.

The Betaflight CLI dump has everything I can think of you’d need to describe the board, specifically what resources are connected to which ARM M pins, the type of IMU and so on.

I will try ti implement one by hand and see how it goes.

marco3dr · December 7, 2022, 5:57am

Great idea, news about this?

james_pattison · May 26, 2023, 7:50am

github.com

ArduPilot/ardupilot/blob/master/libraries/AP_HAL_ChibiOS/hwdef/scripts/convert_betaflight_unified.py

#!/usr/bin/env python
'''
convert a betaflight unified configuration file into a hwdef.dat
currently very approximate, file requires cleanup afterwards
must be run from within a source tree as it relies on other other python files

code by Andy Piper <github@andypiper.com>
'''

import sys, re
import argparse

timers = {}
timers_by_name = {}
resources = {}
features = []
chip_select = {}
chip_select_by_type = {}
defines = {}

This file has been truncated. show original