open.20.fsguruh@xoxy.net 67689c8f71 [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?
2013-03-09 17:19:56 +00:00
2012-11-15 02:10:48 +00:00
2012-05-07 18:35:48 +00:00
2012-04-21 17:52:06 +00:00
S
Description
No description provided
GPL-2.0
400 MiB
Languages
C 71.9%
C++ 25.4%
Python 0.9%
CMake 0.6%
Shell 0.3%
Other 0.7%