; ===========================================================================
; hardware.ini - what this machine IS.
;
; Written once when the tower is assembled. Changing anything here means the
; hardware itself changed: a different board, a sensor fitted or removed, a
; cable moved to another port. Operational settings you tune to get better
; images - capture interval, camera profiles, scan grid, output paths - live in
; config.ini instead, and so does calibration, which is redone from time to time.
;
; WHERE THIS FILE GOES
;   /etc/fire_gimbal_control/hardware.ini
;
; That is beside credentials.env, and it is deliberately OUTSIDE the directory
; deploy.sh rsyncs: a deploy cannot overwrite or delete what it never touches.
; The program looks, in order, at:
;   --hardware <path>  |  $FGC_HARDWARE  |  /etc/...  |  beside config.ini
;
; Keys here override the same keys in config.ini, and any that are still set in
; both are named in a warning at startup so the stale copy can be deleted.
; ===========================================================================

; --- Which computer -------------------------------------------------------
[Board]
; Free-form, but keep it matching a directory under hardware/ so the setup kit
; for this board is easy to find.
model        = lattepanda-3-delta
; PlatformIO env used to build the motor firmware for this board's MCU.
;   lattepanda-3-delta / sigma -> leonardo      (ATmega32U4, 5V logic)
;   lattepanda-iota            -> iota_rp2040   (RP2040, 3.3V logic)
firmware_env = leonardo

; --- What is fitted -------------------------------------------------------
; This is a DECLARATION, and its whole purpose is that startup can compare it
; with what it actually finds. The program already copes gracefully when a part
; is missing - the pitch axis, the IMU, the ambient sensor - which is correct for
; a rig built without them, and indistinguishable from a fault on a rig that has
; them. Saying what was assembled is what tells those two apart.
[Hardware]
; Axes this gimbal has. A yaw-only rig says: axes = yaw
axes    = yaw, pitch
; Orientation sensor: a model name, or 'none'. Most of the fleet has none.
imu     = none
; Ambient temperature/humidity sensor: a model name, or 'none'.
env     = sht41
; The [Camera.<name>] blocks expected to be present and found.
cameras = rgb

; --- Where to find it -----------------------------------------------------
; Device bindings. These follow the hardware, not the tower, so they belong here
; rather than in config.ini.

[Serial]
; The motor controller MCU. Prefer the stable by-id symlink over /dev/ttyACM0,
; which is assigned in enumeration order and moves when USB devices change.
;   Leonardo : /dev/serial/by-id/usb-Arduino_LLC_Arduino_Leonardo-if00
device = /dev/serial/by-id/usb-Arduino_LLC_Arduino_Leonardo-if00
baud   = 115200

[IMU]
; Only read when [Hardware] imu is not 'none'. On the LattePanda 3 Delta the MTi
; is on the RS-232 header, which is a hardware UART: a stable /dev/ttyS* node,
; NOT a USB device and NOT /dev/ttyUSB0-3 (those are the modem).
device = /dev/ttyS0

[Env]
; Only read when [Hardware] env is not 'none'. This is the board's OWN native
; I2C bus, not the motor controller's serial link. The bus number varies by
; board - it is /dev/i2c-2 on the 3 Delta, not the /dev/i2c-1 default.
;
; Two traps when finding it: i2cdetect false-negatives on the SHT4x (probe with
; a real measurement instead), and an SMBus-only adapter can never work at all
; (i2cdetect -F N reports 'I2C = no').
i2c_device = /dev/i2c-2
i2c_addr   = 0x44

[Camera.rgb]
; The serial of the physical camera fitted to this tower. A USB DEV_ id, or a
; GigE IP address.
id = DEV_1AB22C049CD1