Added configs for supporting LSM6DS320x on ORBITF435

[orbittechnologyx]

The LSM6DSK320x will be used in the new ORBITF435 flight controllers due to a shortage of the ICM42688P.

[qodo-code-review]

ⓘ Qodo reviews are paused because the subscription is no longer active. Ask your workspace admin to reactivate the subscription to resume reviews. Manage billing

[qodo-free-for-open-source-projects]

PR Summary by Qodo

ORBITF435: add LSM6DS320x (LSM6DXX) IMU target configs as ICM42688P fallback

✨ Enhancement ⚙️ Configuration changes 🕐 10-20 Minutes

AI Description

• Enable LSM6DXX IMU support on ORBITF435 to mitigate ICM42688P shortages.
• Register an LSM6DXX SPI bus device descriptor on SPI1/PA4 with correct alignment.
• Keep existing ICM42605/ICM42688 descriptor so firmware can probe either IMU.

Diagram

graph TD
  A["ORBITF435 target.h"] --> B["IMU macros"] --> C["ORBITF435 target.c"] --> D["BUSDEV SPI tags"] --> E["SPI1"] --> F["IMU @ PA4 CS"]
  F --> G["LSM6DS320x"]
  F --> H["ICM42688"]

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Compile-time select a single IMU per target/variant

• ➕ Avoids probing two drivers against the same SPI CS, reducing boot-time and ambiguity.
• ➕ Eliminates any risk of one driver partially initializing and affecting the other.
• ➖ Requires separate build targets (or a board revision flag) to cover both BOM variants.
• ➖ Less flexible for mixed manufacturing runs without changing firmware artifacts.

2. Single busdev entry with runtime WHO_AM_I-based dispatch

• ➕ Keeps one SPI device descriptor, then selects the driver after reading device ID.
• ➕ Reduces duplicated CS/bus configuration and avoids double registration.
• ➖ Requires additional glue code/abstraction (or changes in the sensor init path).
• ➖ May be more intrusive than a target-only config change.

3. Keep both registrations but document expected behavior and priority

• ➕ Minimal change set; relies on existing sensor autodetect behavior.
• ➕ One firmware image can support either IMU depending on what is populated.
• ➖ Can increase probe time and may complicate debugging if both drivers log failures.
• ➖ If init order/side-effects aren’t well-controlled, could cause intermittent detection issues.

Recommendation: If the platform’s IMU init path is known to safely probe multiple SPI IMUs on the same CS and pick the one that responds, the current approach is acceptable and lowest-effort. Otherwise, prefer a compile-time selection (separate target/variant or board-revision flag) to ensure only one IMU driver is enabled/registered per hardware build, avoiding ambiguous probing on SPI1/PA4.

Files changed (2) +6 / -0

Other (2) +6 / -0

target.cRegister LSM6DXX SPI bus device descriptor +1/-0

Register LSM6DXX SPI bus device descriptor

• Adds a BUSDEV_REGISTER_SPI_TAG entry for the LSM6DXX IMU on the ORBITF435 target. The new descriptor uses the same SPI bus and CS pin mapping defined in the target header and specifies the LSM6DXX alignment.

src/main/target/ORBITF435/target.c

target.hEnable LSM6DXX IMU and define SPI/CS/alignment mappings +5/-0

Enable LSM6DXX IMU and define SPI/CS/alignment mappings

• Enables LSM6DXX IMU support via USE_IMU_LSM6DXX and defines its SPI bus (SPI1), chip-select pin (PA4), and alignment (CW270_DEG). This allows building firmware that can support LSM6DS320x on ORBITF435 as an alternative to the ICM42688 family IMU.

src/main/target/ORBITF435/target.h

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 📜 Skill insights (0)

1. Slow gyro autodetect boot 🐞 Bug ➹ Performance

Description

On ORBITF435 builds with both ICM42605 and LSM6DXX enabled, gyro init always starts from
GYRO_AUTODETECT and will attempt ICM42605 detection first; on LSM6DXX hardware this adds ~0.9s of
delay before it can fall through to LSM6DXX detection. This slows boot and can make startup timing
less reliable on the new LSM6DSK320X-equipped boards.

Code

src/main/target/ORBITF435/target.h[R98-101]

+#define USE_IMU_LSM6DXX
+#define IMU_LSM6DXX_ALIGN       CW270_DEG
+#define LSM6DXX_SPI_BUS         BUS_SPI1
+#define LSM6DXX_CS_PIN          PA4

Evidence

