Wishlist - MSP 2.2

[treym]

RFC MSP 2.2

making field mandatory :

• MSP_IDENT : so it reports the full MWC firmware version number, INCLUDING the patch level

adding new feature

• MSP_INIT : send a init payload the flight controler
• MSP_LOG : Openlog compatible logging on serial port in MSP format - https://github.com/multiwii/multiwii-firmware/pull/1

convert some #defines to user configurable items

• MSP_ tune esc refresh rate (only 490Hz ?)
• MSP_ tune servo refresh rate (list value ?)
• MSP_ calib gyro
• MSP_ configurable servo settings

make generic set/get and leverage the storage and decoder, if possible

• MSP_ <key>_GET
• MSP_ <key>_SET

Current MSP message not used in the GUI,

• MSP_SET_RAW_RC : emulator for TX/RX input for testing

[treym]

MSP_INIT <init_payload>

Code: Select all

if (armed){
 if (init_payload){
   //do special thing here
   if (init_payload < INIT_MSP_UART2 ) switch the decoder  to uart2
   if (init_payload <INIT_MSP_OSD ) use osd msp decoder
   etc .. 
 }
}

[Alexinparis]

MSP_MOCKTX : emulator for TX/RX input for testing[/list]

there is already MSP_SET_RAW_RC for this, no ?

MSP_ tune esc refresh rate

multiwii requirement is 490Hz capable. no plan to support ESCs with lower refresh rates as the perf is significantly worse.
but why not for SERVO refresh rate

MSP_ calib gyro

not sure about the interrest

MSP_ configurable servo settings

yes, why not

MSP_ <key>_GET
MSP_ <key>_SET[/list]

you mean renaming the message code ?

[treym]

i edited the first post with your comment , it is mainly for planning the dev work and having the firmware an gui in sync

[treym]

added MSP_LOG

[timecop]

I wonder why this got ignored? Having a generic MSP_GET/SET framework would be really great.
With a dynamically loaded page in multiwiiconf that can expose settings that are deemed too "hard" to implement on promini.
For example in baseflight I could expose all the CLI variables this way

Not to mention the definite need for firmware version/type in MSP_IDENT

[nicog]

yes, CLI variables on the main gui would be more than perfect for my crap android app.

[Alexinparis]

I wonder why this got ignored? Having a generic MSP_GET/SET framework would be really great.
With a dynamically loaded page in multiwiiconf that can expose settings that are deemed too "hard" to implement on promini.

Isn't it the case today ?
If you use servo, you will see a servo tab in GUI.
If not you won't see it.
I agree on one thing: the way for the GUI to know it is not very clean. And independent message (or maybe capability switch) should be used instead.

Not to mention the definite need for firmware version/type in MSP_IDENT

Firmware version: 2.0 2.1 2.2 ...
Each version has its set of MSP
Intermediate versions are for developers&testers
What are you expecting more ? In fact, I don't really see the point to use MSP_VERSION as is it very tied to multiwii version.

[timecop]

I wonder why this got ignored? Having a generic MSP_GET/SET framework would be really great.
With a dynamically loaded page in multiwiiconf that can expose settings that are deemed too "hard" to implement on promini.

Isn't it the case today ?
If you use servo, you will see a servo tab in GUI.
If not you won't see it.
I agree on one thing: the way for the GUI to know it is not very clean. And independent message (or maybe capability switch) should be used instead.

No, I'm talking about a generic framework that can pass any type of value across.
* a MSP to get a 'list' of available "configurable" values, ex
name(descriptive string),type(uint8/int32/float/???),range(min-max). might need to be "paged" to not overrun serial buffer. i.e. get variable names page 1,2,3 - returning 10items per reply.
* present this stuff in some sane way in multiwiiconf (probly a new tab, just full of name [ entry box/slider/whatever ])
* have a 'get' MSP that takes setting index or name or whatever, and returns current value.
* have a 'set' MSP that takes setting index or name or whatever, and writes it to the board.

This way you won't need special "hacks" for minthrottle/failsafe/etc, they can all be served in a generic way and a hardware with better capabilities (tarduino mega or proper hardware) can expose more user-tunable settings via GUI

[treym]

I don't really see the point to use MSP_VERSION as is it very tied to multiwii version.

yes, that the whole point .. so if we add a new capabilitie we have to update the gui ..

that would just solve that.

Code: Select all

foreach capabilitie  in getCapabilities 
  draw(capabilitie)

[timecop]

Bumping for generic get/set framework.

Also, while I'm writing here, a private MSP get/set range that is guaranteed not to be used by "standard" MWC would be nice - so people can implement custom messages without worrying about them being overrun by default configurator.

[treym]

hi,

i think we can use something like this to deal with custom/private/oem msp : we can leverage the payload usage ?

Code: Select all

// customMSP[MSP_EXTENSION_PAYLOADMAX]
//void evaluateCustomCommand(void);

    case MSP_CUSTOM:
        for (i = 0; i < dataSize; i++){
            read8();
            //customMSP[customMSPindex++]=read8();
        }
        // TODO customMSP = evaluateCustomCommand();
        headSerialReply(1);
        serialize8(i);
        break;

this goes without extra cost for mwi

Code: Select all

#ifdef MSP_PROTOCOL_EXTENSION
    #define MSP_CUSTOM                 1  // unknow message    custom crafted message
#endif

http://code.google.com/p/multiwii/sourc ... ?r=1647#18

[Alexinparis]

Hi,

Bumping for generic get/set framework.

I don't see clearly the request.
Is it something:
- like treym suggests (a generic customMSP table)
- or the ability to change any multiwii variable ? <- I don't know how this can be done easily

Also, while I'm writing here, a private MSP get/set range that is guaranteed not to be used by "standard" MWC would be nice - so people can implement custom messages without worrying about them being overrun by default configurator.

ok, a suggestion for the range ?

[treym]

it is both

with a generic customMSP one can use the payload to create additionnal mesages , and paved the way toward the ability to change any baseflight (or multiwii fork) variables.

the only requirement is to have a reserved msp for this purpose , ie #define MSP_CUSTOM 1

[timecop]

I don't see clearly the request.
Is it something:
- like treym suggests (a generic customMSP table)
- or the ability to change any multiwii variable ? <- I don't know how this can be done easily

treym custommsp suggestion is OK.

generic get/set framework doesn't sound very complex to me.
You will need 3 MSPs (or a subset in one, i.e. MSP + function code (LIST/GET/SET) + data)
LIST, GET, SET.
LIST can take params, like start,end range of data to return. this will allow devices with trash memory to return a couple names at a time, not increasing memory usage on promini.

LIST returns a (paged) array of variable names.
GET returns variable type/data/min/max values or something
SET will set that variable

so typical usage would be something like
LIST0,10... LIST11,20... LIST21..30 (mwc stops sending after index 25, so client app knows there's only 26 variables editable)
GET0.. GET1.. GET2.. ... GET25 (receive values and min/max/whatever stuff)
show UI
SET3..1000 (for example) to set 4th (index 3) variable to 1000.

[cTn]

any progress on this? some people like (me) are in desperate need of command like this :/

[treym]

https://github.com/multiwii/multiwii-fi ... 5c40e7238b

thanks Alex