Conversation
clean_<target> ran the generator clean in the build directory, so it wiped every target instead of the one that was named. Remove the artefacts of that target instead: its binary, map file, object files, generated settings and the hex/bin files built from it. Neither "make clean" nor "ninja clean" can be limited to a single target, so the paths are removed by a small cmake script. That keeps the behaviour identical for the Makefile and the Ninja generator. The object directory itself is kept, because the Makefile generator stores the build rules of the target (build.make, DependInfo.cmake, ...) next to the object files and without them the next build fails until cmake is run again. at32, rp2350 and sitl carried the same code and now share add_clean_target() with stm32. Fixes iNavFlight#6135
getMotorAveragePeriod() was guarded by USE_ESC_SENSOR_TELEMETRY and USE_DSHOT_TELEMETRY. Neither of them exists in INAV, so only the #else branch was ever compiled. The guarded code also calls getEscSensorData(), a Betaflight API; INAV has escSensorGetData() and getEscTelemetry(). The function stays, srxlFrameRpm() still calls it and reports the RPM field as unused. Only the branches go, together with the defines and the esc_sensor.h include that nothing else used. Fixes iNavFlight#11298
|
ⓘ 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 QodoScope clean targets and remove dead Spektrum RPM telemetry code
AI Description
Diagram
High-Level Assessment
Files changed (7)
|
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 reviewTip of the day💡 Did you know, you can switch off images and animations for a plain-text comment |
Problem
#6135 (stronnag): after
make MATEKF405 WINGFC MATEKF722, runningmake clean_MATEKF405removed the hex files of all three targets, and the followingmake MATEKF722was a full rebuild instead of a no-op. #11298 (error414):getMotorAveragePeriod()insrc/main/telemetry/srxl.ccarries RPM code underUSE_ESC_SENSOR_TELEMETRY/USE_DSHOT_TELEMETRYthat callsgetEscSensorData(ESC_SENSOR_COMBINED); none of these exist in INAV, the block was copied from Betaflight. Fixes #6135, fixes #11298.Cause
cmake/stm32.cmake:444-446on maintenance-10.x definesclean_<name>asCOMMAND ${generator_cmd} cleanwithWORKING_DIRECTORY ${CMAKE_BINARY_DIR}, i.e. the generator's global clean;<name>is never used. The same block sits incmake/at32.cmake:434-436,cmake/rp2350.cmake:430-432andcmake/sitl.cmake:175-177.src/main/telemetry/srxl.c:187-221: the two guards are defined nowhere in the tree, so only the#elsebranch (line 220,return SPEKTRUM_RPM_UNUSED;) was ever compiled.getEscSensorData()at line 192 does not exist; INAV hasescSensorGetData()/getEscTelemetry()(src/main/sensors/esc_sensor.h:48-49).Change
Adds
add_clean_target()tocmake/main.cmakeand the scriptcmake/clean_target.cmake, run withcmake -Pso it is generator-independent. stm32, at32, rp2350 and sitl call it with their executables and output files (hex/bin/uf2/exe, plus bootloader and combined hex where built); the helper adds each executable's binary, map file, the target's generated settings files and the*.o/*.obj/*.dfiles underCMakeFiles/<exe>.dir, keeping the directory so the Makefile generator'sbuild.makesurvives.stm32.cmakenow also capturesmain_bin_filename.srxl.cdrops the two dead branches,MICROSEC_PER_MINUTE,SPEKTRUM_MIN_RPM,SPEKTRUM_MAX_RPMand thesensors/esc_sensor.hinclude;getMotorAveragePeriod()still returnsSPEKTRUM_RPM_UNUSEDtosrxlFrameRpm().Test
Not run on hardware or in a local build. Cause verified by reading the lines above on maintenance-10.x; The upstream "Build firmware" run for 119a245 is awaiting approval: https://github.com/iNavFlight/inav/actions/runs/34513105859. CI configures with
-G Ninjaonly and never invokes aclean_<target>, so a green build confirms configure and compile, not the clean itself.Flash / RAM
Not measured yet. The upstream firmware CI has not been released for this PR, so no size report exists.
Docs
No documentation change needed:
docs/development/Building in Linux.md:148-157already describesmake clean_MATEKF405as cleaning a single target; this change makes that description true.