[BRANCH] preperation for merge to trunk; GVARS 5; introduced RANGE constant

I would like Bertrand to check this version. It's currently my proposal for the merge. It holds following changes:

- Introduced constant RESERVE_RANGE_FOR_GVARS to make number of MAX_GVARS independent.
- NEGATIVE_SHIFT_CORRECTION is now set by makefile by default instead inside the code
  The would at least give the option to save code and have less precise calculation.
- ex_chans is included like in trunk. No change here, because it would break output as input.

Actually this version would reduce the effort to merge:

- We stay with the GVARS defines we had till now
- We reserve for ranges space for 10 GVARS, which do not hurt, because  we doubled ranges anyway.
- We stay with 5 GVARS in the moment. According my poll not many people currently use GVARS.
  Therefore there is plenty of time finding here a better solution. I expect the number of 
  people will increase soon, but up to this moment 5 GVARS are more than enough.
- The layout of EEPROM for the values is already the new format. That means when we allow more GVARS in future, at least the parameters like weight, offset, etc. needs no additional conversion.

What do you think. Should we go this way?

src/Makefile

@@ -98,9 +98,15 @@ AUDIO = NO
 VOICE = NO
 
 # corrects different rounding for negative values. So instead of -99.9 you will see again -100.0
-CORRECT_NEGATIVE_VALUES = NO
+# Values = YES, NO
+CORRECT_NEGATIVE_VALUES = YES
+
+# adds additional code to prevent arithmetic overflows. MAX or MIN values stays. Not yet guaranteed!! Just improved
+# Values = YES, NO
+ARITHMETIC_OVERFLOW_CHECK = NO
 
 # increases range of expo curve but costs about 82 bytes flash
+# Values = YES, NO
 EXTENDED_EXPO_CURVE = NO
 
 # HAPTIC Mods
@@ -420,6 +426,10 @@ ifeq ($(CORRECT_NEGATIVE_VALUES), YES)
   CPPDEFS += -DCORRECT_NEGATIVE_SHIFTS
 endif
 
+ifeq ($(ARITHMETIC_OVERFLOW_CHECK), YES)
+  CPPDEFS += -DPREVENT_ARITHMETIC_OVERFLOW
+endif
+
 ifeq ($(EXTENDED_EXPO_CURVE), YES)
   CPPDEFS += -DEXTENDED_EXPO
 endif

src/myeeprom.h

@@ -73,8 +73,10 @@ typedef char gvar_name_t[6];
 #define GVAR_MAX  1024
 #endif
 
+#define RESERVE_RANGE_FOR_GVARS 10
+// even we do not spend space in EEPROM for 10 GVARS, we reserve the space inside the range of values, like offset, weight, etc.
 #if defined(CPUM64) && defined(GVARS)
-  #define MAX_GVARS 9
+  #define MAX_GVARS 5
   #define MODEL_GVARS_DATA gvar_t gvars[MAX_GVARS];
   #define PHASE_GVARS_DATA
   #define GVAR_VALUE(x, p) g_model.gvars[x]
@@ -83,7 +85,7 @@ typedef char gvar_name_t[6];
   #define MODEL_GVARS_DATA
   #define PHASE_GVARS_DATA
 #elif defined(GVARS)
-  #define MAX_GVARS 9
+  #define MAX_GVARS 5
   #define MODEL_GVARS_DATA gvar_name_t gvarsNames[MAX_GVARS];
   #define PHASE_GVARS_DATA gvar_t gvars[MAX_GVARS]
   #define GVAR_VALUE(x, p) g_model.phaseData[p].gvars[x]

src/open9x.cpp

@@ -658,7 +658,7 @@ void applyExpos(int16_t *anas)
 
 #if !defined(CPUARM)
 
-#define CORRECT_NEGATIVE_SHIFTS
+// #define CORRECT_NEGATIVE_SHIFTS
 // open.20.fsguruh; shift right operations do the rounding different for negative values compared to positive values
 // so all negative divisions round always further down, which give absolute values bigger compared to a usual division
 // this is noticable on the display, because instead of -100.0 -99.9 is shown; While in praxis I doublt somebody will notice a 
@@ -666,6 +666,7 @@ void applyExpos(int16_t *anas)
 // this define would correct this, but costs 34 bytes code for stock version
 
 // currently we set this to active always, because it might cause a fault about 1% compared positive and negative values
+// is done now in makefile
 
 int16_t calc100to256_16Bits(int16_t x) // return x*2.56
 {

src/open9x.h

@@ -825,16 +825,9 @@ void incRotaryEncoder(uint8_t idx, int8_t inc);
     #define GV1_LARGE  256
   #endif
 
-  // depends if we want free ranges for use, if no MAX_GVARS are smaller
-  // if not this would assume a max for GVARS instead using MAX_GVARS
-  #define GV_RANGESMALL      (GV1_SMALL - (MAX_GVARS+1))
-  #define GV_RANGESMALL_NEG  (-GV1_SMALL + (MAX_GVARS+1))
-  #define GV_RANGELARGE      (GV1_LARGE - (MAX_GVARS+1))
-  #define GV_RANGELARGE_NEG  (-GV1_LARGE + (MAX_GVARS+1))
-  
   #define GV_IS_GV_VALUE(x,min,max)    ( (x>max) || (x<min) )
   #define GV_GET_GV1_VALUE(max)        ( (max<=GV_RANGESMALL) ? GV1_SMALL : GV1_LARGE )
-  #define GV_INDEX_CALCULATION(x,max)  ( (max <= GV1_SMALL) ?  (uint8_t) x-GV1_SMALL  : \
+  #define GV_INDEX_CALCULATION(x,max)  ( (max<=GV1_SMALL) ? (uint8_t) x-GV1_SMALL  : \
                                        (  (x&(GV1_LARGE*2-1))-GV1_LARGE ) )
   #define GV_INDEX_CALC_DELTA(x,delta) ((x&(delta*2-1)) - delta)
 
@@ -846,17 +839,13 @@ void incRotaryEncoder(uint8_t idx, int8_t inc);
   extern uint8_t s_gvar_last;
 #else
   #define GET_GVAR(x, ...) (x)
-
-  // can be used also without GVARS for allowed parameter ranges (makes -500 +500 range for weight unneccessary)
-  // do we want to allow wider ranges without GVARS? Would cause a conversion problem later on, a lot of options needs to be check to do it right
-  #define GV1_SMALL  128
-  #define GV1_LARGE  256
-  #define GV_RANGESMALL      (GV1_SMALL-1)
-  #define GV_RANGESMALL_NEG  (-GV1_SMALL+1)
-  #define GV_RANGELARGE      (GV1_LARGE-1)
-  #define GV_RANGELARGE_NEG  (-GV1_LARGE+1)  
 #endif
 
+#define GV_RANGESMALL      (GV1_SMALL - (RESERVE_RANGE_FOR_GVARS+1))
+#define GV_RANGESMALL_NEG  (-GV1_SMALL + (RESERVE_RANGE_FOR_GVARS+1))
+#define GV_RANGELARGE      (GV1_LARGE - (RESERVE_RANGE_FOR_GVARS+1))
+#define GV_RANGELARGE_NEG  (-GV1_LARGE + (RESERVE_RANGE_FOR_GVARS+1))
+
 extern uint16_t s_timeCumTot;
 extern uint16_t s_timeCumThr;  //gewichtete laufzeit in 1/16 sec
 extern uint16_t s_timeCum16ThrP; //gewichtete laufzeit in 1/16 sec