Merge branch 'for-upstream-ff' into iwj

update from for-upstream (merge -s theirs)

M206: save values in eeprom

Really, we should have a way to adjust the XYZ homing of a machine in
the eeprom.  So as the second stage of this, make the M206 home offset
parameters subject to the M500/M501/M502/M503 eeprom commands.

Bump the eeprom version to "V06".

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

HOMEAXIS: make into a function

Replace the large macro HOMEAXIS with a function.  This avoids the
compiler generating three copies of largely identical code.  The
saving is 724 bytes of program memory.

We make use of XYZ_CONSTS_FROM_CONFIG to provide convenient
array-shaped access to MAX_LENGTH, HOME_RETRACT_MM and HOME_DIR.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

eeprom: provide smaller code for SERIAL_ECHOPAIR

SERIAL_ECHOPAIR implies, eventually, two calls to MYSERIAL.print.  One
of these has FORCE_INLINE for a per-character loop, and both involve
constructing a method call rather than a simple function call.

Produce better and smaller code by providing three specialised
functions serial_echopair.  This saves 672 bytes of program memory
(with EEPROM_SETTINGS and SDSUPPORT enabled).

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

Merge branch 'for-upstream-ff' into iwj

update from for-upstream (merge -s theirs)

M206: save values in eeprom

Really, we should have a way to adjust the XYZ homing of a machine in
the eeprom.  So as the second stage of this, make the M206 home offset
parameters subject to the M500/M501/M502/M503 eeprom commands.

Bump the eeprom version to "V06".

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

HOMEAXIS: make into a function

Replace the large macro HOMEAXIS with a function.  This avoids the
compiler generating three copies of largely identical code.  The
saving is 724 bytes of program memory.

We make use of XYZ_CONSTS_FROM_CONFIG to provide convenient
array-shaped access to MAX_LENGTH, HOME_RETRACT_MM and HOME_DIR.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

eeprom: provide smaller code for SERIAL_ECHOPAIR

SERIAL_ECHOPAIR implies, eventually, two calls to MYSERIAL.print.  One
of these has FORCE_INLINE for a per-character loop, and both involve
constructing a method call rather than a simple function call.

Produce better and smaller code by providing three specialised
functions serial_echopair.  This saves 672 bytes of program memory
(with EEPROM_SETTINGS and SDSUPPORT enabled).

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

M206: always use homing ("homeing") offsets

Previously the parameters set in M206 would only be used if a G82
command was sent with specific axis home values.  This limits its
usefulness.

Really, we should have a way to adjust the XYZ homing of a machine in
the eeprom.  So as the first stage of this, make M206 affect every
home command.  The values set using M206 are now added to the
configuration variables [XYZ]_HOME_POS.

This is achieved by replacing all uses of [XYZ]_HOME_POS in the code
by a new home_pos[] which includes the adjustment.  We also have to
adjust the uses of [XYZ]_{MIN,MAX}_POS similarly - see below.

To allow axis_is_at_home to be written as a function taking an axis
index rather than a macro taking an axis letter, we provide
constant arrays in program memory containing the values of
[XYZ]_{MIN,MAX,HOME}_POS from the compiled-in configuration.

This is done with some helper macros to deal with the declaration
(XYZ_CONSTS_FROM_CONFIG) and definition of the inline function which
does the program memory access.

We also introduce the overloaded function read_pgm_any, whose
instances are produced with DEFINE_PGM_READ_ANY, which allows the
access functions to automatically produce the correct type.

The type- and pointer-massaging code in the access function boils
down, when compiled, to a simple program memory access.

A question arises: if the M206 offset is set, should this adjustment
to the home position shift or change the possible range of movement
permitted by the software endstops ?

The documentation in Configuration.h describes these limits as:
    // Travel limits after homing
Since this is a file containing physical limits, and actual suggested
values for these configuration parameters appear to include a certain
amount of slop, I've taken the view that these should be regarded as
nominal physical distances from the limit switches, and that the
permissible travel should be unaffected by M206.

