docs: document NEXUSX ports, outputs and I2C buses

[Raffi1202]

Problem

Fixes #11326. Painless360 was setting up a NEXUS-X, had found the output timer maps, but could not find how the case ports "A", "B" and "C" relate to iNav's UARTs, or which port carries the serial receiver by default (he guessed UART5). MrD-RC asked for a page under docs/boards because the case labels only make sense for helicopters. The page docs/boards/NEXUSX.md (moved from the target README in a8b92b2) lists the pins per case label but says nothing about default port functions, the receiver provider, timer grouping or the I2C2/UART3 exclusion.

Cause

docs/boards/NEXUSX.md:17-40 on maintenance-10.x contains only the pin tables. The answers sit in the target: src/main/target/NEXUSX/target.h:94-118 (UART pins, DEFAULT_RX_TYPE, SERIALRX_CRSF, SERIALRX_UART = USART5), config.c:41 (TIM1 forced to motors), src/main/fc/fc_init.c:443-446 (I2C2 only started when UART3 has no function) and src/main/io/serial.c:123-151 (MSP on VCP and UART1 after reset).

Change

Extends docs/boards/NEXUSX.md (+119, -0). Adds a board identity table, a sensor/bus/pin table, a serial port table with case labels ("A" = UART4, "B" = UART6, "C" = UART3, internal ELRS = UART5), the port functions after a reset, the timer groups behind the nine outputs with the "ESC" pad forced to motor mode, and the three I2C buses with the UART3/I2C2 exclusion. A closing section lists what the target source does not establish (connector pin order, EXT-V limit, and whether UART1 releases the AUX/SBUS pads: src/main/drivers/pwm_mapping.c:90-141 checks UART2 to UART8 only).

Test

Not run on hardware. Every statement was checked against the files named under Cause on maintenance-10.x, plus src/main/rx/sbus.c:259 for the SBUS inversion default. No CI run: the build workflow does not trigger for this path (ci.yml pull_request.paths); zero check runs on 08dbedd.

Flash / RAM

Not measured yet. The upstream firmware CI has not been released for this PR, so no size report exists.

Docs

docs/boards/NEXUSX.md is the changed file; src/main/target/NEXUSX/README.md already points to it.

[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]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)

Great, no issues found!

Qodo reviewed your code and found no material issues that require review

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]

PR Summary by Qodo

Document NEXUSX ports, outputs, and I2C buses

📝 Documentation 🕐 10-20 Minutes

AI Description

• Maps NEXUS X/XR case labels to iNav serial ports and reset defaults.
• Documents onboard peripherals, output timer groups, and shared UART/I2C behavior.
• Flags hardware details that firmware sources cannot confirm.

Diagram

graph TD
  T["Target Source"] --> D["NEXUSX Guide"] --> U["Board Users"]
  D --> S["Serial Ports"] & O["Output Timers"] & I["I2C Buses"] & C["Source Caveats"]

Loading

High-Level Assessment

Expanding the existing board-specific page is the appropriate approach because it keeps setup guidance discoverable beside the NEXUSX hardware documentation. Deriving claims from target definitions and isolating unverified hardware details avoids unsupported assumptions; separate generic guides or duplicated source comments would be less useful to board owners.

Files changed (1) +119 / -0

Documentation (1) +119 / -0

NEXUSX.mdExpand NEXUSX hardware and configuration reference +119/-0

Expand NEXUSX hardware and configuration reference

• Documents board identity, onboard peripherals, case-label-to-UART mappings, reset-time receiver defaults, output timer groups, and I2C bus conflicts. It also identifies hardware details that cannot be confirmed from firmware sources and require external verification.

docs/boards/NEXUSX.md