New Multiwii Serial Protocol

This forum is dedicated to software development related to MultiWii.
It is not the right place to submit a setup problem.
Software download
Post Reply
Tommie
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

Re: New Multiwii Serial Protocol

Post by Tommie »

Hamburger wrote:Now that is less readable and looks - not aesthetically good.

But at least now it's plain obvious that these are boolean flags; something that wasn't the case with the old variable names.
Also, following our latest coding style agreements it still needs fixing and will end up as

Code: Select all

if (rcOptions[BOXGPSHOLD]) {
  if (!GET_FLAG(FLAG_GPS_HOLD_MODE) & !GET_FLAG(FLAG_GPS_HOME_MODE)) {
    SET_FLAG(FLAG_GPS_HOLD_MODE, 1);

I disagree. Just because the functions have turned into macros their name shouldn't need to change.
Is there any benefit in this that could justify such eye sore (with or without syntax highlighting)?

It allows an easy retransition to a more efficient way of storing the flags, should the need arise to shift the balance between flash and RAM use.
Last edited by Tommie on Tue Jun 12, 2012 9:23 am, edited 1 time in total.


timecop
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: New Multiwii Serial Protocol

Post by timecop »

Pyrofer wrote:Dongs, sure, love to.
Post me a new all in one board with 32bit cpu and IMU and I will use it.

Sadly, a lot of people are limited by cost and thus stuck with the 8bit.
I applaud Alex for wanting to keep the 8bit option open to people with low budgets or existing hardware.


Stm32 from good luck buy is 23$ shipped.
Tarduino pro mini is what, 19.95?
Reuse your current imu.
I see no reason to keep 8bit

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: New Multiwii Serial Protocol

Post by Alexinparis »

Tommie wrote:Adding new message types should not break anything, but neither should appending new data to existing ones; I refrained from adding another message type for performance reasons, since transmitting two additional bytes in this message is essentially free, while adding an additional message is not. It also ensures that heading and reference heading are always in sync.

That's not my view. Reference heading is something that do not need to be refreshed at the same speed as attitude data.
attitude data message is something to represent the 3D orientation of the copter. nothing else.

Pyrofer
Posts: 180
Joined: Sat Apr 14, 2012 2:55 pm

Re: New Multiwii Serial Protocol

Post by Pyrofer »

This is getting a bit off topic Dongs, so lets try not to hog the thread but,
"Stm32 from good luck buy is 23$ shipped.
Tarduino pro mini is what, 19.95?
Reuse your current imu.
I see no reason to keep 8bit"
My Controller board was £50 with arduino328p and IMU all IN ONE.
Do you see that last bit? ALL IN ONE. I cannot "keep" my IMU unless I keep my Arduino.
Plus, it doesn't matter how cheap the stm32 is compared to the Arduino because the point is I ALREADY have the Arduino.
If you GIVE me the stm32 and IMU to replace what I have already paid for at zero cost to me I will happily use them.

Expecting me to replace hardware and buy new is not going to work.

If I was coming at this new, with a fresh budget I WOULD use a stm32.
I am however, like many others already flying a quad with hardware. I would like to improve the FW rather than replace that hardware.

Tommie
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

Re: New Multiwii Serial Protocol

Post by Tommie »

It has to be refreshed at the same speed if you wish to deduce which reference frame is used for control inputs. ATTITUDE transfers the 3D orientation of the copter, as well as the direction it considers its "bow"; this is important if you send control commands to the device.

timecop
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: New Multiwii Serial Protocol

Post by timecop »

De soldering avr and leaving sensor bits is trivial. Infact, you gain removal of stupid transistor based level shifting and other baggage related to no longer needing 5v i/o. The world moved off 5v i/o long time ago. It just sounds like you're making excuses, much like the rest of guys in this thread.

Pyrofer
Posts: 180
Joined: Sat Apr 14, 2012 2:55 pm

Re: New Multiwii Serial Protocol

Post by Pyrofer »

Dongs, I could discuss this with you for ages, but we are derailing the thread.
Instead PM me some links to good cheap stm32 boards.

copterrichie
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: New Multiwii Serial Protocol

Post by copterrichie »

Doug, with all due respect, the NAZE32 is a good board and when tuned correctly, it performs very well on my Bicopter however, the 8bit Promini previously installed on the copter performed equally as well. So going to a stm32 is purely subjective. As for MWC, if people want all of the newest features, then moving to an ATMega2560 is the answer in my opinion. Other flight controller have traveled this same path.

http://www.rcgroups.com/forums/showthread.php?t=1669324

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: New Multiwii Serial Protocol

Post by Hamburger »

Tommie wrote:
Hamburger wrote:Now that is less readable and looks - not aesthetically good.

But at least now it's plain obvious that these are boolean flags; something that wasn't the case with the old variable names.
Also, following our latest coding style agreements it still needs fixing and will end up as

Code: Select all

if (rcOptions[BOXGPSHOLD]) {
  if (!GET_FLAG(FLAG_GPS_HOLD_MODE) & !GET_FLAG(FLAG_GPS_HOME_MODE)) {
    SET_FLAG(FLAG_GPS_HOLD_MODE, 1);

I disagree. Just because the functions have turned into macros their name shouldn't need to change.

You are entitled to your opinion. But it still is against the coding style that was agreed on recently. In case you cannot find it viewtopic.php?f=8&t=1412 And before you get on your high horse, it was not _my_ decision but consensus.

Tommie wrote:
Hamburger wrote:Is there any benefit in this that could justify such eye sore (with or without syntax highlighting)?

It allows an easy retransition to a more efficient way of storing the flags, should the need arise to shift the balance between flash and RAM use.


you want us to live with this monstrous code on the offhand chance that in an unforseeable future the code might need just this change? With that same argument you could justify about everything, like making all vars float or whatever.

I can not see any good reason to trade off the former concise version of

Code: Select all

if (rcOptions[BOXGPSHOLD]) {
  if !GPSModeHold & !GPSModeHome) {
    GPSModeHold = 1;

against the code you proposed (see above to compare)

Now if we take a look at how other project handle this; from random linux drivers section they do the bitmasking in situ, so adopting their style would yield something like

Code: Select all

if (rcOptions[BOXGPSHOLD]) {
  if !(GPSflags & GPS_HOLD_MODE) & !(GPSflags & GPS_HOME_MODE) {
    GPSflags |= GPS_HOLD_MODE;

you get the idea. I do not advocate this, I do not know about effects on time and resources; just wanted to share another aspect.
Converting the current proposal in _shared to this could be done with some regexp.

Question remains: should we trade concise old style against any of the other flavours which bring
+ flags contain FLAG in their name
- source code increase
- reduced readability
- increased size
- no execution time improvement (or time penalty?)

Bottom line: does not look good. The old style has its merits still.
Take your pick

Tommie
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

Re: New Multiwii Serial Protocol

Post by Tommie »

Hamburger wrote:You are entitled to your opinion. But it still is against the coding style that was agreed on recently. In case you cannot find it viewtopic.php?f=8&t=1412 And before you get on your high horse, it was not _my_ decision but consensus.

Actually, you made that proposal and no one disagreed; probably because there werent actually any function style macros in the code at that time.

you want us to live with this monstrous code on the offhand chance that in an unforseeable future the code might need just this change? With that same argument you could justify about everything, like making all vars float or whatever.

Invalid example. Actually using a #define or typedef to wrap the variable type is common practive to avoid error prone changes during refactoring.

Now if we take a look at how other project handle this; from random linux drivers section they do the bitmasking in situ, so adopting their style would yield something like

Code: Select all

if (rcOptions[BOXGPSHOLD]) {
  if !(GPSflags & GPS_HOLD_MODE) & !(GPSflags & GPS_HOME_MODE) {
    GPSflags |= GPS_HOLD_MODE;

you get the idea. I do not advocate this, I do not know about effects on time and resources; just wanted to share another aspect.
Converting the current proposal in _shared to this could be done with some regexp.

It's the same code, only more verbose and error prone. Since all arguments are constant, the compiler boils the macros down to exactly this.
- increased size
- no execution time improvement (or time penalty?)

Neither.

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: New Multiwii Serial Protocol

Post by Hamburger »

Tommie wrote:
Hamburger wrote:You are entitled to your opinion. But it still is against the coding style that was agreed on recently. In case you cannot find it viewtopic.php?f=8&t=1412 And before you get on your high horse, it was not _my_ decision but consensus.

Actually, you made that proposal and no one disagreed; probably because there werent actually any function style macros in the code at that time.

how ignorant do you want to play? viewtopic.php?f=8&t=1412&start=10#p11231 :
kos wrote:
Hamburger wrote:use Camel style (cycleTimeMax) or get an all capitals prefix for the realm like GPS_latitude ( I found BaroAlt difficult to identify, rather prefer BAROalt or BARO_alt)



everything with underscore or all upercase is const or a define, it is ok to use upper case for acronym or short word [1]


int GPSMaxSpeed = ok
define GPS_ALT_MAX 33000 = ok
int BAROalt = ok

int BARO_alt = bad
void INIT() = bad
int GPSHOME_latitude = bad

1 : http://en.wikipedia.org/wiki/CamelCase# ... _computing

Tommie
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

Re: New Multiwii Serial Protocol

Post by Tommie »

So where does it state that functions turned into macros for performance reasons must use ALLCAPS? This does not make sense from a semantic point of view. Using ALLCAPS for #defined constants is common practice because they are literals; you cannot assign them or do anything else of the stuff usually done with variables, while function like #defines behave like functions in most common use cases.

everything with underscore or all upercase is const or a define

Check you propositional calculus. Implication does not imply equivalence.
A->B !=> B->A
A->B != A<->B

ziss_dm
Posts: 529
Joined: Tue Mar 08, 2011 5:26 am

Re: New Multiwii Serial Protocol

Post by ziss_dm »

Hi,

Generally speaking, reasons to mark all preprocessor macroses with all caps are outlined here:
http://www.cprogramming.com/tutorial/cpreprocessor.html

regards,
ziss_dm

Tommie
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

Re: New Multiwii Serial Protocol

Post by Tommie »

ziss_dm wrote:Generally speaking, reasons to mark all preprocessor macroses with all caps are outlined here:
http://www.cprogramming.com/tutorial/cpreprocessor.html

What exactly are you referring to?

"Typically, constants and macros are written in ALL CAPS to indicate they are special (as we will see)."

I do not see the need or advantage of using ALLCAPS for a macro that behaves exactly as the function it replaced.

ziss_dm
Posts: 529
Joined: Tue Mar 08, 2011 5:26 am

Re: New Multiwii Serial Protocol

Post by ziss_dm »

Hi,

Just to indicate that it is macro.. For example, it is quite tempting to do something like this:

Code: Select all

set_flag(FLAG_GPS_HOLD_MODE, !get_flag(GPS_HOLD_MODE) && !get_flag(FLAG_GPS_HOME_MODE));

and it would not work as expected.. ;) If I know, that set_flag/get_flag are macroses, first thing I would check is parentneses in macro definition.

regards,
ziss_dm

Tommie
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

Re: New Multiwii Serial Protocol

Post by Tommie »

ziss_dm wrote:Hi,

Just to indicate that it is macro.. For example, it is quite tempting to do something like this:

Code: Select all

set_flag(FLAG_GPS_HOLD_MODE, !get_flag(GPS_HOLD_MODE) && !get_flag(FLAG_GPS_HOME_MODE));

and it would not work as expected.. ;) If I know, that set_flag/get_flag are macroses, first thing I would check is parentneses in macro definition.

Oh, I see what you are getting at. But I'd consider that a bug in the macro definition, just like a faulty function may have unintended side effects.

User avatar
jevermeister
Posts: 708
Joined: Wed Jul 20, 2011 8:56 am
Contact:

Re: New Multiwii Serial Protocol

Post by jevermeister »

Tommie,

how many people does it take to change your opinion on something.

This is a community not a contest.

Please be cooperative and try not to force all you ideas into the code at once, this annoys people. Just slow down a little and do it bit by bit, so everyone else can follow and understand your changes.

I think the flags are causing more confusion and errors than advantages right now.

How about using your own branch for now, and then we compare the trunk to you branch.

Tommie
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

Re: New Multiwii Serial Protocol

Post by Tommie »

jevermeister wrote:How about using your own branch for now, and then we compare the trunk to you branch.

I've been placing bug reports and improvements with diffs (to my private branch) into this forum for quite some time now, and I made the experience that no one cares. If one isn't affected by a specific issue, it tends to be ignored.

Consider the RAM issue, which was the original trigger for me hunting down every spare byte of memory I could find, and finally yielded the bitmask implementation of flags as well as the reduction of the serial buffers; how long did it take until the existence of this actual major problem was actually acknowledged? I also reported multiple cases of undefined behaviour inside the code; no one cared, for their copters where flying. There are other examples, and it is quite frustrating to find and debug an error, create a fix, present it - only to let it rot away while the code moves on and your carefully crafted patch does not apply anymore and you can start over.

User avatar
EOSBandi
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary
Contact:

Re: New Multiwii Serial Protocol

Post by EOSBandi »

Tommie wrote:
jevermeister wrote:How about using your own branch for now, and then we compare the trunk to you branch.

I've been placing bug reports and improvements with diffs (to my private branch) into this forum for quite some time now, and I made the experience that no one cares. If one isn't affected by a specific issue, it tends to be ignored.

Consider the RAM issue, which was the original trigger for me hunting down every spare byte of memory I could find, and finally yielded the bitmask implementation of flags as well as the reduction of the serial buffers; how long did it take until the existence of this actual major problem was actually acknowledged? I also reported multiple cases of undefined behaviour inside the code; no one cared, for their copters where flying. There are other examples, and it is quite frustrating to find and debug an error, create a fix, present it - only to let it rot away while the code moves on and your carefully crafted patch does not apply anymore and you can start over.


Tommie,
Your bitmask implementation (which is NOT a bitmask anyway) is actually reinventing bitfields, with the unnecessary code obfuscation. See my comparision in the relevant thread : viewtopic.php?f=8&t=1840
EOS

ziss_dm
Posts: 529
Joined: Tue Mar 08, 2011 5:26 am

Re: New Multiwii Serial Protocol

Post by ziss_dm »

Hi Tommie,
I think, for reducing sram usage it is better to use bit field struct members. This way you do not need enums macroses and compiler doing all hard work for you. :)
Regards,
Ziss_dm

Tommie
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

Re: New Multiwii Serial Protocol

Post by Tommie »

EOSBandi wrote: Your bitmask implementation (which is NOT a bitmask anyway) is actually reinventing bitfields, with the unnecessary code obfuscation.

It's not a bitmask? (foo & 1<<n) is not using a bitmask to retrieve the state of a specific bit? Perhaps we are using different names here, but in my book, a bitmask is a mask used to filter specific bits, which is clearly the case.

User avatar
EOSBandi
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary
Contact:

Re: New Multiwii Serial Protocol

Post by EOSBandi »

http://en.wikipedia.org/wiki/Bit_field

you just reimplemented a function which is included in the C language

boke
Posts: 11
Joined: Sat Aug 13, 2011 1:36 am

Re: New Multiwii Serial Protocol

Post by boke »

Hello!
I am a student of electronics and we have a new nice projekt with multiwii.
I hope someone can helpe us. we wanna use your new serial protocol to get data to an android phone ( Java would help also).
I dont understand how i get nice values. i need some values like gyro and acc sensor values and save it to a variable or array.
Please help me.
Greetings Dennis

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: New Multiwii Serial Protocol

Post by Hamburger »

From past experience with protocols in other projects, I propose to include one new item of information to the protocol, namely the serial protocol version number. Currently, we have only MSP_IDENT which iincludes copter type and mwc version number.

For gui implementations it will become helpful to know which version of the protocol the mwc side speaks, for the protocol will evolve and change over time. This has advantages in cases of
- added/removed messages
- changed messages (like int8 -> int16, added vars)

With a protocol version number, gui coders can
- verify if their gui code speaks the same protocol version as the mwc and decide whether the gui is capable to interpret the mwc side on a solid basis, or tell the user the gui has to take a guess
- preserve compatibility for several protocol versions if they want and do a switch based on protocol number.

This 'serial protocol version number' should be completely independent from other version numbers (mwc version, eeprom version). It gets incremented with each change to the protocol.
What do you think?

fiendie
Posts: 151
Joined: Fri Apr 20, 2012 4:22 pm

Re: New Multiwii Serial Protocol

Post by fiendie »

Hamburger wrote:From past experience with protocols in other projects, I propose to include one new item of information to the protocol, namely the serial protocol version number. Currently, we have only MSP_IDENT which iincludes copter type and mwc version number.

For gui implementations it will become helpful to know which version of the protocol the mwc side speaks, for the protocol will evolve and change over time. This has advantages in cases of
- added/removed messages
- changed messages (like int8 -> int16, added vars)

With a protocol version number, gui coders can
- verify if their gui code speaks the same protocol version as the mwc and decide whether the gui is capable to interpret the mwc side on a solid basis, or tell the user the gui has to take a guess
- preserve compatibility for several protocol versions if they want and do a switch based on protocol number.

This 'serial protocol version number' should be completely independent from other version numbers (mwc version, eeprom version). It gets incremented with each change to the protocol.
What do you think?

I second the idea but it can become a kind of chicken-and-egg situation.
There has to be some kind of handshake protocol that doesn't change between versions.

Tommie
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

Re: New Multiwii Serial Protocol

Post by Tommie »

The question is which layer the version number should apply to; do you want to include the base protocol (transmission prefix $M[<>?], length, command, payload, checsum), or use it to indicate changes in the application layer (format of message FOO has changed, increment version number)?

LenzGr
Posts: 166
Joined: Wed Nov 23, 2011 10:50 am
Location: Hamburg, Germany
Contact:

Re: New Multiwii Serial Protocol

Post by LenzGr »

Hamburger wrote:This 'serial protocol version number' should be completely independent from other version numbers (mwc version, eeprom version). It gets incremented with each change to the protocol.
What do you think?


I second this proposal. This would allow a better decoupling of the GUI and firmware development and would make it easier for third-party GUIs to stay compatible.

Pyrofer
Posts: 180
Joined: Sat Apr 14, 2012 2:55 pm

Re: New Multiwii Serial Protocol

Post by Pyrofer »

I am VERY much against this.
Wasting flash to tell the GUI what version the serial protocol is? If flash is so critical how do you justify this.

You have argued over a few bytes of flash while improving FLIGHT code and making things better, and now want to waste that flash on something that will make no difference in flight at all!

It's not so hard to get the right GUI for the right version.

User avatar
EOSBandi
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary
Contact:

Re: New Multiwii Serial Protocol

Post by EOSBandi »

+1
My implementation proposal is one additional byte for the IDENT packet as a serial protocol identifier. As long as the PID and other paramaters are not self describing this number also can identify changes in the parameters.

timecop
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: New Multiwii Serial Protocol

Post by timecop »

While we're there, nicodh's request about platform identification + capabilities would be nice.
i.e. 8/32bit, cli available/not, that sorta stuff. could pack it in some bitfields (hi tommie) and declare victory.

Tommie
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

Re: New Multiwii Serial Protocol

Post by Tommie »

As a side note, I tried implementing self describing PID items; it kind of works, but takes up quite a bunch of flash memory:

https://github.com/wertarbyte/multiwii- ... ...pidconf
https://github.com/wertarbyte/multiwii- ... ...pidconf

nicodh
Posts: 44
Joined: Sun Apr 08, 2012 1:42 pm

Re: New Multiwii Serial Protocol

Post by nicodh »

Thanks dongs,
I think there is no interest on the 8/32 bits indentification.

:-(

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: New Multiwii Serial Protocol

Post by Alexinparis »

Hi,
in the last changes, I added 2 more variables in the IDENT message:
- adding MSP version in IDENT message -> version of the serial protocol
- adding a 32 bit "capability" variable in IDENT message (not currently used) -> following the idea of dongs. So this field is here, but its content is still to define.

User avatar
EOSBandi
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary
Contact:

Re: New Multiwii Serial Protocol

Post by EOSBandi »

Tommie wrote:As a side note, I tried implementing self describing PID items; it kind of works, but takes up quite a bunch of flash memory:

https://github.com/wertarbyte/multiwii- ... ...pidconf
https://github.com/wertarbyte/multiwii- ... ...pidconf


Tommie,
Your code is overkill ...the PID range and visibility could by easily coded on one byte/PID such like this, the only tradeoff the the max values are tied to the precision, but if you know the current code, it' is more less already done.

Code: Select all

#define P_PREC_1         0x00   //00 00 00 00   0-255
#define P_PREC_10          0x40   //01 00 00 00   0.0 - 25.5
#define P_PREC_100         0x80   //10 00 00 00   0.00 - 2.55
#define P_PREC_1000         0xc0   //11 00 00 00   0.00 - 0.255

#define I_PREC_1         0x00   //00 00 00 00
#define I_PREC_10          0x01   //00 01 00 00
#define I_PREC_100          0x02   //00 10 00 00
#define I_PREC_1000         0x03   //00 11 00 00

#define D_PREC_1            0x00   //00 00 00 00
#define D_PREC_10           0x04   //00 00 01 00
#define D_PREC_100          0x08   //00 00 10 00
#define D_PREC_1000         0x0c   //00 00 11 00

#define I_VISIBLE           0x02   //00 00 00 10   
#define D_VISIBLE           0x01   //00 00 00 01


#define PID_ROLL            P_PREC_10+I_PREC_1000+D_PREC_1+I_VISIBLE+D_VISIBLE
#define PID_MAG             P_PREC_10
#define P_POSHOLD_RATE      P_PREC_100+I_PREC_100+I_VISIBLE


However i'm still not a big fan of the self describing FC, since once we adding checkboxitems and pid's then we have to add other parameters (tuning, misc, debug etc...) I would go rather with a simple definition xml which defines the serial protocol and the parameters (with full names, help text, ranges etc..) and make this xml as a part of the multiwii source. Then any gui can read, parse and use this xml.
So if a dev changes a parameter or adding a new one, he simply add the definition to this xml....

User avatar
EOSBandi
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary
Contact:

Re: New Multiwii Serial Protocol

Post by EOSBandi »

Alex,
Do you have any plans on freeze of serial protocol for 2.1 release ? I would like to move ahead with the WinGUI but i postponed it until the serial protocol is not stabilised.

copterrichie
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: New Multiwii Serial Protocol

Post by copterrichie »

EOSBandi wrote:Alex,
Do you have any plans on freeze of serial protocol for 2.1 release ? I would like to move ahead with the WinGUI but i postponed it until the serial protocol is not stabilised.


It would be nice if the serial routine was contained in its own .dll file so the entire GUI does not have to wait or updated.

User avatar
EOSBandi
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary
Contact:

Re: New Multiwii Serial Protocol

Post by EOSBandi »

copterrichie wrote:
EOSBandi wrote:Alex,
Do you have any plans on freeze of serial protocol for 2.1 release ? I would like to move ahead with the WinGUI but i postponed it until the serial protocol is not stabilised.


It would be nice if the serial routine was contained in a .dll file so that the entire GUI does not have to wait.

Yeah but the content of the serial protocol defines the interface of the dll and even some GUI elements. So it's hard to decouple them...
For example i'm not a fan of the self describing serial protocol but if Alex decides to go there then the gui have to adopt.

copterrichie
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: New Multiwii Serial Protocol

Post by copterrichie »

Understood.

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: New Multiwii Serial Protocol

Post by Alexinparis »

EOSBandi wrote:For example i'm not a fan of the self describing serial protocol but if Alex decides to go there then the gui have to adopt.


Hi,

I think the current implementation can fit currently all needs:
- self describing: you can get the number of element, their name, and for exception in unit display like Pos, PosR, NavR, it's possible to parse the name and apply coef in gui (or via an xml file besides). No need to my mind to describe also the coef in the sketch as there is one constant: P,I,D are 8 bit variables.
- the way it was done before is currently ok : retrieving PID and checkbox assuming the order is defined. But it could change if an option is for instance deactivated (not done yet). So it's maybe not the best choice to rely on order to implement the GUI.

Anyway, I think this method is fine for PID and checkbox, but not for other settings which are more tied to original main functions.
In the future, ee should be able to handle this way things like sonar or optical sensors without changing a line in the gui.

message content:
If you have no specific remark on the message content, I think you can consider it is stable for 2.1 (About last additions, I think it's not too important to define now what is a "capability" as long as the variable is here)

serial protocol:
For the protocol, I think Tommie made a nice adaptation on the initial work and I see no reason to change it.

User avatar
kos
Posts: 286
Joined: Thu Feb 16, 2012 4:51 am
Location: Fr

Re: New Multiwii Serial Protocol

Post by kos »

Revision: r929 - freeze serial protocol for 2.1

;)
Last edited by kos on Thu Jun 21, 2012 12:19 am, edited 1 time in total.

copterrichie
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: New Multiwii Serial Protocol

Post by copterrichie »

I know it is after the fact now but it sure would be nice for OSD to have a Toggle ON / Toggle OFF for continuous updates without having to send a request.

Tommie
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

Re: New Multiwii Serial Protocol

Post by Tommie »

So, why no MSP_HEADING exactly?

User avatar
kos
Posts: 286
Joined: Thu Feb 16, 2012 4:51 am
Location: Fr

Re: New Multiwii Serial Protocol

Post by kos »

we can start discuss the 2.2 wishlist :)

copterrichie
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: New Multiwii Serial Protocol

Post by copterrichie »

The great thing about the OSD Toggle, it would not effect any of the current GUIs.

User avatar
kos
Posts: 286
Joined: Thu Feb 16, 2012 4:51 am
Location: Fr

Re: New Multiwii Serial Protocol

Post by kos »

in fact we should add a toggle flag for all requestable . so we can construct any osd , any gui with any refresh rate for any components

we just have to use the unused payload as the toggle flag

Code: Select all

no payload 
   // send reply and stop
else
  payload = read8
 // payload == 5 ->send reply @5 hz

Pyrofer
Posts: 180
Joined: Sat Apr 14, 2012 2:55 pm

Re: New Multiwii Serial Protocol

Post by Pyrofer »

I second this request. In fact I would like it as a simple compile time option to force GUI data out.

That way a GPS could send its data into the serial port while the GUI received the telemetry out at the same time. This would make life MUCH easier for me :)

The GPS doesn't need to receive anything so other than not having the option to configure PID etc while doing this there is no problem. I would take that minor issue over having to choose between GUI/GPS at the moment.

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: New Multiwii Serial Protocol

Post by Alexinparis »

kos wrote:in fact we should add a toggle flag for all requestable . so we can construct any osd , any gui with any refresh rate for any components

we just have to use the unused payload as the toggle flag

Code: Select all

no payload 
   // send reply and stop
else
  payload = read8
 // payload == 5 ->send reply @5 hz


Right, it's possible to do like this, and handle a timer to send regularly unsollicited messages.

But would it be really usefull ?
The OSD or GUI would still have to activate the toggle.
So, if it's possible, it's also possible to request each message.

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: New Multiwii Serial Protocol

Post by Alexinparis »

Pyrofer wrote:I second this request. In fact I would like it as a simple compile time option to force GUI data out.

That way a GPS could send its data into the serial port while the GUI received the telemetry out at the same time. This would make life MUCH easier for me :)

The GPS doesn't need to receive anything so other than not having the option to configure PID etc while doing this there is no problem. I would take that minor issue over having to choose between GUI/GPS at the moment.


For the same reason, the GUI or OSD would need to talk at least once to multiwii.
(and more time for GUI in case of sending conf)
So the problem of UART sharing remains.

Tommie
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

Re: New Multiwii Serial Protocol

Post by Tommie »

use a multiplex switch to share the RX pin. Listen for OSD commands while the engines aren't running, switch to the GPS module once the copter takes off.

Post Reply