So for example with the (rather unrealistic)
  #define X_HOME_DIR -1
  #define X_MIN_POS -20
  #define X_HOME_POS 0
  #define X_MAX_POS 100
no matter the setting of M206 X, the machine would be permitted
to move from 20mm "beyond" the limit switch trigger point in
the negative X direction and 100mm away from the limit switch in
the positive X direction, for a total travel of 120mm.

With M206 X-10 that would be considered to correspond to X coordinates
-30 to +90.  With M206 X+10 that would be considered to correspond to
X coordinates -10 to +110.

fixes #200 (in ErikZalm/Marlin).

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

M206: always use homing ("homeing") offsets

Previously the parameters set in M206 would only be used if a G82
command was sent with specific axis home values.  This limits its
usefulness.

Really, we should have a way to adjust the XYZ homing of a machine in
the eeprom.  So as the first stage of this, make M206 affect every
home command.  The values set using M206 are now added to the
configuration variables [XYZ]_HOME_POS.

This is achieved by replacing all uses of [XYZ]_HOME_POS in the code
by a new home_pos[] which includes the adjustment.  We also have to
adjust the uses of [XYZ]_{MIN,MAX}_POS similarly - see below.

To allow axis_is_at_home to be written as a function taking an axis
index rather than a macro taking an axis letter, we provide
constant arrays in program memory containing the values of
[XYZ]_{MIN,MAX,HOME}_POS from the compiled-in configuration.

This is done with some helper macros to deal with the declaration
(XYZ_CONSTS_FROM_CONFIG) and definition of the inline function which
does the program memory access.

We also introduce the overloaded function read_pgm_any, whose
instances are produced with DEFINE_PGM_READ_ANY, which allows the
access functions to automatically produce the correct type.

The type- and pointer-massaging code in the access function boils
down, when compiled, to a simple program memory access.

A question arises: if the M206 offset is set, should this adjustment
to the home position shift or change the possible range of movement
permitted by the software endstops ?

The documentation in Configuration.h describes these limits as:
    // Travel limits after homing
Since this is a file containing physical limits, and actual suggested
values for these configuration parameters appear to include a certain
amount of slop, I've taken the view that these should be regarded as
nominal physical distances from the limit switches, and that the
permissible travel should be unaffected by M206.

So for example with the (rather unrealistic)
  #define X_HOME_DIR -1
  #define X_MIN_POS -20
  #define X_HOME_POS 0
  #define X_MAX_POS 100
no matter the setting of M206 X, the machine would be permitted
to move from 20mm "beyond" the limit switch trigger point in
the negative X direction and 100mm away from the limit switch in
the positive X direction, for a total travel of 120mm.

With M206 X-10 that would be considered to correspond to X coordinates
-30 to +90.  With M206 X+10 that would be considered to correspond to
X coordinates -10 to +110.

fixes #200 (in ErikZalm/Marlin).

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

Merge branch 'for-upstream-ff' into iwj

update from for-upstream (merge -s theirs)

software_endstops: use *_MIN_POS and *_MAX_POS for arcs

If [XYZ]_HOME_POS and [XYZ]_MIN_POS aren't 0, these corrections are
wrong.  Use the same logic as in Marlin.pde:prepare_move: ie, clamp to
[XYZ]_{MIN,MAX}_POS.

While we're here, put this cut-and-paste code in a function
clamp_to_software_endstops.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

M206: save values in eeprom

Really, we should have a way to adjust the XYZ homing of a machine in
the eeprom.  So as the second stage of this, make the M206 home offset
parameters subject to the M500/M501/M502/M503 eeprom commands.

Bump the eeprom version to "V06".

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

Makefile: Better display of size (device memory usage)

Run avr-size with the --mcu=... -C option as well.  That reports how
much actual device program and data memory is used along with a
percentage fullness.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

HOMEAXIS: make into a function

Replace the large macro HOMEAXIS with a function.  This avoids the
compiler generating three copies of largely identical code.  The
saving is 724 bytes of program memory.

We make use of XYZ_CONSTS_FROM_CONFIG to provide convenient
array-shaped access to MAX_LENGTH, HOME_RETRACT_MM and HOME_DIR.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

