From 67689c8f7148a02ad47ee1f76999d0a6c5293c9a Mon Sep 17 00:00:00 2001 From: "open.20.fsguruh@xoxy.net" Date: Sat, 9 Mar 2013 17:19:56 +0000 Subject: [PATCH] [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 | 12 +++++++++++- src/myeeprom.h | 6 ++++-- src/open9x.cpp | 3 ++- src/open9x.h | 23 ++++++----------------- 4 files changed, 23 insertions(+), 21 deletions(-) diff --git a/src/Makefile b/src/Makefile index b36e6d431..c2ddf89e4 100644 --- a/src/Makefile +++ b/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 diff --git a/src/myeeprom.h b/src/myeeprom.h index 3a30457e1..3a794d27d 100644 --- a/src/myeeprom.h +++ b/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] diff --git a/src/open9x.cpp b/src/open9x.cpp index 727805925..a39c12abb 100644 --- a/src/open9x.cpp +++ b/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 { diff --git a/src/open9x.h b/src/open9x.h index ddd1fa49f..2b489b83e 100644 --- a/src/open9x.h +++ b/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