Code: Select all
#define CAP_CHANNEL_FORWARDING ((uint32_t)1 << 4)
that is deprecated, i will delete that now.
Code: Select all
#define CAP_CLEANFLIGHT_CONFIG ((uint32_t)1 << 29)
to detect cleanflight and cleanflight msp commands
stronnag wrote:So how much better would it be if alexinparis, eosbandi, timecop, dominicclifton et al could get together and agree:
The usage of capabilities (and revert the clashes, guarded by a minor increment to the version number e.g. (230 => 232));
Agree an MSP message that takes one parameter uniquely identifying the FC, and then a variable sized data field at the sole discretion of the FC author (e.g. for specific version info);
Agree other MSP message allocations; at least timecop and dominic appear to have done that in the range 32-63 and 64-, even without actually talking to each other.
* I didn't notice any other clashes with regards to the capability flags.
* I chose a range for new MSP commands that appeared to be unused. I have to start defining commands that i want to use and then make sure they will work with the tools before I settle on what is actually needed. This can be seen from the recent aux/mode changes.
* I didn't agree anything with timecop since he ignores me on the forum and on irc (and has done for months now). the onus is on him to be rational and sensible. It's pretty hard to agree on anything without actual communication. I would also speculate that due to his dislike of cleanflight he won't care about cleanflight MSP compatability, I sincerely hope I am mistaken in that regard.
* Since the MSP_IDENT command is already set in stone that can't really be changed now (it's too late), an additional command that, as you say, is variable length but identifies the FC. I agree that using a capabilities bitmask isn't so great for this. I would go with 4 bytes that use letters/numbers in upper case rather than a single one however.
* Then i think there should be an API version number in the response, so that authors of tools can know and build around API changes. Uniquely identifying the FC isn't enough.
* The API version is specific to the FC and is in addition to the MSP protocol version. This is so that the first MSP command issues by a tool finds the protocol version using MSP_IDENT and then the second command issues would be to the new command to find out the finer details.
* The API version should be in the format major/minor.
* Using a build version, in the format major.minor.patchlevel be standard for all FC's that support the new command and included in the response.
* Including build date/time in the response would be good, the baseflight MSP_BUILDINFO imho is not required and not good enough since it doesn't contain the time.
* Since baseflight and cleanflight both use git, including the short git revision number in the response would be good, it's trivial to do too, cleanflight already shows this in the cli via the version command.
* Then there should be an API and FC specific section, the contents of which should be documented by the FC authors.
Maybe i have more ideas, gotta get to work now...