eeprom: provide smaller code for SERIAL_ECHOPAIR

SERIAL_ECHOPAIR implies, eventually, two calls to MYSERIAL.print.  One
of these has FORCE_INLINE for a per-character loop, and both involve
constructing a method call rather than a simple function call.

Produce better and smaller code by providing three specialised
functions serial_echopair.  This saves 672 bytes of program memory
(with EEPROM_SETTINGS and SDSUPPORT enabled).

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

M206: always use homing ("homeing") offsets

Previously the parameters set in M206 would only be used if a G82
command was sent with specific axis home values.  This limits its
usefulness.

Really, we should have a way to adjust the XYZ homing of a machine in
the eeprom.  So as the first stage of this, make M206 affect every
home command.  The values set using M206 are now added to the
configuration variables [XYZ]_HOME_POS.

This is achieved by replacing all uses of [XYZ]_HOME_POS in the code
by a new home_pos[] which includes the adjustment.  We also have to
adjust the uses of [XYZ]_{MIN,MAX}_POS similarly - see below.

To allow axis_is_at_home to be written as a function taking an axis
index rather than a macro taking an axis letter, we provide
constant arrays in program memory containing the values of
[XYZ]_{MIN,MAX,HOME}_POS from the compiled-in configuration.

This is done with some helper macros to deal with the declaration
(XYZ_CONSTS_FROM_CONFIG) and definition of the inline function which
does the program memory access.

We also introduce the overloaded function read_pgm_any, whose
instances are produced with DEFINE_PGM_READ_ANY, which allows the
access functions to automatically produce the correct type.

The type- and pointer-massaging code in the access function boils
down, when compiled, to a simple program memory access.

A question arises: if the M206 offset is set, should this adjustment
to the home position shift or change the possible range of movement
permitted by the software endstops ?

The documentation in Configuration.h describes these limits as:
    // Travel limits after homing
Since this is a file containing physical limits, and actual suggested
values for these configuration parameters appear to include a certain
amount of slop, I've taken the view that these should be regarded as
nominal physical distances from the limit switches, and that the
permissible travel should be unaffected by M206.

So for example with the (rather unrealistic)
  #define X_HOME_DIR -1
  #define X_MIN_POS -20
  #define X_HOME_POS 0
  #define X_MAX_POS 100
no matter the setting of M206 X, the machine would be permitted
to move from 20mm "beyond" the limit switch trigger point in
the negative X direction and 100mm away from the limit switch in
the positive X direction, for a total travel of 120mm.

With M206 X-10 that would be considered to correspond to X coordinates
-30 to +90.  With M206 X+10 that would be considered to correspond to
X coordinates -10 to +110.

fixes #200 (in ErikZalm/Marlin).

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

software_endstops: use *_MIN_POS and *_MAX_POS for arcs

If [XYZ]_HOME_POS and [XYZ]_MIN_POS aren't 0, these corrections are
wrong.  Use the same logic as in Marlin.pde:prepare_move: ie, clamp to
[XYZ]_{MIN,MAX}_POS.

While we're here, put this cut-and-paste code in a function
clamp_to_software_endstops.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

Makefile: support V=1

Often it can be useful to see the actual commands being run by make.
Other projects (eg, the Linux kernel) support this with a "V=1" make
parameter.  Do the same here.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

.gitignore: Add *~, *.orig, *.rej, move to root directory

Move the .gitignore out of the Marlin subdirectory so it applies to
the whole tree, and add some missing patterns.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

Marlin.pde: include comment for emacs mode

Emacs by default doesn't recognise a ".pde" file as C++ source code.
Add the annotation to the top of the file to make it work.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

adjust Z software endstop downwards

Remove the reprappro config file

Merge branch 'for-upstream-ff' into iwj

update from for-upstream (merge -s theirs)

M206: save values in eeprom

Really, we should have a way to adjust the XYZ homing of a machine in
the eeprom.  So as the second stage of this, make the M206 home offset
parameters subject to the M500/M501/M502/M503 eeprom commands.

Bump the eeprom version to "V06".

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

