Pushed minor changes. Thanks @Protoneer!
G-code updates for G10 L2 and L20.

- LinuxCNC's g-code definitions changed for G10. Updated to their
descriptions.
Untested! Soft limits, max travel, homing changes, new settings.

- WARNING: Completely untested. Will later when there is time. Settings
WILL be overwritten, as there are new settings.

- Soft limits installed. Homing must be enabled for soft limits to work
correctly. Errors out much like a hard limit, locking out everything
and bringing up the alarm mode. Only difference is it forces a feed
hold before doing so. Position is not lost.

- IMPORTANT: Homing had to be updated so that soft limits work better
with less CPU overhead. When homing completes, all axes are assumed to
exist in negative space. If your limit switch is other side, the homing
cycle with set this axis location to the max travel value, rather than
zero.

- Update mc_line() to accept an array, rather than individual variables.

- Added an mc_auto_cycle_start() function handle this feature.
Organization only.

-
Update README.md
Minor updates to code and commenting.
Updates to edge/dev. Line buffer increased/planner buffer decreased. Line overflow feedback.

- Increased g-code parser line buffer to 70 characters (from 50) to
prevent some long arc commands from getting truncated.

- Decreased planner buffer from 18 to 17 blocks to free up memory for
line buffer.

- Added a line buffer overflow feedback error (Thanks @BHSPitMonkey!)
Push old dev_2 draft to work on other things.

- **NON-FUNCTIONAL**
- Contains an old draft of separating the stepper driver direct access
to the planner buffer. This is designed to keep the stepper and planner
modules independent and prevent overwriting or other complications. In
this way, feedrate override should be able to be installed as well.
- A number of planner optimizations are installed too.
- Not sure where the bugs are. Either in the new planner optimizations,
new stepper module updates, or in both. Or it just could be that the
Arduino AVR is choking with the new things it has to do.
Protected buffer works! Vast improvements to planner efficiency.  Many things still broken with overhaul.

Development push. Lots still broken.

- Protected planner concept works! This is a critical precursor to
enabling feedrate overrides in allowing the planner buffer and the
stepper execution operate atomically. This is done through a
intermediary segment buffer.

- Still lots of work to be done, as this was a complete overhaul of the
planner and stepper subsystems. The code can be cleaned up quite a bit,
re-enabling some of the broken features like feed holds, and finishing
up some of the concepts

- Pushed some of the fixes from the master and edge branch to here, as
this will likely replace the edge branch when done.
New stepper subsystem bug fixes.

- New stepper algorithm with the new optimized planner seems to be
working nearly twice as fast as the previous algorithm.

- For one, the planner computation overhead is probably a fraction of
what it used to be with the worst case being about half still.

- Secondly, anytime the planner plans back to the first executing
block, it no longer overwrites the block conditions and allows it to
complete without lost steps. So no matter if the streams slows, the
protected planner should keep the steppers moving without risk of lost
steps (although this still needs to be tested thoroughly and may
audibly sound weird when this happens.)

- It now seems that the bottleneck is the serial baudrate (which is
good!)
Fine tuning of new stepper algorithm with protected planner. Adaptive step prediction for segment buffer.

- Cleaned up the new stepper algorithm code with more commenting and
better logic flow.

- The new segment buffer now predicts the number of steps each segment
should have to execute over about 8 milliseconds each (based on the
ACCELERATION_TICKS_PER_SECOND setting). So, for when the whole segment
buffer is full, the stepper algorithm has roughly 40 milliseconds of
steps queued before it needs to refilled by the main program.

- Readjusted the max supported step rate back to 30kHz from the lower
development 20kHz. Everything still works amazing great and the test
CNC machine still runs twice as fast with the new stepper algorithm and
planner.

- Upped the standard serial baudrate to 115200 baud, as it is clear
that the bottleneck is the serial interface. Will now support this, as
well as the old 9600 baud, in new firmware builds.
Cleaned up stepper and planner code.

- Added some compile-time error checking. Will add more in future
pushes to ensure settings are correct and within parameters that won't
break anything.

- Pushed some master branch changes with MEGA pin settings.

- Cleaned up planner code and comments to clarify some of the new
changes. Still much to do here.

- Cleaned up the new stepper code. May need to abstract some of the
segment buffer more to fix the feed holds (and integrate homing into
the main stepper routine). With what's planned, this should make the
stepper algorithm easier to attach other types of processes to it,
where it is now tightly integrated with the planner buffer and nothing
else.
Updated comments. Changed stepper variable names to be more understandable. Added step locking note.

- Updated config comments and stepper code comments for the new changes.

- Changed stepper algorithm variable names to be more understandable in
what they actually do.

- Added a stepper lock note in default.h per user request.

- Started some code layout in handling feed holds and refactoring the
homing routine to use the main stepper algorithm instead of a seperate
version.
Planner function call fix. More clean up.
Merge branch 'dev_2' into dev

Conflicts:
	README.md
	gcode.c
	motion_control.c
	planner.c
	planner.h
	protocol.c
	report.c
	settings.c
	settings.h
	stepper.c
	stepper.h