MSP Bind Message, CLI Command

[jlpoltrack]

User description

Two changes:

• Add new MSP message for bind
• Add new CLI command to send bind message to receiver

New message and command chosen as MSP receivers don't use serial_rx used by the existing rx_bind / MSP2_BETAFLIGHT_BIND stuff.

Tested with: olliw42/mLRS#395

---

PR Type

Enhancement, New Feature

---

Description

• Add MSP2_RX_BIND message for MSP receiver binding support

• Implement CLI command to send bind message to MSP receivers

• Update documentation with new bind command and MSP message details

---

Diagram Walkthrough

flowchart LR
  CLI["CLI bind_msp_rx command"]
  PORT["Serial port lookup"]
  MSP["MSP port validation"]
  SEND["Send MSP2_RX_BIND message"]
  RX["MSP receiver binding"]
  
  CLI -- "port index" --> PORT
  PORT -- "port usage" --> MSP
  MSP -- "msp port" --> SEND
  SEND -- "bind request" --> RX

Loading

File Walkthrough

	Relevant files
Enhancement	cli.c Add CLI command for MSP receiver binding                                  src/main/fc/cli.c Add includes for MSP serial and protocol headers Implement cliBindMspRx() function to handle MSP receiver binding via CLI Register new bind_msp_rx CLI command with port parameter validation Validate serial port existence and MSP configuration before sending bind message +38/-0    msp_protocol_v2_common.h Define MSP2_RX_BIND protocol constant                                        src/main/msp/msp_protocol_v2_common.h Define new MSP2_RX_BIND message constant with code 0x3001 +1/-0
Documentation	Cli.md Document new bind_msp_rx CLI command                                          docs/Cli.md Add bind_msp_rx command to CLI command reference table +1/-0      Rx.md Document MSP receiver binding command usage                            docs/Rx.md Rename section from "CLI Bind Command" to "CLI Bind Commands" Add documentation for bind_msp_rx command with port parameter syntax Explain MSP receiver binding functionality +7/-1      msp_messages.json Add MSP2_RX_BIND to message documentation                                docs/development/msp/msp_messages.json Add MSP2_RX_BIND message definition with code 12289 Include notes about MSP receiver protocol requirement Provide description of binding functionality for mLRS receivers +8/-0      msp_ref.md Add MSP2_RX_BIND reference documentation                                  docs/development/msp/msp_ref.md Add MSP2_RX_BIND to message reference table of contents Create detailed documentation section for MSP2_RX_BIND message Include description, payload details, and protocol notes +11/-1

---

[qodo-code-review]

PR Compliance Guide 🔍

All compliance sections have been disabled in the configurations.

[qodo-code-review]

Suggestion: Replace fastA2I with strtol to ensure the entire port argument is a valid number, preventing partial parsing of non-numeric input. [possible issue, importance: 6]

Suggested change

	int portIndex = fastA2I(cmdline);
	if (portIndex < 0 || portIndex > 7) {
	cliShowArgumentRangeError("port", 0, 7);
	return;
	}
	char *endptr;
	long portIndex = strtol(cmdline, &endptr, 10);
	if (endptr == cmdline || *endptr != '\0') {
	cliShowParseError();
	return;
	}
	if (portIndex < 0 || portIndex > 7) {
	cliShowArgumentRangeError("port", 0, 7);
	return;
	}

[b14ckyy]

Tagging for a possible 9.1 since it just adds a feature without altering existing config or functionality.

[olliw42]

@sensei-hacker @b14ckyy

since we have here a typical hen-egg situation, I would be eager to merge to mLRS what it needs, so that it is ready for when INAV does it. We are preparing for a next release; otherwise it would dongle around in mLRS dev versions for a good while.

To do so, all we would have to know is what the message would be going to look like.

The message as designed here is ok and will eventually become part of the standard?
Changes suggested? E.g., should it get a u32 payload to be more future proof? ??
Not possible to say now?

[b14ckyy]

do you have any future upgrades in mind that just don't make sense right now? Considering its "just" a bind trigger?

[sensei-hacker]

@xznhj8129 you're deep into MSP.

Any thoughts?

[olliw42]

do you have any future upgrades in mind that just don't make sense right now? Considering its "just" a bind trigger?

not being MSP savy I would not know :)
Maybe something like a port number, if that can be figured out, or a flag to distinguish between an extrenal receiver and an on-board receiver if the FC has any (which I would assume the FC code knows about), stuff of that kind, and all the stuff which doesn't come yet to mind. LOL

[b14ckyy]

That's fair. @sensei-hacker since this is a message that won't be used by anything else then by the FC to sending a command to a MSP Receiver, I think it would not hurt to have a payload option, even if its empty now?

[sensei-hacker]

That's fair. @sensei-hacker since this is a message that won't be used by anything else then by the FC to sending a command to a MSP Receiver, I think it would not hurt to have a payload option, even if its empty now?

Sounds reasonable to me. But I'm not deep into MSP like @stronnag and @xznhj8129 are, so I may be missing something.

[olliw42]

since this is a message that won't be used by anything else then by the FC to sending a command to a MSP Receiver

ah, not intended to also be potentially send e.g. by a GCS?

[b14ckyy]

@olliw42 the CSG (or in this case potentially just INAV configurator) only commands the FC to send the MSP message to the Rx. Like that CLI command bind_msp_rx 1. I don't know how that works from GUI though. But over CLI, the ground station does not to implement anything dedicated.

[olliw42]

thx for the clarification
this is the current state, which may not be the final state
just wonder if it couldn't/shouldn't be seen more general. Would there be reason it would not come from different sources too? I mean, in terms of MSP protocol hygiene.

[xznhj8129]

I haven't seen anything about binding, not that i looked, but if there's already a function to send a bind message, it only takes a handle case in fc_msp

[stronnag]

since this is a message that won't be used by anything else then by the FC to sending a command to a MSP Receiver

ah, not intended to also be potentially send e.g. by a GCS?

A GCS has no interest in this. It is effectively a private capability between a mLRS management tool, the FC and the radio. All it needs is that the MSP function ID is publicly documented to avoid reuse. The payload is only relevant to the MLRS capability, if / how / when mLRS decides it needs to implement a payload need not concern other MSP users. It might as well be documented as "opaque".