HOMEAXIS: make into a function

Replace the large macro HOMEAXIS with a function.  This avoids the
compiler generating three copies of largely identical code.  The
saving is 724 bytes of program memory.

We make use of XYZ_CONSTS_FROM_CONFIG to provide convenient
array-shaped access to MAX_LENGTH, HOME_RETRACT_MM and HOME_DIR.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

eeprom: provide smaller code for SERIAL_ECHOPAIR

SERIAL_ECHOPAIR implies, eventually, two calls to MYSERIAL.print.  One
of these has FORCE_INLINE for a per-character loop, and both involve
constructing a method call rather than a simple function call.

Produce better and smaller code by providing three specialised
functions serial_echopair.  This saves 672 bytes of program memory
(with EEPROM_SETTINGS and SDSUPPORT enabled).

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

M206: always use homing ("homeing") offsets

Previously the parameters set in M206 would only be used if a G82
command was sent with specific axis home values.  This limits its
usefulness.

Really, we should have a way to adjust the XYZ homing of a machine in
the eeprom.  So as the first stage of this, make M206 affect every
home command.  The values set using M206 are now added to the
configuration variables [XYZ]_HOME_POS.

This is achieved by replacing all uses of [XYZ]_HOME_POS in the code
by a new home_pos[] which includes the adjustment.  We also have to
adjust the uses of [XYZ]_{MIN,MAX}_POS similarly - see below.

To allow axis_is_at_home to be written as a function taking an axis
index rather than a macro taking an axis letter, we provide
constant arrays in program memory containing the values of
[XYZ]_{MIN,MAX,HOME}_POS from the compiled-in configuration.

This is done with some helper macros to deal with the declaration
(XYZ_CONSTS_FROM_CONFIG) and definition of the inline function which
does the program memory access.

We also introduce the overloaded function read_pgm_any, whose
instances are produced with DEFINE_PGM_READ_ANY, which allows the
access functions to automatically produce the correct type.

The type- and pointer-massaging code in the access function boils
down, when compiled, to a simple program memory access.

A question arises: if the M206 offset is set, should this adjustment
to the home position shift or change the possible range of movement
permitted by the software endstops ?

The documentation in Configuration.h describes these limits as:
    // Travel limits after homing
Since this is a file containing physical limits, and actual suggested
values for these configuration parameters appear to include a certain
amount of slop, I've taken the view that these should be regarded as
nominal physical distances from the limit switches, and that the
permissible travel should be unaffected by M206.

So for example with the (rather unrealistic)
  #define X_HOME_DIR -1
  #define X_MIN_POS -20
  #define X_HOME_POS 0
  #define X_MAX_POS 100
no matter the setting of M206 X, the machine would be permitted
to move from 20mm "beyond" the limit switch trigger point in
the negative X direction and 100mm away from the limit switch in
the positive X direction, for a total travel of 120mm.

With M206 X-10 that would be considered to correspond to X coordinates
-30 to +90.  With M206 X+10 that would be considered to correspond to
X coordinates -10 to +110.

fixes #200 (in ErikZalm/Marlin).

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

software_endstops: use *_MIN_POS and *_MAX_POS for arcs

If [XYZ]_HOME_POS and [XYZ]_MIN_POS aren't 0, these corrections are
wrong.  Use the same logic as in Marlin.pde:prepare_move: ie, clamp to
[XYZ]_{MIN,MAX}_POS.

While we're here, put this cut-and-paste code in a function
clamp_to_software_endstops.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

Merge branch 'for-upstream-ff' into iwj

Conflicts:
Marlin/EEPROMwrite.h
Marlin/Marlin.h
Marlin/Marlin.pde
Marlin/motion_control.cpp

update from for-upstream (merge -s theirs)

M206: save values in eeprom

Really, we should have a way to adjust the XYZ homing of a machine in
the eeprom.  So as the second stage of this, make the M206 home offset
parameters subject to the M500/M501/M502/M503 eeprom commands.

Bump the eeprom version to "V06".

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

HOMEAXIS: make into a function

