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

Re: New Multiwii Serial Protocol

Postby Tommie » Tue Jun 12, 2012 9:22 am

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.
Tommie
 
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

Re: New Multiwii Serial Protocol

Postby nicodh » Tue Jun 12, 2012 9:22 am

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

Re: New Multiwii Serial Protocol

Postby timecop » Tue Jun 12, 2012 9:47 am

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
timecop
 
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: New Multiwii Serial Protocol

Postby Alexinparis » Tue Jun 12, 2012 9:50 am

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.
Alexinparis
 
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: New Multiwii Serial Protocol

Postby Pyrofer » Tue Jun 12, 2012 9:53 am

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.
Pyrofer
 
Posts: 180
Joined: Sat Apr 14, 2012 2:55 pm

Re: New Multiwii Serial Protocol

Postby Tommie » Tue Jun 12, 2012 9:56 am

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.
Tommie
 
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

Re: New Multiwii Serial Protocol

Postby timecop » Tue Jun 12, 2012 11:23 am

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.
timecop
 
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: New Multiwii Serial Protocol

Postby Pyrofer » Tue Jun 12, 2012 12:03 pm

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.
Pyrofer
 
Posts: 180
Joined: Sat Apr 14, 2012 2:55 pm

Re: New Multiwii Serial Protocol

Postby copterrichie » Tue Jun 12, 2012 4:13 pm

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
copterrichie
 
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: New Multiwii Serial Protocol

Postby Hamburger » Tue Jun 12, 2012 10:28 pm

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
User avatar
Hamburger
 
Posts: 2557
Joined: Tue Mar 01, 2011 2:14 pm
Location: air

Re: New Multiwii Serial Protocol

Postby Tommie » Tue Jun 12, 2012 10:48 pm

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.
Tommie
 
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

Re: New Multiwii Serial Protocol

Postby Hamburger » Tue Jun 12, 2012 11:04 pm

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
User avatar
Hamburger
 
Posts: 2557
Joined: Tue Mar 01, 2011 2:14 pm
Location: air

Re: New Multiwii Serial Protocol

Postby Tommie » Tue Jun 12, 2012 11:19 pm

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
Tommie
 
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

Re: New Multiwii Serial Protocol

Postby ziss_dm » Wed Jun 13, 2012 7:51 am

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
ziss_dm
 
Posts: 529
Joined: Tue Mar 08, 2011 5:26 am

Re: New Multiwii Serial Protocol

Postby Tommie » Wed Jun 13, 2012 8:12 am

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.
Tommie
 
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

Re: New Multiwii Serial Protocol

Postby ziss_dm » Wed Jun 13, 2012 9:52 am

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
ziss_dm
 
Posts: 529
Joined: Tue Mar 08, 2011 5:26 am

Re: New Multiwii Serial Protocol

Postby Tommie » Wed Jun 13, 2012 10:05 am

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.
Tommie
 
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

Re: New Multiwii Serial Protocol

Postby jevermeister » Wed Jun 13, 2012 10:39 am

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.
User avatar
jevermeister
 
Posts: 708
Joined: Wed Jul 20, 2011 8:56 am

Re: New Multiwii Serial Protocol

Postby Tommie » Wed Jun 13, 2012 10:54 am

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
 
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

Re: New Multiwii Serial Protocol

Postby EOSBandi » Wed Jun 13, 2012 11:19 am

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
User avatar
EOSBandi
 
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary

Re: New Multiwii Serial Protocol

Postby ziss_dm » Wed Jun 13, 2012 11:29 am

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
ziss_dm
 
Posts: 529
Joined: Tue Mar 08, 2011 5:26 am

Re: New Multiwii Serial Protocol

Postby Tommie » Wed Jun 13, 2012 4:59 pm

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.
Tommie
 
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

Re: New Multiwii Serial Protocol

Postby EOSBandi » Wed Jun 13, 2012 5:49 pm

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

you just reimplemented a function which is included in the C language
User avatar
EOSBandi
 
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary

Re: New Multiwii Serial Protocol

Postby boke » Thu Jun 14, 2012 10:16 pm

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
boke
 
Posts: 11
Joined: Sat Aug 13, 2011 1:36 am

Re: New Multiwii Serial Protocol

Postby Hamburger » Fri Jun 15, 2012 10:19 am

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?
User avatar
Hamburger
 
Posts: 2557
Joined: Tue Mar 01, 2011 2:14 pm
Location: air

