* boards: enable CONFIG_FS_LARGEFILE for NuttX boards with MMC/SD
Without large file support, fsblkcnt_t/off_t are 32-bit and statfs
consumers (procfs /fs/usage, df) compute the volume size as
f_bsize * f_blocks in 32 bits, which wraps at 4GB. Boards with an
SD card or eMMC larger than 4GB report the wrong capacity, e.g. a
32GB SD card on FMU-V6X:
nsh> ls -l /dev/mmcsd0
brw-rw-rw-1850212352 /dev/mmcsd0 (= 31914983424 mod 2^32)
nsh> df -h
vfat 1749M 240K 1749M /fs/microsd
With CONFIG_FS_LARGEFILE=y the same card reports the full 29G.
This enables the option on the 77 boards that build the MMC/SD block
driver (CONFIG_MMCSD=y, SDIO or SPI). Boards without removable storage
and constrained-flash targets (CONFIG_BOARD_CONSTRAINED_FLASH=y) are
left unchanged.
Note: on the px4_firmware_nuttx-10.3.0+ branch the 64-bit file types
are additionally gated on CONFIG_HAVE_LONG_LONG, which is only defined
via nuttx/compiler.h include order, making the option unreliable. That
gating is fixed by the companion NuttX backport PR
(PX4/NuttX, branch backport-fs-largefile, upstream commit 92b2f1bd3d3).
Tested on a custom STM32H743 board with 8GB eMMC and on FMU-V6X with a
32GB SD card.
* fix(boards): enable CONFIG_FS_LARGEFILE for MMC/SD variant configs
The test/console/stackcheck/socketcan/sysview/cyphal/debug/cryptotest
variant configs of boards covered by the previous commit were missed,
leaving them with 32-bit off_t. fmu-v5 protected is intentionally
excluded: protected-mode syscall proxies keep 32-bit widths.
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
* chore(nuttx): bump submodule for FS_LARGEFILE backport
Picks up the backport of upstream NuttX 92b2f1bd3d3, which gates the
64-bit file types on CONFIG_FS_LARGEFILE alone instead of the
include-order-dependent CONFIG_HAVE_LONG_LONG.
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
---------
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
Co-authored-by: Jacob Dahl <dahl.jakejacob@gmail.com>
* feat(gps): inject SPARTN corrections alongside RTCM
Add a SPARTN transport-layer framer and feed gps_inject_data through both
RTCM3 and SPARTN parsers so PointPerfect-style SPARTN streams can be
reassembled and written to the receiver the same way RTCM already is.
Gated by CONFIG_GPS_SPARTN (default on). Disabled on px4_fmu-v6x where
flash is already at the limit; enabled on ark_can-rtk-gps.
Depends on PX4-GPSDrivers for automatic u-blox SPARTN input enable.
Signed-off-by: alexklimaj <alex@arkelectron.com>
* fix(gnss): avoid undefined shift in SPARTN CRC-32
Use uint64_t for the CRC working register so n==32 does not perform
1u << 32 (clang-analyzer BitwiseShift).
Signed-off-by: alexklimaj <alex@arkelectron.com>
* make format
* feat(gps): enable SPARTN support in board configurations
* feat(gps): enhance SPARTN support with additional frame tracking and status reporting
* fix(gps): frame RTCM3 and SPARTN from a single buffer
Feeding every inject chunk to an independent framer per protocol let each
one resync inside the other's payloads. That is not symmetric: RTCM3 is
covered by CRC-24Q, but SPARTN's header carries no usable integrity check
(TF006 is 4 bits over a non-byte-aligned field) and TF005 permits an 8-bit
message CRC, so a stray 0x73 in an RTCM3 payload is framed as SPARTN at
roughly 1 in 1024.
RTCM3-only is what every board actually runs, and over 50 MB of it the two
framers produced 211 bogus SPARTN frames (210 declaring CRC-8), each
re-injecting up to 1 kB of the stream back into the receiver. The reverse
direction produced none.
Frame both protocols from one buffer instead: whichever preamble comes
first is framed, and a valid frame consumes its own payload, so bytes
inside one protocol's frame never start the other's. The same 50 MB now
yields zero. Frames are also injected in arrival order rather than all
RTCM3 then all SPARTN, and one buffer replaces two (2248 B/instance,
down from ~4350 B).
Also reject TF002 message types 5-119, which SPARTN reserves, as the one
header field with a checkable range.
CONFIG_GPS_SPARTN was default y, so it built into every target with a GPS
including px4_fmu-v6x, which the flash report showed gaining the framer
despite the intent to keep it off. Default it to n and enable it explicitly
where it is wanted; the ark GPS boards already opt in, and SITL opts in so
the framing tests keep running in CI.
Rtcm3Parser and SpartnParser are replaced by CorrectionFramer; their tests
carry over to it. RtcmStress fed "garbage" drawn from 0x01-0xD2 to avoid a
preamble, which includes 0x73, and RtcmBustedSender ended its stream on a
candidate the framer was still waiting to complete; both now avoid every
preamble and flush respectively.
* feat(gps): enable SPARTN on ARK flight controllers
Covers receivers attached over UART rather than CAN. All four targets
link with margin; fmu-v6xrt has no px4board on this branch yet.
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
---------
Signed-off-by: alexklimaj <alex@arkelectron.com>
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
Co-authored-by: Jacob Dahl <dahl.jakejacob@gmail.com>
* fix(boards/ark/fpv): split FW/VTOL into separate builds for flash
Default ark_fpv is multicopter-only so listener and sd_bench fit in
flash. Fixed-wing and VTOL stacks move to ark_fpv_fw and ark_fpv_vtol,
which disable those two system commands to stay under the limit.
Signed-off-by: alexklimaj <alex@arkelectron.com>
* fix(boards/ark/fpv): trim optional modules from vtol build
Drop gimbal, gyro_fft, autotune, camera, payload, and debug systemcmds
from ark_fpv_vtol so the full VTOL stack fits with more flash margin.
Signed-off-by: alexklimaj <alex@arkelectron.com>
* fix(boards/ark/fpv): keep more modules on vtol; trim only debug extras
Restore autotune, gimbal, gyro_fft, mag bias, payload, camera, esc
battery, and actuator_test on ark_fpv_vtol. Keep flash margin by
leaving sd_bench, listener, bsondump, i2cdetect, and pca9685 off.
Signed-off-by: alexklimaj <alex@arkelectron.com>
---------
Signed-off-by: alexklimaj <alex@arkelectron.com>
* feat(navigator): extend detect and avoid module to follow regulatory standards such as ASTM F3442
* docs(docs): minor subedit
* refactor(navigator): reduce flash by grouping notif into same events
* docs(daa): Improve docs readability with ::: details blocks
* fix(navigator): single event when on ground with conflict
* refactor(boards): increase flash length from 4M - 128k to 5M - 128k
* rework(general): define DAA standard at build with new CONFIG_NAVIGATOR_ADSB_F3442
* clean(navigator): minor changes to clean the PR
* feat(boards): add CONFIG_NAVIGATOR_ADSB_FAKE_TRAFFIC in visionTargetEstStatic.px4board
* rework(daa): reduce amount of abstractions and minor cleaning
* refactor(boards): allyes revert flash length to 4M-128K
* refactor(boards): allyes increase flash length to 5M-128K
* rework(daa): rework event notifications to improve clarity
* docs(docs): move details inside of ::: details block
* docs(docs): run npx prettier
* refactor(daa): avoid void mutator functions
* docs(docs): Improve Python helper to decode daa unique id
* rework(daa): move encoded id handling to the adsb lib and refactor on_active
* refactor(daa): naming and zero init
* fix(daa): move dataman dep from daa level to unit test level
* refactor(daa): define common daa_input and rework process_transponder_report
* fix(daa): remove stale todo
* refactor(daa): rename crosstrack_based_daa to crosstrack_standard
* refactor(daa): rename F34_ params to DAA_
* docs(docs): revert changes to autogenerated docs
* docs(docs): Add Detect And Avoid in index.md
* refactor(daa): update message on init failed
* refactor(daa): only publish most_urgent conflict once in on_active()
* refactor(daa): move conflict buffer handling in the adsb lib
* refactor(daa): move notifications into new class ConflictNotifier and only notify once per cycle
* refactor(daa): uninit _cycle_changes to store into .bss (and save flash)
* docs(docs): remove unused image link
* refactor(daa): move automated action policy to the adsb lib
* refactor(daa): move self detection into adsb lib as DaaTrafficFilter
* refactor(daa): minor changes in unit tests
* refactor(daa): merge DaaTrafficFilter and DaaEncoding
* fix(daa): fix CI by removing navigator from the DAA deps
* refactor(daa): reduce stack size
* fix(daa): advertise _fake_traffic_pub in constructor
* refactor(daa): Comments only, simplify and reduce comments
* fix(daa): brief comment missing end star
* Disable CONFIG_NAVIGATOR_ADSB in ark_fpv_default board
* docs(docs): General clarifications and remove the 1.18 badge
* refactor(daa): cleaning
* refactor(daa): minor cleaning
* refactor(adsb): simplify conflict tracker assuming push_back cannot fail
* build(cmake): cleaner fix to protect regex alternations
* refactor(daa): Crosstrack, remove unit test requiring finite yaw (yaw not used by standard)
* refactor(daa): minor cleaning and fix callsign to uint64
---------
Co-authored-by: jonas <jonas.perolini@rigi.tech>
Co-authored-by: Hamish Willee <hamishwillee@gmail.com>
Plan RTL paths that route around geofence boundaries — both inclusion
and exclusion zones — instead of flying straight through them and
breaching. The planner builds a visibility graph over the margin-inflated
geofence polygons and circles and runs Dijkstra to find the shortest
legal return path, falling back to a straight line to the destination
when no valid path exists.
Highlights:
- New reusable libraries: src/lib/dijkstra (generic shortest path) and
src/lib/geofence (fixed-point geometry, polygon inflation, bitangent
visibility); the RTL planner lives in navigator/RTLPlanner.
- Visibility graph keeps only bitangent edges and skips edges that poke
into a forbidden region, greatly reducing edge-cost computation.
- Corner splitting is limited to sharp convex corners.
- Geometry validation: reject self-intersecting polygons and vertices
outside the fixed-point range; centimeter fixed-point scaling keeps
orientation tests exact and avoids drift at large distances.
- Failure handling: a Status enum replaces silent bool returns, and
failures (unbuildable fence, planner capacity overflow, dataman load
errors, NaN waypoints, destinations that breach the fence) are
surfaced to the operator via MAVLink warnings/criticals; the planner
falls back to a straight-line RTL.
- Destination updates are centralized in RTL::setRtlTypeAndDestination;
the path is replanned only when the destination or geometry changes.
- VTOLs always use the fixed-wing margin (FW loiter radius).
- kMaxNodes is exposed as a Kconfig option (default 100); the feature is
disabled on flash-constrained boards (FMUv4 and older, various F4/F7).
- Tests: unit tests for the Dijkstra lib, geofence geometry utils, and
the avoidance planner, plus a MAVSDK SITL test flying an RTL through a
geofence.
- Documentation: new "Geofence Awareness" section in the RTL docs.
Co-authored-by: Balduin <balduin@auterion.com>
The per-channel send mutex is genuinely recursive: callers hold lock_send()
while the MAVLink C library re-enters send_start()/send_finish() on the same
mutex via MAVLINK_START_UART_SEND. On NuttX a recursive mutex only works with
CONFIG_PTHREAD_MUTEX_TYPES; without it pthread_mutexattr_settype() is a no-op
and the nested lock deadlocks. Only a handful of boards happened to enable the
option (for Zenoh), so mavlink could deadlock at startup on most boards, e.g.
when bringing up a USB link.
Enable CONFIG_PTHREAD_MUTEX_TYPES on the NuttX boards that build mavlink, add
a compile-time guard so a board missing the option fails the build loudly
instead of deadlocking silently, and check the settype() return. Enabling the
option is free in flash and RAM on these boards since they already enable
CONFIG_PRIORITY_INHERITANCE / CONFIG_PTHREAD_MUTEX_ROBUST.
Signed-off-by: Julian Oes <julian@oes.ch>
PB2 has no timer alternate function on the F412, so declare
PPS_CAPTURE_GPIO for the EXTI path, enable CONFIG_DRIVERS_PPS_CAPTURE, and
start pps_capture from rc.board_sensors.
* fix(boards): update STM32H7 bootloaders with ECC scrub and enable bl_update
The committed extras/*_bootloader.bin for every STM32H7 flash-parameter
target predate #27642, so none carry the uncorrectable-flash-ECC scrub
that keeps a torn parameter-flash write from bricking the board on every
boot. Rebuild each bootloader from current main with the release
toolchain (GCC 13.2.1) and enable CONFIG_SYSTEMCMDS_BL_UPDATE so the fix
can be applied in the field via SYS_BL_UPDATE without a debugger; the
~40-45 KB image is embedded in ROMFS only when the option is on.
ark/fpv drops LANDING_TARGET_ESTIMATOR to fit the embedded image,
x-mav/ap-h743v2 gets its first committed bin, and a stray duplicate
bootloader bin is removed from kakuteh7dualimu/extras.
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
* fix(boards): remove SCH16T from ARK FPV mavlink-dev.px4board
---------
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
Vendor-specific airframes (Holybro, UVify, ATL, COEX, Bitcraze,
ThunderFly, Applied Aeronautics) are not relevant on the ARK FMU
boards and only consume flash. Add an rc.board_airframes whitelist
to ark_fmu-v6x and ark_fmu-v6s that keeps only the generic
multirotor, fixed-wing, VTOL, and rover frame types.
Flash savings (default variant):
ark_fmu-v6x: 1965708 -> 1957772 B (-7936 B, free 372 -> 8308 B)
ark_fmu-v6s: 1960212 -> 1945748 B (-14464 B, free 8108 -> 22572 B)
Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com>
Set CONFIG_STM32H7_DTCMEXCLUDE=y on the four STM32H7 ARK boards
(fmu-v6x, fmu-v6s, fpv, pi6x) so DTCM is no longer part of the kernel
heap. Stacks and dynamic buffers can otherwise land in DTCM, which AHB
DMA masters (SDMMC IDMA, MDMA, BDMA, DMA1/2) cannot access, causing file
operations to fail with EIO/ETIMEDOUT.
Refs PX4/PX4-Autopilot#27242.
The committed ark_fmu-v6s_bootloader.bin was built before BOARD_TYPE was
set to 61 in src/hw_config.h, so it advertises board id 57 (the v6x id)
to px_uploader. Uploading any v6s firmware then fails with:
Board mismatch: No suitable firmware for board 57 (available: [61])
Rebuild the bootloader from the current source so the binary reports
board id 61 and matches firmware.prototype.
* chore(boards): copy ark/fmu-v6x to ark/fmu-v6s
Verbatim copy of ark/fmu-v6x board support to ark/fmu-v6s to
establish a baseline. Functional changes will follow in the next commit.
* feat(boards): add ark/fmu-v6s board support
Low-cost variant of ARK V6X with:
- STM32H743IIK6 MCU (no hardware crypto)
- Single IIM-42653 IMU on SPI1 (SPI2/SPI3 removed)
- IIS2MDC magnetometer on I2C4
- BMP390 barometer on I2C4
- Single sensor power rail
Board ID 61, USB PID 0x003C.
* feat(px4_uploader): add ARK FMU v6s USB ID to the uploader
* refactor: rename SENS_IMU_TEMP to HEATER1_TEMP in rc.board_defaults
* refactor: remove unused ADC channel definitions in board_config.h
* refactor: update ADC channel definitions and remove unused sensor power control
* arkv6s sensor roations
* Add support for Murata SCH16T IMU in default.px4board configuration
* Update bootloader binary for FMU v6s
* Update boards/ark/fmu-v6s/src/hw_config.h
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
* Update boards/ark/fmu-v6s/src/hw_config.h
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
* fix(ark/fmu-v6s): enable CONFIG_CRYPTO for encrypted_logs build
CONFIG_CRYPTO_RANDOM_POOL was set without its parent CONFIG_CRYPTO,
so it was silently dropped and px4_get_secure_random was compiled out,
breaking the ark_fmu-v6s_encrypted_logs link.
---------
Co-authored-by: alexklimaj <alex@arkelectron.com>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
The bootloader boot-delay feature has been mechanically broken on
every modern FMU board since the STM32F7/H7 transition. It has three
independent bugs that prevent it from ever working:
1. Offset mismatch: BOOT_DELAY_ADDRESS is hardcoded to 0x1a0, but the
NuttX vector table is 504 B (F76x) to 664 B (H743) long. The
linker places _bootdelay_signature at ALIGN(32) past end of
vectors (e.g. 0x2a0 on CubeOrange), never at 0x1a0. The bootloader
reads random exception_common pointers in place of the magic and
never matches BOOT_DELAY_SIGNATURE1/2. Verified on CubeOrange with
objdump of cubepilot_cubeorange_default.elf.
2. Flash cache never flushes: fc_write() stores arbitrary writes in
cache line 1 and only flushes on a very specific condition tied
to the sequential firmware upload flow. A standalone write during
PROTO_SET_DELAY is cached forever. fc_read() then returns the
cached value, so the post-write verify lies and the bootloader
reports success. Nothing ever reaches flash.
3. H7 write granularity: the STM32H7 flash controller requires a
full 32-byte program cycle per write. Single 32-bit writes from
flash_func_write_word() would not be accepted by the controller
even if they reached it.
The feature has been silently dead on every H7/F7 FMU board for
years and no one noticed, which is strong evidence nothing actually
depends on it. Rather than fix it (which would mean rewriting
PROTO_SET_DELAY, the flash cache path, and the H7 flash programming
path), remove it.
Changes:
- bl.c: PROTO_SET_DELAY case now immediately NACKs (goto cmd_bad)
so clients that still send the command get a clear rejection
instead of the previous silent fake-success. The opcode stays in
the protocol enum for backwards compatibility.
- bl.h: drop BOOT_DELAY_SIGNATURE1/2 and BOOT_DELAY_MAX.
- stm/stm32_common/main.c, nxp/imxrt_common/main.c: drop the
startup boot-delay sig check block.
- image_toc.c: decouple find_toc() from BOOT_DELAY_ADDRESS.
BOARD_IMAGE_TOC_OFFSET is now the required define when
BOOTLOADER_USE_TOC is enabled. The body is wrapped in #ifdef
BOOTLOADER_USE_TOC and falls back to a stub returning false when
the TOC is not in use (no upstream board currently enables it).
- Linker scripts: strip EXTERN(_bootdelay_signature) and the
FILL/. += 8 block from all 142 affected .ld files across boards/.
- hw_config.h: strip the #define BOOT_DELAY_ADDRESS and its comment
block entry from all 48 affected boards.
- Tools/px4_uploader.py, Tools/teensy_uploader.py: remove --boot-delay,
set_boot_delay(), and SET_BOOT_DELAY client-side counterpart.
Smoke-built on cubepilot_cubeorange_default and
cubepilot_cubeorange_bootloader; no link errors, no unresolved
symbols, flash usage unchanged.
Tested:
- New BL, new FW
- Old BL, old FW
- Old BL, new FW
- New BL, old FW
* refactor: make timer_io_channels[].timer_channel 0-indexed
timer_channel was 1-indexed (1-4) to mirror STM32 hardware naming
(TIM_CH1-CH4), but this was purely cosmetic — the ccr_offset field
already handles register mapping. Every consumer did timer_channel - 1
to get a 0-based index, creating underflow bugs when the guard was
missing (e.g. dshot.c capture_complete_callback,
output_channel_from_timer_channel, up_bdshot_get_erpm).
Changes:
- STM32: Timer::Channel enum starts at 0, initIOTimerChannel assigns
directly, removed all timer_channel - 1 in dshot.c and io_timer.c
- NXP (kinetis, s32k1xx, s32k3xx): removed the + 1 in
initIOTimerChannel, removed timer_channel - 1 in io_timer.c,
led_pwm.cpp, and input_capture.c
- RPI: Channel enum starts at 0, removed timer_channel - 1 in
io_timer.c
- Validity checks updated from timer_channel <= 0 || >= 5 to
timer_channel >= 4
Closes#26747
Signed-off-by: Pavel Guzenfeld <pavelgu@gmail.com>
* fix: complete 0-indexed timer_channel migration across all platforms
Address review feedback for incomplete migration:
1. STM32H7 io_timer_hw_description.h: update standalone
initIOTimerChannel() to assign timer_channel from enum
(0-based) instead of hardcoded 1/2/3/4
2. Switch case labels: update all switch(timer_channel) blocks
from 1/2/3/4 to 0/1/2/3 in:
- stm32_common: input_capture.c (4 blocks), led_pwm.cpp (3),
io_timer.c DMA base register switch
- kinetis: input_capture.c (2 filter blocks)
- s32k1xx: input_capture.c (2 filter blocks)
- spix_sync.c (ark/fpv + ark/pi6x, 3 blocks each)
3. Sentinel checks: replace timer_channel != 0 / == 0 (which
now conflicts with valid channel 0) with gpio_out-based
checks in:
- io_timer_validate_channel_index() across all 5 platforms
- led_pwm_channel_init() and led_pwm_servo_get() in all
led_pwm.cpp variants (STM32 + 4 NXP)
- spix_sync_channel_init() and spix_sync_servo_get()
Tested: px4_fmu-v6x_default (H7) build OK, px4_sitl_default
build OK, 154/154 unit tests pass, ASan build clean.
* fix: update NXP board led_pwm_channels to 0-indexed timer_channel
These 4 board files manually specify led_pwm_channels[] with
1-indexed timer_channel values. Since the platform code no longer
subtracts 1, decrement all values to match the new 0-indexed
convention.
* fix: correct FTM CH3 filter mask in kinetis and s32k1xx input capture
Case 3 in up_input_capture_set_filter() was using CH2FVAL_MASK/SHIFT
instead of CH3FVAL_MASK/SHIFT due to a copy-paste error, causing
channel 3 filter writes to modify channel 2's filter register instead.
---------
Signed-off-by: Pavel Guzenfeld <pavelgu@gmail.com>
Co-authored-by: Jacob Dahl <dahl.jakejacob@gmail.com>
Overhauls the DShot driver with per-timer BDShot selection, multi-timer
sequential capture, Extended DShot Telemetry (EDT), and AM32 ESC EEPROM
read/write via MAVLink. Expands ESC support from 8 to 12 channels.
BDShot:
- Per-timer BDShot protocol selection via actuator config UI
- Multi-timer sequential burst/capture on any DMA-capable timer
- Adaptive per-channel GCR bitstream decoding
- Per-channel online/offline detection with hysteresis
Extended DShot Telemetry (EDT):
- Temperature, voltage, current from BDShot frames (no serial wire)
- New DSHOT_BIDIR_EDT parameter
- EDT data merged with serial telemetry when both available
AM32 EEPROM:
- Read/write AM32 ESC settings via MAVLink ESC_EEPROM message
- ESCSettingsInterface abstraction for future ESC firmware types
- New DSHOT_ESC_TYPE parameter
Other changes:
- Per-motor pole count params DSHOT_MOT_POL1–12 (replaces MOT_POLE_COUNT)
- EscStatus/EscReport expanded to 12 ESCs with uint16 bitmasks
- Numerous bounds-check, overflow, and concurrency fixes
- Updated DShot documentation
* fix(fmu-v6c): correct GPIO_VDD_3V3_SENSORS_EN macro name
VDD_3V3_SENSORS_EN() referenced GPIO_VDD_3V3_SENSORS4_EN which
does not exist. The correct macro is GPIO_VDD_3V3_SENSORS_EN.
Fixes#26454
* fix(boards): rename VDD_3V3_SENSORS4_EN to VDD_3V3_SENSORS_EN
These boards have a single sensor power rail that was incorrectly
named SENSORS4_EN (copy-paste from boards with 4 rails). Rename
to SENSORS_EN to match the actual hardware.
Boards with legitimately numbered rails (fmu-v6xrt, x25-evo,
x25-super) are not changed.
* refactor: use parseDefaultArguments
* style: reverted changes to docs (should be auto-generated)
* refactor: use parseDefaultArguments
* style: reverted changes to docs (should be auto-generated)
* heater: add multi-instance support, refactor parameter handling, remove legacy params file
This change introduces multi-instance heater support to allow independent temperature control for multiple IMUs.
Main changes:
- Add support for multiple heater instances
- Refactor parameter handling to use per-instance parameters
- Remove the legacy parameter file and migrate to the updated parameter structure
This improves scalability and makes heater configuration consistent across setups with multiple sensors.
* Refactor heater configuration across multiple boards
- Updated heater GPIO definitions to introduce a new naming convention for better clarity and consistency.
- Replaced `GPIO_HEATER_OUTPUT` with `GPIO_HEATER1_OUTPUT` and adjusted the corresponding output enable macros.
- Changed parameter names from `SENS_TEMP_ID` to `HEATER1_IMU_ID` in various board default configurations to reflect the new heater setup.
- Ensured all affected board configurations are updated to maintain functionality with the new heater definitions.
* heater: fix missing HEATER1_OUTPUT_EN control
* heater: fix more missing HEATER1_OUTPUT_EN control
* heater: tidy config, docs, and instance handling
- Remove unused controller period member and use CONTROLLER_PERIOD_DEFAULT
- Improve HEATER${i}_IMU_ID description and instance-related logging/behavior
- Add a guard when HEATER_NUM exceeds HEATER_MAX_INSTANCES
Note: drop intermediate/reverted change around the 'celsius' spelling.
* heater: refactor constructor to remove unused parameter and add instance name function
- Remove unused ModuleParams argument from Heater constructor
- Add heater_instance_name() helper to provide per-instance work queue task names
- Use instance-specific parameter lookup (HEATER{n}_*) during initialization
Use heater_instance_name() to label each instance (heater_1/2/3) in work queue.
Also drop unused ModuleParams argument from constructor and keep per-instance
parameter handle lookup in initialization.
* format
* board: update GPIO configuration for multiple heater instances, add HEATER_NUM for boards using PX4IO
* heater: update heater control to use HEATER1_OUTPUT_EN when using PX4IO for consistency
* heater: add a TODO for px4io multi-instance
* heater: update missing GPIO_HEATER1_OUTPUT in sky-drones
* heater: fix multiple newlines at EOF (resolve CI check failure)
* heater: switch to PublicationMulti for heater_status and log multi-instance
- Changed _heater_status_pub from Publication to PublicationMulti to support independent per-instance publications without overwriting.
- Updated logged_topics.cpp to use add_optional_topic_multi("heater_status")
This fixes the issue where multiple heater instances were writing to the same heater_status topic, causing data overwriting and incorrect update rates in logs.
---------
Co-authored-by: Jacob Dahl <dahl.jakejacob@gmail.com>
Co-authored-by: Jacob Dahl <37091262+dakejahl@users.noreply.github.com>
* ark fpv board_config: update battery ADC current filter time constant to 0.5s
* battery: add configurable voltage and current filter time constants
---------
Co-authored-by: Jacob Dahl <37091262+dakejahl@users.noreply.github.com>
* Adds configurable I2C address for PCA9685 PWM driver
Introduces a parameter to set the I2C address for the PCA9685 PWM output driver, enhancing flexibility for hardware variations. Updates documentation and board initialization scripts to support the new configuration and streamline device startup.
* Update src/drivers/pca9685_pwm_out/module.yaml
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
* Update src/drivers/pca9685_pwm_out/module.yaml
---------
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Jacob Dahl <37091262+dakejahl@users.noreply.github.com>
We should not build and release with the MAVLink development dialect
because messages in development.xml can change at any time and break
things.
Instead we should prototype and test things using specific mavlink-dev
targets.