Replace the large macro HOMEAXIS with a function.  This avoids the
compiler generating three copies of largely identical code.  The
saving is 704 bytes of program memory.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

update from for-upstream (merge -s theirs)

eeprom: provide smaller code for SERIAL_ECHOPAIR

SERIAL_ECHOPAIR implies, eventually, two calls to MYSERIAL.print.  One
of these has FORCE_INLINE for a per-character loop, and both involve
constructing a method call rather than a simple function call.

Produce better and smaller code by providing three specialised
functions serial_echopair.  This saves 672 bytes of program memory
(with EEPROM_SETTINGS and SDSUPPORT enabled).

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

HOMEAXIS: make into a function

Replace the large macro HOMEAXIS with a function.  This avoids the
compiler generating three copies of largely identical code.  The
saving is 704 bytes of program memory.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

M206: save values in eeprom

Really, we should have a way to adjust the XYZ homing of a machine in
the eeprom.  So as the second stage of this, make the M206 home offset
parameters subject to the M500/M501/M502/M503 eeprom commands.

Bump the eeprom version to "V06".

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

update from for-upstream (merge -s theirs)

Makefile: Better display of size (device memory usage)

Run avr-size with the --mcu=... -C option as well.  That reports how
much actual device program and data memory is used along with a
percentage fullness.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

M206: always use homing ("homeing") offsets

Previously the parameters set in M206 would only be used if a G82
command was sent with specific axis home values.  This limits its
usefulness.

Really, we should have a way to adjust the XYZ homing of a machine in
the eeprom.  So as the first stage of this, make M206 affect every
home command.  The values set using M206 are now added to the
configuration variables [XYZ]_HOME_POS.

This is achieved by replacing all uses of [XYZ]_HOME_POS in the code
by [XYZ]_HOME_POS_A which is a macro which includes the adjustment.

A question arises: if the M206 offset is set, should this adjustment
to the home position shift or change the possible range of movement
permitted by the software endstops ?

The documentation in Configuration.h describes these limits as:
    // Travel limits after homing
Since this is a file containing physical limits, and actual suggested
values for these configuration parameters appear to include a certain
amount of slop, I've taken the view that these should be regarded as
nominal physical distances from the limit switches, and that the
permissible travel should be unaffected by M206.

So for example with the (rather unrealistic)
  #define X_HOME_DIR -1
  #define X_MIN_POS -20
  #define X_HOME_POS 0
  #define X_MAX_POS 100
no matter the setting of M206 X, the machine would be permitted
to move from 20mm "beyond" the limit switch trigger point in
the negative X direction and 100mm away from the limit switch in
the positive X direction, for a total travel of 120mm.

With M206 X-10 that would be considered to correspond to X coordinates
-30 to +90.  With M206 X+10 that would be considered to correspond to
X coordinates -10 to +110.

fixes #200 (in ErikZalm/Marlin).

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

HOMEAXIS: make into a function

Replace the large macro HOMEAXIS with a function.  This avoids the
compiler generating three copies of largely identical code.  The
saving is 704 bytes of program memory.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

Makefile: support V=1

Often it can be useful to see the actual commands being run by make.
Other projects (eg, the Linux kernel) support this with a "V=1" make
parameter.  Do the same here.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

software_endstops: use *_MIN_POS and *_MAX_POS for arcs

If [XYZ]_HOME_POS and [XYZ]_MIN_POS aren't 0, these corrections are
wrong.  Use the same logic as in Marlin.pde:prepare_move: ie, clamp to
[XYZ]_{MIN,MAX}_POS.

While we're here, put this cut-and-paste code in a function
clamp_to_software_endstops.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

M206: save values in eeprom

Really, we should have a way to adjust the XYZ homing of a machine in
the eeprom.  So as the second stage of this, make the M206 home offset
parameters subject to the M500/M501/M502/M503 eeprom commands.

Bump the eeprom version to "V06".

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

.gitignore: Add *~, *.orig, *.rej, move to root directory

Move the .gitignore out of the Marlin subdirectory so it applies to
the whole tree, and add some missing patterns.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

Makefile: Better size printing