Re: New Multiwii Serial Protocol

Postby fiendie » Fri Jun 15, 2012 10:32 am

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.
fiendie
 
Posts: 151
Joined: Fri Apr 20, 2012 4:22 pm

Re: New Multiwii Serial Protocol

Postby Tommie » Fri Jun 15, 2012 10:43 am

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)?
Tommie
 
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

Re: New Multiwii Serial Protocol

Postby LenzGr » Fri Jun 15, 2012 10:49 am

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.
User avatar
LenzGr
 
Posts: 166
Joined: Wed Nov 23, 2011 10:50 am
Location: Hamburg, Germany

Re: New Multiwii Serial Protocol

Postby Pyrofer » Fri Jun 15, 2012 10:59 am

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.
Pyrofer
 
Posts: 180
Joined: Sat Apr 14, 2012 2:55 pm

Re: New Multiwii Serial Protocol

Postby EOSBandi » Fri Jun 15, 2012 11:12 am

+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.
User avatar
EOSBandi
 
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary

Re: New Multiwii Serial Protocol

Postby timecop » Fri Jun 15, 2012 11:14 am

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.
timecop
 
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: New Multiwii Serial Protocol

Postby Tommie » Fri Jun 15, 2012 11:18 am

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
 
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

Re: New Multiwii Serial Protocol

Postby nicodh » Sun Jun 17, 2012 10:57 am

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

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

Re: New Multiwii Serial Protocol

Postby Alexinparis » Sun Jun 17, 2012 12:35 pm

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.
Alexinparis
 
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: New Multiwii Serial Protocol

Postby EOSBandi » Sun Jun 17, 2012 12:46 pm

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

Re: New Multiwii Serial Protocol

Postby EOSBandi » Mon Jun 18, 2012 8:51 pm

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.
User avatar
EOSBandi
 
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary

Re: New Multiwii Serial Protocol

Postby copterrichie » Mon Jun 18, 2012 9:01 pm

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.
copterrichie
 
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: New Multiwii Serial Protocol

Postby EOSBandi » Mon Jun 18, 2012 9:05 pm

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.
User avatar
EOSBandi
 
Posts: 802
Joined: Sun Jun 19, 2011 11:32 am
Location: Budapest, Hungary

Re: New Multiwii Serial Protocol

Postby copterrichie » Mon Jun 18, 2012 9:06 pm

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

Re: New Multiwii Serial Protocol

Postby Alexinparis » Mon Jun 18, 2012 10:19 pm

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.
Alexinparis
 
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: New Multiwii Serial Protocol

Postby kos » Wed Jun 20, 2012 11:33 pm

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.
User avatar
kos
 
Posts: 286
Joined: Thu Feb 16, 2012 4:51 am
Location: Fr

Re: New Multiwii Serial Protocol

Postby copterrichie » Wed Jun 20, 2012 11:43 pm

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.
copterrichie
 
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: New Multiwii Serial Protocol

Postby Tommie » Thu Jun 21, 2012 12:05 am

So, why no MSP_HEADING exactly?
Tommie
 
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

Re: New Multiwii Serial Protocol

Postby kos » Thu Jun 21, 2012 12:19 am

we can start discuss the 2.2 wishlist :)
User avatar
kos
 
Posts: 286
Joined: Thu Feb 16, 2012 4:51 am
Location: Fr

Re: New Multiwii Serial Protocol

Postby copterrichie » Thu Jun 21, 2012 12:36 am

The great thing about the OSD Toggle, it would not effect any of the current GUIs.
copterrichie
 
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: New Multiwii Serial Protocol

Postby kos » Thu Jun 21, 2012 12:42 am

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
User avatar
kos
 
Posts: 286
Joined: Thu Feb 16, 2012 4:51 am
Location: Fr

Re: New Multiwii Serial Protocol

Postby Pyrofer » Thu Jun 21, 2012 10:14 am

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.
Pyrofer
 
Posts: 180
Joined: Sat Apr 14, 2012 2:55 pm

Re: New Multiwii Serial Protocol

Postby Alexinparis » Thu Jun 21, 2012 12:56 pm

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

Postby Alexinparis » Thu Jun 21, 2012 12:58 pm

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.
Alexinparis
 
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: New Multiwii Serial Protocol

Postby Tommie » Thu Jun 21, 2012 1:03 pm

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.
Tommie
 
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

PreviousNext

Return to Software development

Who is online

Users browsing this forum: No registered users and 10 guests