[Patch for r1181] Transmit additional AUX Channels to GUI

[cGiesen]

Hello,

this patch add teh posibillity to transmit the AUX channels higher than AUX4.
In the moment it's hardcoded to 8 now it's fit to RC_CHANS

There is a new MSP command.
This give my GUI the number of AUX Channels to prepare the GUI.

Code: Select all

Index: Serial.ino
===================================================================
--- Serial.ino   (Revision 1181)
+++ Serial.ino   (Arbeitskopie)
@@ -49,6 +49,8 @@
 #define MSP_PIDNAMES             117   //out message         the PID names
 #define MSP_WP                   118   //out message         get a WP, WP# is in the payload, returns (WP#, lat, lon, alt, flags) WP#0-home, WP#16-poshold
 
+#define MSP_AUX_COUNT            119   //out message         number of AUX channels 
+
 #define MSP_SET_RAW_RC           200   //in message          8 rc chan
 #define MSP_SET_RAW_GPS          201   //in message          fix, numsat, lat, lon, alt, speed
 #define MSP_SET_PID              202   //in message          up to 16 P I D (8 are used)
@@ -316,8 +318,8 @@
      }
      break;
    case MSP_RC:
-     headSerialReply(16);
-     for(uint8_t i=0;i<8;i++) serialize16(rcData[i]);
+     headSerialReply(RC_CHANS * 2);
+     for(uint8_t i=0;i<RC_CHANS;i++) serialize16(rcData[i]); 
      break;
    #if GPS
    case MSP_RAW_GPS:
@@ -417,6 +419,11 @@
      }
      break;  
    #endif
+   case MSP_AUX_COUNT:
+     headSerialReply(2);
+     serialize8(RC_CHANS);
+     serialize8(3);
+     break;  
    case MSP_RESET_CONF:
      if(!f.ARMED) LoadDefaults();
      headSerialReply(0);
@@ -789,4 +796,4 @@
 }
 #else
 void debugmsg_append_str(const char *str) {};
-#endif
+#endif 

My GUI:
https://github.com/cGiesen/multiwii-gui-processing.git

Regards
Carsten

[Mis]

The MSP_AUX_COUNT is not needed. PC application should count number of RC channels from "size" field of MSP_RC command.

[cGiesen]

Sorry, there is now size!
And I need this command befor I ask for MSP_RC.
Otherwise I run I outoff range.

And by the way, there is AUX Steps for future build in!

[Sebbi]

I agree with Mis. You can do MSP_RC and the length of the result will tell you how much Aux channels to display. The information is already there, so why duplicate it?

Number of Aux steps can also be derived from rcData and/or MultiWii version.

[cGiesen]

[cGiesen]

Ok, I start dealing with the lenght of the rc result.
But what about this?

Code: Select all

    case MSP_RC:
-     headSerialReply(16);
-     for(uint8_t i=0;i<8;i++) serialize16(rcData[i]);
+     headSerialReply(RC_CHANS * 2);
+     for(uint8_t i=0;i<RC_CHANS;i++) serialize16(rcData[i]); 
      break;

[Hamburger]

you beat me.

to ease the path how about this:

the following excerpt taken from the proposed patch seems acceptable and does not break anything ?

Code: Select all

    case MSP_RC:
-     headSerialReply(16);
-     for(uint8_t i=0;i<8;i++) serialize16(rcData[i]);
+     headSerialReply(RC_CHANS * 2);
+     for(uint8_t i=0;i<RC_CHANS;i++) serialize16(rcData[i]);
      break;

though I do not currently know where RC_CHANS gets defined.

[cGiesen]

you beat me.

though I do not currently know where RC_CHANS gets defined.

Thats easy:

def.h row 1228:

Code: Select all

#if defined(SBUS)
  #define RC_CHANS 18
#elif defined(SPEKTRUM) || defined(SERIAL_SUM_PPM)
  #define RC_CHANS 12
#else
  #define RC_CHANS 8
#endif 

[Hamburger]

ok.
Then I will include that excerpt next time I submit if no one else has done it till then.

[cGiesen]

Thanks

[Hamburger]

just an afterthought:
what will happen to the GUI for those cases where RC_CHANS > ?