The PR enables LSM6DXX on ORBITF435 while keeping ICM42605 enabled on the same SPI/CS footprint.
Gyro initialization always runs full autodetect and probes ICM before LSM6DXX, and the ICM detect
routine has multiple 150ms delay retries, which will be paid on LSM6DXX-equipped boards before
falling through to the LSM6DXX driver.

src/main/target/ORBITF435/target.h[84-102]
src/main/sensors/gyro.c[151-234]
src/main/sensors/gyro.c[321-346]
src/main/drivers/accgyro/accgyro_icm42605.c[288-318]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
On ORBITF435, this PR enables `USE_IMU_LSM6DXX` while keeping `USE_IMU_ICM42605` enabled. Gyro init always runs `GYRO_AUTODETECT` and probes ICM first; when the physical IMU is LSM6DSK320X, the ICM driver’s detect routine performs multiple delayed retries before failing, adding a noticeable boot delay.

## Issue Context
- `gyroInit()` always calls `gyroDetect(..., GYRO_AUTODETECT)` (not target-configurable today), so every enabled gyro driver in the detection chain may be probed.
- The ICM42605 detect path includes repeated `delay(150)` retries.

## Fix Focus Areas
Pick one approach (preferably aligned with how ORBITF435 hardware is actually shipping):

1) **If ORBITF435 is now LSM6DSK320X-only**
- Remove ICM42605/42688 enablement and its busdev registration from the ORBITF435 target so autodetect doesn’t spend time probing an IMU that will never be present.

2) **If ORBITF435 must support both IMUs in one firmware**
- Consider introducing a target-specific way to bias detection order / reduce worst-case probe latency when multiple IMUs share a footprint (e.g., a faster “non-matching device” exit path in the ICM detect routine, without breaking cold-start ICM detection).

### Code references
- src/main/target/ORBITF435/target.h[84-102]
- src/main/sensors/gyro.c[151-234]
- src/main/sensors/gyro.c[321-346]
- src/main/drivers/accgyro/accgyro_icm42605.c[288-318]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Tip of the day

💡 Did you know, you can switch off images and animations for a plain-text comment

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[qodo-free-for-open-source-projects]

1. Slow gyro autodetect boot 🐞 Bug ➹ Performance

On ORBITF435 builds with both ICM42605 and LSM6DXX enabled, gyro init always starts from
GYRO_AUTODETECT and will attempt ICM42605 detection first; on LSM6DXX hardware this adds ~0.9s of
delay before it can fall through to LSM6DXX detection. This slows boot and can make startup timing
less reliable on the new LSM6DSK320X-equipped boards.

Agent Prompt

## Issue description
On ORBITF435, this PR enables `USE_IMU_LSM6DXX` while keeping `USE_IMU_ICM42605` enabled. Gyro init always runs `GYRO_AUTODETECT` and probes ICM first; when the physical IMU is LSM6DSK320X, the ICM driver’s detect routine performs multiple delayed retries before failing, adding a noticeable boot delay.

## Issue Context
- `gyroInit()` always calls `gyroDetect(..., GYRO_AUTODETECT)` (not target-configurable today), so every enabled gyro driver in the detection chain may be probed.
- The ICM42605 detect path includes repeated `delay(150)` retries.

## Fix Focus Areas
Pick one approach (preferably aligned with how ORBITF435 hardware is actually shipping):

1) **If ORBITF435 is now LSM6DSK320X-only**
- Remove ICM42605/42688 enablement and its busdev registration from the ORBITF435 target so autodetect doesn’t spend time probing an IMU that will never be present.

2) **If ORBITF435 must support both IMUs in one firmware**
- Consider introducing a target-specific way to bias detection order / reduce worst-case probe latency when multiple IMUs share a footprint (e.g., a faster “non-matching device” exit path in the ICM detect routine, without breaking cold-start ICM detection).

### Code references
- src/main/target/ORBITF435/target.h[84-102]
- src/main/sensors/gyro.c[151-234]
- src/main/sensors/gyro.c[321-346]
- src/main/drivers/accgyro/accgyro_icm42605.c[288-318]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

[github-actions]

Test firmware build ready — commit 5976bf6

Download firmware for PR #11818

2 targets built. Find your board's .hex file by name on that page (e.g. MATEKF405SE.hex). Files are individually downloadable — no GitHub login required.

Development build for testing only. Use Full Chip Erase when flashing.

[github-actions]

RAM / Flash usage vs. base branch — commit 5976bf6

None of the representative targets (MATEKF405, MATEKF722, MATEKF765, MATEKH743) were built by this PR — no size comparison to show.

See RAM/flash optimization guide for techniques to reduce usage.