Repository navigation
maintenance-10.x into next-10.1 - #12207
sensei-hacker wants to merge 44 commits into
Conversation
SBUS servo output is resolved with findSerialPortConfig(), which returns the first port that carries FUNCTION_SERVO_SERIAL. Assigning the function to a second port was accepted and reported back by the serial command, but that port was never opened. Reject such an assignment in the CLI instead of ignoring it silently. Fixes #11430
The receiver transmit power is only written by the MSP and MAVLink RC paths. The CRSF link statistics frame 0x14 has no such field and no other CRSF frame is parsed for it, so with an ExpressLRS receiver the element showed a permanent 0 mW. ExpressLRS never sends the optional link statistics RX frame 0x1C that would carry a power value, so parsing it would not populate the element either. A power of 0 already means "not reported" on the other paths, so skip drawing the element in that case. Fixes #11136
The mixer switch carry over loop ended at the first INPUT_MIXER_SWITCH_HELPER rule. Switching a mixer profile back before the carry over of the previous switch had decayed therefore dropped its remaining filter state, the newly loaded rule restarted from zero and the servo jumped towards its mid position. Only the carry capacity ends the loop now, helper rules are carried over like any other speed limited rule. Fixes #11503
The constraints list already covers the analogous telemetry rule. Adds the SERVO_SERIAL case, including that the second assignment used to be accepted silently without the port ever being opened.
The safehome zone appended in geoZoneInit() was counted in activeGeoZonesCount but never had enable set, unlike the configured zones. The following sort by enable could therefore move it behind the counted range and pull a zeroed slot (NULL vertices) in front of it, or keep a deliberately deactivated far inclusive zone active instead. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
atan2() promoted both integer arguments to double. F4/F7 have no double-precision FPU, so this single call pulled the libgcc soft-double arithmetic and compare routines plus the double atan/atan2 from libm into every image. The result is truncated to integer degrees, so float precision is more than enough. MATEKF722 -2792 B, MATEKF405 -1460 B, MATEKF765 -1392 B, MATEKH743 -1392 B, NEUTRONRCF435WING -1456 B flash; RAM unchanged. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
A %f vararg promotes to double, which keeps libgcc's soft-double add/sub
and int-to-double routines linked on MCUs without a double FPU. The four
sites (GPS HDOP/EPH/EPV in "status", DLVR pitot debug log) only display
already scaled integers.
MATEKF722 -876 B, MATEKF765/H743/NEUTRONRCF435WING -44 B, MATEKF405 +20 B
flash; RAM unchanged. The CLI status lines now print two decimals
("1.50") instead of ftoa's " 1.500".
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
newlib implements strstr and strnstr with the two-way algorithm and memmem, about 2.8 KB of code. INAV only searches short CLI tokens, setting names and u-blox version strings, so a plain scan is enough. cliSet's strstr(cmdline, "=") becomes strchr. SITL's private strnstr had no caller left and is removed. MATEKF722 -3008 B, MATEKF405 -3232 B, MATEKF765 -2672 B, MATEKH743 -2680 B, NEUTRONRCF435WING -2816 B flash. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
These were the last callers of libm sinf/cosf/atan2f on targets without USE_TERRAIN. sinf/cosf link the large-argument range reduction (rem_pio2 plus its 792 B table) although the arguments here never exceed 2 pi. sin_approx/cos_approx are within 4e-7 of libm over that range and are the codebase standard; the results feed a smoothed wind estimate and an integer-degree telemetry value. The tracker elevation is now rounded instead of truncated, so the approximation's 3e-7 rad error at exact integer angles (45 deg) cannot shift the reported value by a degree. MATEKF722 -4808 B, MATEKF405 -4616 B, NEUTRONRCF435WING -4616 B, MATEKF765/H743 -760 B flash; RAM unchanged. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Both callers sort tiny arrays at init time: the three battery profiles by detect voltage, and the geozone runtime list into "enabled first". An insertion sort and a stable partition do the same and newlib's qsort (1.6 KB) leaves the image. Enabled geozones now keep their configured order instead of qsort's permutation; the battery order is unchanged (newlib already insertion-sorts fewer than seven elements). MATEKF722 -1472 B, MATEKF405 -1408 B, MATEKF765 -1288 B, MATEKH743 -1344 B, NEUTRONRCF435WING -1408 B flash. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Three byte-sized members sat between word-sized ones, costing 4 B of padding per state in the const navFSM table. The table uses designated initialisers, so the order change has no other effect. MATEKF722 -196 B, the other reference targets -260 B flash. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Like the other OSD elements that hide themselves at runtime, the element now takes its slot in the per-cycle draw budget after blanking its field. No visible change. The receiver transmit power is carried by CRSF frame 0x1D, not 0x1C. INAV parses neither and ExpressLRS sends neither, so the docs no longer claim that CRSF cannot carry the value, and name mLRS only as MAVLink receiver.
NAV-SIG (M9, M10) and NAV-SAT (M8) were requested at every navigation epoch. They feed only the satellite list in the CLI, yet they are most of what the receiver sends: NAV-SIG carries 16 bytes for each tracked signal, several hundred bytes per epoch on a multi-constellation receiver, against about 100 for the NAV-PVT that navigation runs on. They are now requested every (gps_ublox_nav_hz + 1) / 2 epochs, which is about twice a second at any navigation rate.
A receive buffer has to hold what arrives between two runs of the task that drains it. For the GPS task, 20 ms apart, that is up to 230 bytes at 115200 and 460 at 230400, and a reply to a poll has to fit whole: MON-VER alone can be 258 bytes. With the 256 bytes every port has, a NEO-F10N at 230400 was never identified, because its MON-VER reply was always cut. The GPS port now gets a 512 byte buffer of its own, in FASTRAM, where there is room: CCM on F405, RAM1 on AT32F43x. serialSetRxBuffer() swaps it in right after the port is opened. Every other port keeps its 256 bytes. The note that occupied sizes are returned as uint8_t no longer held: the driver functions and the ring indices are all 32 bit.
The satellite details also feed the OSD's GPS extra stats, not only gpssats, so the comment now says both. The comments are one line each, the buffer states the rate it covers (230400; at 460800 and above a NAV-PVT plus a large NAV-SIG can still overflow it), its size is asserted to be a power of two because softserial masks with size - 1, and it only exists where the u-blox provider does, the only one that opens a port. The note in serial_uart.h about sending a UBLOX SVINFO was stale.
Rename serialDuplicatedSinglePortFunctions() to serialGetDuplicatedSinglePortFunctions() so the helper has a verb name like the other serialGet*/serialFind* functions (Development.md #5). Cut the three-line comment above SERIAL_SINGLE_PORT_FUNCTIONS to one line that states why the list exists. docs/Serial.md: drop the "previously it was accepted" history from the constraint and say what happens to a saved configuration that already has SBUS output on several ports: only the first port in the serial list is used, the configuration is not reset. No functional change.
Only MSP receivers that send MSP2_COMMON_SET_MSP_RC_INFO report the receiver transmit power, and mLRS reports 0 dBm or less as 0 mW, so the element is also hidden for mLRS at 1 mW and below. Say so in the OSD element table.
Development.md asks for comments that explain why, not what. No functional change.
With parity enabled the F4 data register holds the parity bit in bit 8, and it was passed through to the rx callback. F7/H7 drivers already mask to 8 bits. Protocol handlers comparing the received value directly, e.g. the SBUS 0x2F start byte, never matched on F4.
… a function besides MSP checkPwmTimerConflicts() kept outputs off the pins of UART2 to UART8 but not UART1. On NEXUSX and VANTAC_RF007 the pads labelled AUX and SBUS are both UART1 and two timer outputs, and SPRACINGF7DUAL has the same on PWM 3 and 4: with a receiver on UART1, a motor or servo could be assigned to the receiver's pin and drive nothing once the receiver took it back. UART1 gets MSP by default next to the VCP, and MSP opens before the outputs and has always given them these pins, so MSP alone still does; any other function on UART1 now keeps them, as on UART2 to UART8.
A reboot without a power cycle (CLI save or exit, a Configurator reboot, a DFU flash) left the IST8310 as it was. In the continuous mode the driver set, a value the datasheet lists as reserved, it then never raised DRDY again: the compass kept its last reading, or zeros right after boot, with MAG=OK in status until the next power cycle. Following the datasheet and PX4: soft reset at init (50 ms power-on reset), then single measurement mode, each read starting the next measurement and restarting one that never completed. STAT1 and the data registers come in one transfer, which cannot tear since the data only changes after a trigger.
Beyond 1600 uT on X and Y, or 2500 uT on Z, a sample is not a field: it can only be a corrupted transfer or a chip in a bad state, and one such sample is enough to throw off the sphere fit of a compass calibration. The previous sample is kept, as when no measurement is ready. ArduPilot's IST8310 driver makes the same check.
… holds it The fixed-wing I-term lock damps P and D and freezes the I-term while the stick asks for a big rate, so the feed-forward flies the manoeuvre. An I-term built in a motion the pilot did not ask for is then held against the stick and eats that feed-forward: a trainer pulling out of a spiral dive at 34 m/s got +30 us of elevator from a demand of 111 deg/s, the I-term at +87 against a feed-forward of -115, and hit the ground level, a second short. Now an I-term of the opposite sign to the rate target fades with a 0.5 s time constant, scaled by how far the lock attenuates the I-term; one of the same sign, the trim the lock is meant to keep, is left alone. Same in the auto-transition controller. Unit test on the trainer's pitch loop.
…d not on yaw A small correction of the opposite sign to the trim would have erased it in a few seconds, and the rudder trim would have faded in a banked turn, where the yaw rate target is the turn's. The fade now applies on roll and pitch, and only when the rate target is above 20 % of the maximum rate, the threshold the lock itself uses to count a stick input as big. Two unit tests.
Refuse assigning SBUS output to a second serial port
Keep the servo speed carry over when switching mixer profiles back
fw pid: an I-term that opposes a big stick input fades while the lock holds it
Flash: remove double math, newlib strstr/qsort and libm trig from the F7 images (-13 KB on F722)
|
ⓘ Qodo reviews are paused because the subscription is no longer active. Ask your workspace admin to reactivate the subscription to resume reviews. Manage billing |
PR Summary by QodoFix flight-control edge cases and reduce firmware footprint
AI Description
Diagram
High-Level Assessment
Files changed (21)
|
Code Review by Qodo
1. Legacy backups lose serial settings
|
|
RAM / Flash usage vs. base commit
See RAM/flash optimization guide for techniques to reduce usage. |
|
Test firmware build ready — commit Download firmware for PR #12207 251 targets built. Find your board's
|
pwm_mapping: skip timer outputs on UART1's pins when UART1 has a function besides MSP
Pitot filter cut off fix
IST8310: fix the compass freezing after a reboot, drop impossible samples
Fix typo in flash chip management section
Fix incorrect arm result in fcSetArmState
gps: satellite details twice a second, and a 512 byte receive buffer for the GPS port
Hide the RX downlink power element when the link does not report it
F4 UART: mask received data to 8 bits, align with F7/H7
No description provided.