Run avr-size with the --mcu=... -C option as well.  That reports how
much actual device program and data memory is used along with a
percentage fullness.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

eeprom: provide smaller code for SERIAL_ECHOPAIR

SERIAL_ECHOPAIR implies, eventually, two calls to MYSERIAL.print.  One
of these has FORCE_INLINE for a per-character loop, and both involve
constructing a method call rather than a simple function call.

Produce better and smaller code by providing three specialised
functions serial_echopair.  This saves 672 bytes of program memory
(with EEPROM_SETTINGS and SDSUPPORT enabled).

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

Marlin.pde: include comment for emacs mode

Emacs by default doesn't recognise a ".pde" file as C++ source code.
Add the annotation to the top of the file to make it work.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

M206: always use homing ("homeing") offsets

Previously the parameters set in M206 would only be used if a G82
command was sent with specific axis home values.  This limits its
usefulness.

Really, we should have a way to adjust the XYZ homing of a machine in
the eeprom.  So as the first stage of this, make M206 affect every
home command.  The values set using M206 are now added to the
configuration variables [XYZ]_HOME_POS.

This is achieved by replacing all uses of [XYZ]_HOME_POS in the code
by [XYZ]_HOME_POS_A which is a macro which includes the adjustment.

A question arises: if the M206 offset is set, should this adjustment
to the home position shift or change the possible range of movement
permitted by the software endstops ?

I have taken the view that the software endstops are a backstop safety
feature which is not necessarily entirely accurate, and that reducing
the scope of movement, at either end, is not desirable.  I have
therefore arranged that nonzero values for M206 increase the total
range of movement.

So for example with
  #define X_MIN_POS 0
  #define X_HOME_POS 0
  #define X_MAX_POS 100

M206 X-10 would permit the machine to move from the endstop
(considered X=-10) 110mm in the positive X direction (considered
X=+100).

M206 X+10 would permit the machine to move from the endstop
(considered X=-10) 110mm in the positive X direction (considered
X=+110).

fixes #200 (in ErikZalm/Marlin).

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

undo broken for-upstream change by stgit

update from for-upstream (merge -s theirs)

HOMEAXIS: make into a function

Replace the large macro HOMEAXIS with a function.  This avoids the
compiler generating three copies of largely identical code.  The
saving is 714 bytes of program memory.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

M206: save values in eeprom

Really, we should have a way to adjust the XYZ homing of a machine in
the eeprom.  So as the second stage of this, make the M206 home offset
parameters subject to the M500/M501/M502/M503 eeprom commands.

Bump the eeprom version to "V06".

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

eeprom: provide smaller code for SERIAL_ECHOPAIR

SERIAL_ECHOPAIR implies, eventually, two calls to MYSERIAL.print.  One
of these has FORCE_INLINE for a per-character loop, and both involve
constructing a method call rather than a simple function call.

Produce better and smaller code by providing three specialised
functions serial_echopair.  This saves 672 bytes of program memory
(with EEPROM_SETTINGS and SDSUPPORT enabled).

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

M206: always use homing ("homeing") offsets

Previously the parameters set in M206 would only be used if a G82
command was sent with specific axis home values.  This limits its
usefulness.

Really, we should have a way to adjust the XYZ homing of a machine in
the eeprom.  So as the first stage of this, make M206 affect every
home command.  The values set using M206 are now added to the
configuration variables [XYZ]_HOME_POS.

This is achieved by replacing all uses of [XYZ]_HOME_POS in the code
by [XYZ]_HOME_POS_A which is a macro which includes the adjustment.

A question arises: if the M206 offset is set, should this adjustment
to the home position shift or change the possible range of movement
permitted by the software endstops ?

I have taken the view that the software endstops are a backstop safety
feature which is not necessarily entirely accurate, and that reducing
the scope of movement is not desirable.

I have therefore implemented it so that negative values for M206
increase the total range of movement, whereas positive values leave it
unchanged.

So for example with
  #define X_MIN_POS 0
  #define X_HOME_POS 0
  #define X_MAX_POS 100

M206 X-10 would permit the machine to move from the endstop
(considered X=-10) 110mm in the positive X direction (considered
X=+100).