[Sebbi]

Code: Select all

case MSP_RC:
        rcRoll = read16();rcPitch = read16();rcYaw = read16();rcThrottle = read16();    
        rcAUX1 = read16();rcAUX2 = read16();rcAUX3 = read16();rcAUX4 = read16(); break;

That's the current GUI code which just ignores additional channels. I understand cGiesen has a different version of the GUI (based on an old version, but I'm sure he can adapt it the the current dev release) supporting more channels.

[cGiesen]

[code]I understand cGiesen has a different version of the GUI (based on an old version, but I'm sure he can adapt it the the current dev release) supporting more channels.

No I can't
Because there is no room for the controls!
That's the reason I create a new version with an tab controll.

viewtopic.php?f=8&t=2592

But we will run out of room, when we get more features.
But I see, it's more important to have nice new gimmicks ...

[Hamburger]

Code: Select all

case MSP_RC:
        rcRoll = read16();rcPitch = read16();rcYaw = read16();rcThrottle = read16();    
        rcAUX1 = read16();rcAUX2 = read16();rcAUX3 = read16();rcAUX4 = read16(); break;

That's the current GUI code which just ignores additional channels..

yes. But by then the mwc has pumped the additional data through the serial chain. The GUI input buffer gets emptied and the surplus data discarded?
This msp should maybe changed to transmit RC_CHANs as its first value? This hardcoded '8' instead of the appropriate symbol in the sending code was a relic from the very old days.

Either way, not my beef.

[Hamburger]

But I see, it's more important to have nice new gimmicks ...

?
I was under the impression you yourself were very interested in 'nice new gimmicks'? Why else would you want more than 8 channels?

[cGiesen]

That was just a sarcastic remark.

I allways here more than 8 channels are unnecessary.

But new visualizations are made continuously.
I think, the GUI is only for settings and testing! And I do not need an artificial horizon.
But this is going to the code....

[Sebbi]

What I meant is, that you need to adapt your changes (tabs, more aux channels displayed) to the current version and not some month old version

P.S.: It goes into the code because it's tested, liked and works. That's easier to accomplish with GUI changes than functional changes like new AUX channels. Having more than eight 2ms channels in a PPM stream that is supposed to be 20 ms long per frame is something non standard and needs testing to make sure it works for everyone. But I agree, those who have commit access often commit things with bugs (e.g. not fully tested functionality) and then fix them later. Kind of annoying

[cGiesen]

GUICapture.JPG

What I meant is, that you need to adapt your changes (tabs, more aux channels displayed) to the current version and not some month old version

Sorry, now I get really frustated
viewtopic.php?f=8&t=2192

by cGiesen » Fri Aug 03, 2012 12:12 pm
2.1 yust released

and by the way:
the tab controll is a night mare.....

[cGiesen]

Is there some think that help coding a GUI in Proccesing?

I see only writing...

Edit:
Correction, coding in Processing is an night mare....

[cGiesen]

Hello Again,

I wonder, why I can't set AUX6 (for example) to switch some functions.
After a closer look, I see the activation variable is only 16Bit.
That's only hold 16 checkboxes.

We see, to have more than 8 usable channels is still a long way.
And to have more than 3 states, what Tommie is asking for, is still a longer way.

For both, we have to think about a different way to hold the information.

But it's ok in generall to have the new channels. They can be use for gimble or other function that are comming in future.
Perhaps to switch lamps or open an candy box. But for that we do not use the standard activation functions.

I will cancel my GUI project now, take the actual on, and try to put the new channels only for visualisation in.

regards
Carsten

[Sebbi]

That's what i meant ... sorry, I did not see that the post was from August 3rd ... time flies. I hope you are successful though, because I just found out my T9x could send 12 or 16 channels too ... no restrictions on payload functions hurray

[cGiesen]

Ok, first try.

Please give me a test and feedback

[cGiesen]

That's what i meant ... sorry, I did not see that the post was from August 3rd ... time flies. I hope you are successful though, because I just found out my T9x could send 12 or 16 channels too ... no restrictions on payload functions hurray

You do not need more than 8 channels !!!!
Your words....