Extend hwdef system to Linux HAL

[peterbarker]

Lightly factors libraries/AP_HAL_ChibiOS/hwdef/scripts/chibios_hwdef.py into libraries/AP_HAL/hwdef/scripts/hwdef.py and ChibiOSHWDef starts to inherit from HWDef

Creates libraries/AP_HAL_Linux/hwdef/scripts/linux_hwdef.py and LinuxHWDef inherits from HWDef.

Creates hwdef files for Linux build targets in libraries/AP_HAL_Linux/hwdef/<boardname>

Moves defines from #if block based on linux built subtype into those hwdefs.

Removes checks of linux-board-subtype in various libraries, replacing them with simple defines in the new hwdefs.

Allows parsing of LINUX_SPIDEV lines in the Linux hwdef files, replacing static definitions in libraries/AP_HAL_Linux/SPIDevice.cpp.

This is by no means a complete movement to hwdef, but I think it's at a reasonable point to merge.

Still to do (at least...):

• move specification of tool-chain into the hwdef (eg. navigator64 requires aarch64) (I have patches for this)
• magically generate boards from contents of the hwdef directory, as we do for ChibiOS
• move compass, baro and IMU declarations into hwdef, out of static delcarations in Linux HAL
• remove subtype definition use in Sub-related code
• remove use of subtype definitions within the Linux HAL
• remove subtype defintiions
• move AP_HAL_Linux::OpticalFlow_Onboard out into OpticalFlow, remove OF interface from HAL
• use LinuxHWDef object in place of static lists when determining board types

The output for this PR is binary-identical to the master it is based on, at least for the ChibiOS boards and these:

            Board("erlebrain2"),
            Board("navigator"),
            Board("navigator64"),
            Board("navio"),
            Board("navio2"),
            Board("edge"),
            Board("obal"),
            Board("pxf"),
            Board("bbbmini"),
            Board("bebop"),
            Board("blue"),
            Board("pxfmini"),
            Board("canzero"),

Notably missing are the zynq boards (xilinx).

For reference, the Navigator hwdef:

# BlueRobotics Navigator

# I2C6 is the only i2c one exposed on a header
define HAL_LINUX_I2C_EXTERNAL_BUS_MASK 1 << 6

# We don't want any probing on the internal buses
define HAL_LINUX_I2C_INTERNAL_BUS_MASK 0
define AP_NOTIFY_NAVIGATOR_LED_ENABLED 1

#            NAME         BUS SUBDEV MODE       BPW CS_PIN         LOWSPD HIGHSPD
LINUX_SPIDEV "led"        0   0      SPI_MODE_0 8   SPI_CS_KERNEL  6*MHZ  6*MHZ
LINUX_SPIDEV "icm20602"   1   2      SPI_MODE_0 8   SPI_CS_KERNEL  4*MHZ  10*MHZ
LINUX_SPIDEV "mmc5983"    1   1      SPI_MODE_0 8   SPI_CS_KERNEL  4*MHZ  10*MHZ

define HAL_LINUX_GPIO_RPI_ENABLED 1
define HAL_LINUX_GPIO_NAVIGATOR_ENABLED 1

define HAL_BATT_VOLT_PIN                  5
define HAL_BATT_CURR_PIN                  4
define HAL_BATT_VOLT_SCALE                11.0f
define HAL_BATT_CURR_SCALE                37.8788f
define AP_BATT_CURR_AMP_OFFSET_DEFAULT    0.330f

[andyp1per]

Amazing! No idea how you verify, I suppose configure all?

[tridge]

@Williangalvani can you look at and approve this? I think this is ready, but would like you to test it in your build env

[Williangalvani]

Very nice! I tested on Navigator64 and everything looks good.

The only think that caught my attention is having an env.py being a pickled file instead of actual python code, but that is already in chibios.py, too.

[peterbarker]

Very nice! I tested on Navigator64 and everything looks good.

The only think that caught my attention is having an env.py being a pickled file instead of actual python code, but that is already in chibios.py, too.

LOL. @tpwrules was similarly vexed when reviewing this PR!

Thanks for looking.