M206 X+10 would permit the machine to move from the endstop
(considered X=-10) 100mm in the positive X direction (considered
X=+110).

fixes #200 (in ErikZalm/Marlin).

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

Makefile: support V=1

Often it can be useful to see the actual commands being run by make.
Other projects (eg, the Linux kernel) support this with a "V=1" make
parameter.  Do the same here.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

Add *~ to Marlin/.gitignore

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

update from for-upstream (merge -s theirs)

Add *~ to Marlin/.gitignore

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

Marlin.pde: include comment for emacs mode

Emacs by default doesn't recognise a ".pde" file as C++ source code.
Add the annotation to the top of the file to make it work.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

HOMEAXIS: make into a function

Replace the large macro HOMEAXIS with a function.  This avoids the
compiler generating three copies of largely identical code.  The
saving is 714 bytes of program memory.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

M206: save values in eeprom

Really, we should have a way to adjust the XYZ homing of a machine in
the eeprom.  So as the second stage of this, make the M206 home offset
parameters subject to the M500/M501/M502/M503 eeprom commands.

Bump the eeprom version to "V06".

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

eeprom: provide smaller code for SERIAL_ECHOPAIR

SERIAL_ECHOPAIR implies, eventually, two calls to MYSERIAL.print.  One
of these has FORCE_INLINE for a per-character loop, and both involve
constructing a method call rather than a simple function call.

Produce better and smaller code by providing three specialised
functions serial_echopair.  This saves 672 bytes of program memory
(with EEPROM_SETTINGS and SDSUPPORT enabled).

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

M206: always use homing ("homeing") offsets

Previously the parameters set in M206 would only be used if a G82
command was sent with specific axis home values.  This limits its
usefulness.

Really, we should have a way to adjust the XYZ homing of a machine in
the eeprom.  So as the first stage of this, make M206 affect every
home command.  The values set using M206 are now added to the
configuration variables [XYZ]_HOME_POS.

This is achieved by replacing all uses of [XYZ]_HOME_POS in the code
by [XYZ]_HOME_POS_A which is a macro which includes the adjustment.

fixes #200 (in ErikZalm/Marlin).

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
minimums too

FIXME FIXME FIXME

Makefile: support V=1

Often it can be useful to see the actual commands being run by make.
Other projects (eg, the Linux kernel) support this with a "V=1" make
parameter.  Do the same here.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

ENABLE EEPROM SETTINGS AND SDSUPPORT NOT FOR UPSTREAM

minimums too

homeing fixes

M206: save values in eeprom

Really, we should have a way to adjust the XYZ homing of a machine in
the eeprom.  So as the second stage of this, make the M206 home offset
parameters subject to the M500/M501/M502/M503 eeprom commands.

Bump the eeprom version to "V06".

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

echopair double thing

Revert "M206: save values in eeprom"

This reverts commit ea54e71397799c16cde4f6d55d57195aea439ce9.

Merge branch 'for-upstream-ff' into iwj

update from ref for-upstream (merge -s theirs)

M206: save values in eeprom

Really, we should have a way to adjust the XYZ homing of a machine in
the eeprom.  So as the second stage of this, make the M206 home offset
parameters subject to the M500/M501/M502/M503 eeprom commands.

Bump the eeprom version to "V06".

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

M206: always use homing ("homeing") offsets

Previously the parameters set in M206 would only be used if a G82
command was sent with specific axis home values.  This limits its
usefulness.

Really, we should have a way to adjust the XYZ homing of a machine in
the eeprom.  So as the first stage of this, make M206 affect every
home command.  The values set using M206 are now added to the
configuration variables [XYZ]_HOME_POS.

This is achieved by replacing all uses of [XYZ]_HOME_POS in the code
by [XYZ]_HOME_POS_A which is a macro which includes the adjustment.

fixes #200 (in ErikZalm/Marlin).

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

Merge branch 'for-upstream-ff' into iwj

Merge branch 'for-upstream-ff' into for-upstream

Makefile: support V=1

