Repository navigation
Conversation
A few helicopter flight controllers have a connector labelled ESC whose pin can also be UART1's TX: the NEXUS X/XR and Vantac RF007 (PA9) and the NEXUS (PB6). Such a target now declares ESC_CONNECTOR_UART and ESC_CONNECTOR_PIN, and a new setting, esc_srxl2_connector (off by default, only on those targets), puts a Smart ESC there: with the ESC protocol set to SRXL2 and the connector's UART free, the driver moves that UART's TX to the connector (uartSetTxPin(), on F7 and H7) and opens it as motor 1. UARTs assigned the Smart ESC function in Ports follow as motors 2 and on. The pad behind the connector keeps its motor slot, which SRXL2 never drives, so on these targets, which set the connector's timer to motors, the servos map as with the setting off. The pad gets no servo, and after the mapping it keeps no LED, beeper or PINIO flag either: none of those takes the pin from the UART, and the Outputs tab maps what the board does. The setting lives in a new parameter group. The three targets gain the driver (USE_MOTOR_SRXL2) and with it the SRXL2 fields of motorConfig_t; the padding byte in front of them lets a configuration saved without them load with their defaults, so that group keeps its version. The FlyDragon Pro gains the driver only: its connector labelled ESC is UART4's TX already. MSP2_INAV_ESC_SRXL2_STATUS now ends with the board's connectors, by the UART behind each, for the Configurator.
|
ⓘ 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 QodoEnable SRXL2 Smart ESCs on supported ESC connectors
AI Description
Diagram
High-Level Assessment
Files changed (19)
|
Code Review by Qodo
1.
|
![qodo-free-for-open-source-projects[bot]](https://avatars.githubusercontent.com/in/1068000?s=60&v=4){kind=small}
|
RAM / Flash usage vs. base branch — commit
See RAM/flash optimization guide for techniques to reduce usage. |
|
Test firmware build ready — commit Download firmware for PR #12087 251 targets built. Find your board's
|
|
I tested this fix on avian 100A on nexus XR, I confirm it works after setting esc port to srxl2 mode |
|
@UltraFly thanks, the first test on one of the three boards, and with an Avian other than my 70A. |
The driver opens at most four ports, and the connector takes the first, so with four UARTs also assigned the last one was dropped without a word: its ESC was never fed while the other four answered, and arming went ahead. A port left over now keeps the link reported as missing, which blocks arming with the OSD's hardware warning.
|
I could see how this could be a little useful - though the board already has a pin for UART1. Only on this one specific group of boards, To: Would it be 5939% more useful too 800X more people if the restrictions were deleted? |
|
Also just an FYI so you can prioritize your time since I know you've worked on a lot of things: This board family is by far the most limited, least-capable target that can partially support INAV. I guess certain people are attracted to it BECAUSE it only has a couple spots to plug things in, while all other flight controllers have two or three times as many places users can plug things in. A couple of users made a few requests to do hacky things in INAV to try to get around the extreme limitations of this particular board, to "undo" the choice of buying a board with only plugs available, A and B. A better solution would probably be for them to use literally any other any other board, any of the 209+ boards that can run INAV. There are no other boards in existence with the same limitations, and these won't be able to even partially support INAV 11 a year from now. |
|
Code review by qodo was updated up to the latest commit ee138ec |
|
There is a cool feature in here. I am hesitant to burn flash and RAM on on lines of code like: I'm thinking it may be more useful to essentially delete lines 1-4? If putting a UART on a PWM pad is useful, can we just do that? Without restricting it to only the three people who want to use one specific uart on one specific board for one specific purpose? |
3 participants
A few flight controllers made for helicopters have a connector labelled ESC whose signal pin can also be UART1's TX. @UltraFly asked in #11184 for a Smart ESC on the NEXUS-XR's one, which is PA9, USART1 TX on the F722. This adds an option for it on the three such boards INAV has. It is off by default, so nothing changes until someone turns it on.
The FlyDragon Pro's ESC connector is UART4's TX already, so that target only gains the driver: a Smart ESC there works with UART4 assigned to it in Ports.
How it behaves
esc_srxl2_connector, OFF by default, only on these three targets.SRXL2and UART1 free in Ports: the driver moves UART1's TX to the connector, half duplex, and the ESC there is motor 1. UARTs assigned the Smart ESC function in Ports follow as motors 2 and on, in UART order, as before.ESC_CONNECTOR_UART, which only these three define. Their binaries grow only by the connector count in the status reply below.I made it a setting rather than automatic because the firmware cannot tell a Smart ESC on the connector from one on a UART pad. With a Smart ESC on UART3 and UART1 free, an automatic choice would make the empty connector motor 1 and the ESC on UART3 motor 2.
The change
target.hof the three boards:ESC_CONNECTOR_UART,ESC_CONNECTOR_PINandUSE_MOTOR_SRXL2, which F7 does not build by default. FLYDRAGONPRO:USE_MOTOR_SRXL2only.uartSetTxPin()in the F7 UART driver, for these boards, and in the H7 one, where I tested it. It applies at the next open, and the new pin must use the alternate function of the UART's own TX: AF7 for USART1 on PA9 and PB6 alike.motor_srxl2.c: the setting (new PGescConnectorConfig, id 1048), andsrxl2MotorUsesEscConnector(), which decides from the configuration alone, so the output mapping, which runs before the driver opens its port, agrees with it.pwm_mapping.c: while the connector carries the ESC, its pad gets no servo, and after the mapping it loses its servo, LED, beeper and PINIO flags. The motor slot stays because SRXL2 never drives it; skipping the pad would move the slot onto S1's timer and take S1-S3 from the servos.MSP2_INAV_ESC_SRXL2_STATUSappends the board's connectors (a count, then the serial port identifier behind each), so the Configurator can offer the option only where it exists.msp_messages.jsonand the MSP README are updated. Both sides read the message by its length, so the 10.0 RC Configurator ignores the new bytes.motorConfig_t: on these four targets it gains the SRXL2 fields that F4, H7 and AT32 already have. The padding byte in front of them (seeflight/mixer.h) lets a configuration saved without them load with their defaults, so the group keeps its version and nobody loses motor settings.motor_srxl2.h: an#errorif a target defines a connector withoutUSE_MOTOR_SRXL2, or on a platform other than F7 and H7. A static assert keeps a connector off PA11/PA12. On F7 INAV's USB runs on OTG_FS with VBUS sensing off, so PA9 is not used by the USB (usbd_conf_stm32f7xx.c).pwm_mapping_esc_connector_unittest.cc.pwm_mapping.cis not built for the host, so like the otherpwm_mappingtests it reproduces the override pass and the assignment loop, and a SourceSync case checks that the live source still has both hooks.docs/Settings.mdregenerated, a section "Boards with an ESC connector" indocs/Spektrum Smart ESC.md, and a line indocs/boards/NEXUSX.md.The Configurator side is iNavFlight/inav-configurator#2814: the option in the Outputs tab, shown only when the board reports a connector, and the UART shown as "SRXL2 via ESC connector" in Ports.
Related
motor_srxl2.cand the same doc. This one is independent of both and merges with them without conflicts; I also built and tested it together with the power-up change.motor_srxl2.cand.h. It conflicts with this one on a single line at the top ofmotor_srxl2.h, where both add a line after the includes. If Spektrum Smart Battery telemetry #12077 goes in first, I'll rebase this one.serial_uart_stm32h7xx.cwhere this one addsuartSetTxPin(), right afteruartGetPortPins(). Whichever goes in second keeps both blocks; both are mine, so I'll fix the one left.PG_CHIRP_CONFIG) and by MZTC thermal camera integration — merge conflicts resolved against maintenance-10.x (supersedes PR #11005) #11837 (PG_MZTC_CAMERA_CONFIG), so whichever of them goes in second has to move to the next free id. If that is this one, I'll move it.serial_uart_stm32h7xx.c), GPS: report what the receiver actually has, and allow NavIC where it exists #11979, Add names for control, battery and mixer profiles #11894, OSD elements for the control, battery and mixer profile names #11896 and Detect the DPS310 on both of its I2C addresses #11906 (the version inmsp_messages.json), docs: correct the NEXUSX UART1 note and hardware layout #11925 (docs/boards/NEXUSX.md). I'll update this one for whichever goes in first.Cost
Against the base, 3931fcd:
On the four boards nearly all of it is the SRXL2 driver, which F7 targets do not build by default. It is in the binary whether the setting is on or not: FLYDRAGONPRO ends at 98.39%, below MATEKF722SE's 98.43%. With #12084 (ready delay) and #12085 (power-up) in as well, the four boards grow by another 298 to 584 B, and FLYDRAGONPRO ends at 98.49% (484091 B).
Tested
pwm_mappingones pass. The new one fails as it should with the final mask taken out of the reproduction (5 cases) or out ofpwm_mapping.c(SourceSync).uartSetTxPin(), since SITL has no UART driver): the option on and off, the port count in the status reply (1 with the connector in use, 0 while its UART has MSP), and the Configurator tabs in each state.resourceshows PC6 taken by UART6 in half duplex; the ESC links and its telemetry arrives as motor 1; motor 1's command reaches it (1300, 1600 and 1000 us), with a real Avian on UART8 as motor 2. With motor_srxl2: link an ESC powered together with the board #12085 (power-up) in the same image, the ESC powered 0 to 150 ms after the board's reset linked 8 times out of 8; powered after the board was up, absent at boot and connected later, and across a board reboot, it linked every time.Not tested, testing wanted
None of the three boards. The mechanism ran on an H7 standing in for one; the three are F722, whose UART driver takes the same four-line setter. An owner of any of them with a Smart ESC could confirm the link on the connector, and that with the option off a normal ESC on the connector still works.