Global variables

[GoogleCodeExporter]

I should revive the global setting solution I suggested to Bertrand some time 
ago. These things really get forgotten if we don't open enhancement issues for 
them... -> there we go

In short:
- Have a certain number of "global variables" that can mirror anything (fixed 
value, control input, channel output, telemetry value,... with the same loooong 
list we have for sources in custom switches)
- Be able to assign these global values to any field that would normally hold a 
number. As those fields can usually hold a few more values in the bitfield size 
than the +/-125 limit for numbers (mixer weights and offsets, D/Rs, expos, 
limits, etc) those "unused" values could be mapped to the GVs. For example a 
8-bit field that's used between -125 and +125 has 5 unused values, so it would 
be easy to assign a choice of 5 GVs to any 8-bit numeric field without 
additional eeprom. The only eeprom needed would be the 5 bytes to store the 
choices for the input to those GVs. Maybe also min/max values, so the 
adjustment range can be constrained.

Would add even more possibilities to do very twisted things, plus make it 
convenient to do things like that variable expo that owners of radios that 
allow it love (e.g. Multiplex, where any numerical parameter can be assigned to 
one of the 2 rotary encoders for easy in-flight adjustment)

Original issue reported on code.google.com by bernet.a...@gmail.com on 8 Oct 2012 at 8:07

[GoogleCodeExporter]

Excellent thing, already proposed in the issue #54, I really enjoy that it 
would be done.

Global variables are essential to simplify the programming of redundant values 
(used twice or more in the same goal), typically with two or more servos acting 
in the same way (ailerons, dual-elevator, etc.) for differentiel or mixer rates.

In the opposite, global variable are not very useful for D/R, expo or limits 
because each value has a different and specific use. For exemple, there is no 
reason to have the same D/R between aileron and elevator D/R.

Original comment by f.ague...@wanadoo.fr on 9 Oct 2012 at 7:56

[GoogleCodeExporter]

Well, as global variables could use anything as a source, like a pot or trim 
for example, they would be useful also for these as they would allow easy 
in-flight adjustment. 

Original comment by bernet.a...@gmail.com on 9 Oct 2012 at 7:59

[GoogleCodeExporter]

Right issue 54 is more or less the same. I don't remember why I changed its 
state to fixed. My main concern will be the flash consumption. Easily fixed 
with the introduction of a new compilation option.

Now about the implementation:

- I would like to start with only 2 variables X1 and X2. It allows their use 
with values max+1 and max+2 (126 and 127 when the max is 125)

- Do we agree that 
   1) X1 and X2 will be model based
   2) X1 and X2 will be stored in EEPROM at each change

- On which screen will they be associated to a source? I would rather propose a 
new Function Switch which could be something like:
   THR ... Register X1 ... P1

Original comment by bson...@gmail.com on 9 Oct 2012 at 8:49

• Changed state: Accepted

[GoogleCodeExporter]

- How will we switch from a numerical value to a register value on a field? 
[MENU Long] would be ok?

Original comment by bson...@gmail.com on 9 Oct 2012 at 8:52

[GoogleCodeExporter]

OK for two GV.
OK for [MENU Long] to acces to GV list.
OK for a model based (indispensable!).

For the modification of the GV's value : we should be able to modify them like 
any other valeur (keys +/-), and we should be able to use a potentiometer or a 
rotary encoder for inflight adjustement.
In the same time, I would suggest to extend to any value (mix rate, 
differential, etc.) the inflight adjustment feature.

Original comment by f.ague...@wanadoo.fr on 9 Oct 2012 at 11:50

[GoogleCodeExporter]

If the registers need to be modified using the keys, they must be displayed 
somewhere in a Menu. I don't know where it would fit at the best.

Also I think we would need to define a min and a max for each register.

Original comment by bson...@gmail.com on 9 Oct 2012 at 12:13

[GoogleCodeExporter]

As Curves could be considered as global variables, with not add two lignes in 
this menu for GV X1 and X2 ?

For min/max : a default +/-100%, or +/-125%, will be sufficient in most of 
cases. That will not prevent an in-flight "stupid" setting (like a 0% rate for 
an elevator entry in a mixer!), but it is the same problem for other settings 
like dual-rate. So, I think it will be better to keep it as simple as possible 
and let the user taking care about what he is doing.

Original comment by f.ague...@wanadoo.fr on 9 Oct 2012 at 1:39

[GoogleCodeExporter]

I tried it in CURVES menu, but I don't like the result...

Original comment by bson...@gmail.com on 15 Oct 2012 at 12:28

Attachments:

• snapshot_05.png

[GoogleCodeExporter]

It could be better if the value of Reg.X are shown only when highlighted (like 
what is done with curves).
Or, if you want to let the values always visible, they can be put on the right 
on the screen, on the other side of the graph.

Original comment by f.ague...@wanadoo.fr on 15 Oct 2012 at 2:36

[GoogleCodeExporter]

Woops, for some reason I didn't have notifications turned on - can't wait to 
see the draft implementation :)

Original comment by bernet.a...@gmail.com on 15 Oct 2012 at 4:34

[GoogleCodeExporter]

Screenshots here:
http://9xforums.com/forum/viewtopic.php?f=45&t=1850&p=26463#p26463

Original comment by bson...@gmail.com on 15 Oct 2012 at 5:25

[GoogleCodeExporter]

Original comment by bson...@gmail.com on 15 Oct 2012 at 5:25

• Changed state: Started

[GoogleCodeExporter]

Romolo asked for Flight Phases dependant global variables here:
http://9xforums.com/forum/posting.php?mode=quote&f=45&t=1850&p=26647
I am ok with that (except on stock board), but what do you think of it?

Original comment by bson...@gmail.com on 17 Oct 2012 at 6:47

[GoogleCodeExporter]

YES !

Original comment by f.ague...@wanadoo.fr on 17 Oct 2012 at 8:02

[GoogleCodeExporter]

YES !

Original comment by bernet.a...@gmail.com on 17 Oct 2012 at 8:03

[GoogleCodeExporter]

Done. Will be in next release as soon as companion9x is ready

Original comment by bson...@gmail.com on 24 Oct 2012 at 8:40

• Changed state: Fixed