Often it can be useful to see the actual commands being run by make.
Other projects (eg, the Linux kernel) support this with a "V=1" make
parameter.  Do the same here.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

M206: save values in eeprom

Really, we should have a way to adjust the XYZ homing of a machine in
the eeprom.  So as the second stage of this, make the M206 home offset
parameters subject to the M500/M501/M502/M503 eeprom commands.

Bump the eeprom version to "V06".

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

M206: always use homing ("homeing") offsets

Previously the parameters set in M206 would only be used if a G82
command was sent with specific axis home values.  This limits its
usefulness.

Really, we should have a way to adjust the XYZ homing of a machine in
the eeprom.  So as the first stage of this, make M206 affect every
home command.  The values set using M206 are now added to the
configuration variables [XYZ]_HOME_POS.

This is achieved by replacing all uses of [XYZ]_HOME_POS in the code
by [XYZ]_HOME_POS_A which is a macro which includes the adjustment.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

Merge branch 'for-upstream-ff' into iwj

Makefile: support V=1

Often it can be useful to see the actual commands being run by make.
Other projects (eg, the Linux kernel) support this with a "V=1" make
parameter.  Do the same here.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

M206: save values in eeprom

Really, we should have a way to adjust the XYZ homing of a machine in
the eeprom.  So as the second stage of this, make the M206 home offset
parameters subject to the M500/M501/M502/M503 eeprom commands.

Bump the eeprom version to "V06".

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

M206: always use homing ("homeing") offsets

Previously the parameters set in M206 would only be used if a G82
command was sent with specific axis home values.  This limits its
usefulness.

Really, we should have a way to adjust the XYZ homing of a machine in
the eeprom.  So as the first stage of this, make M206 affect every
home command.  The values set using M206 are now added to the
configuration variables [XYZ]_HOME_POS.

This is achieved by replacing all uses of [XYZ]_HOME_POS in the code
by [XYZ]_HOME_POS_A which is a macro which includes the adjustment.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

Revert "remove annoying @s from Makefile"

before redo with V=

This reverts commit acb82c90e5a1d3168847371cb91e38d69ea072b3.

M206: save values in eeprom

Really, we should have a way to adjust the XYZ homing of a machine in
the eeprom.  So as the second stage of this, make the M206 home offset
parameters subject to the M500/M501/M502/M503 eeprom commands.

Bump the eeprom version to "V06".

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

M206: always use homing ("homeing") offsets

Previously the parameters set in M206 would only be used if a G82
command was sent with specific axis home values.  This limits its
usefulness.

Really, we should have a way to adjust the XYZ homing of a machine in
the eeprom.  So as the first stage of this, make M206 affect every
home command.  The values set using M206 are now added to the
configuration variables [XYZ]_HOME_POS.

This is achieved by replacing all uses of [XYZ]_HOME_POS in the code
by [XYZ]_HOME_POS_A which is a macro which includes the adjustment.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

config fix - enable eeprom support

update date

fix bed pin and thermistor etc, now it works

remove annoying @s from Makefile

config fixes
 - 115200 baud since zealot won't do 250000
 - thermistors set to boring 1 and 2, a la
    sprinter-reprappro.git#aec04de807fe6d84315096477674a1eccc959aee
    Sprinter_Sanguinololu/Configuration.h
 - enable SD support

Revert "get temp tables from "RepRapPro-Huxley-July-2012" ie c33ed4dcb852815f16f0ebb7dd9433e4d7d78590"

these are bollocks; the table 102 which we were using for hot end
sensor is not even monotonic

This reverts commit 0b3d4364b7b52efda6fb492f91aca92da70c6d19.

get temp tables from "RepRapPro-Huxley-July-2012" ie c33ed4dcb852815f16f0ebb7dd9433e4d7d78590

settings

Fixed soft limits when the origin is in the middle.
HOME_POS is now always where the endstop is and can be outside the limits.
The limits are now defined by MIN_POS and MAX_POS rather than HOME_POS and MAX_LENGTH.
The Z is axis now homed first if direction is away from the bed.

Saguinololu limit pins change from MIN to MAX according to the homing direction.