0.16.2:
- Add comments to example RawAccessWithPause (renamed from RawAccessWithDelay)
- addQueueEntry() expects now a const pointer instead of just a pointer
- Rework RawAccess example and test on hw

0.16.1:
- Usage example in readme has not worked due to a bug in the auto enable/disable variable setting.
  => Added the UsageExample under examples

0.16.0:
- disableOutputs() returns boolean success value
- The external enable output routine will be called regularly in case of disable, too
- esp32: fixed loss of pauses in command queue due to pcnt/mcpwm timer interaction.
   This caused V4100 being faster than V4000, even so it should be slower
- ramp generator: fix for high accelerations to have stop command effective

0.15.2:
- Assume for now, that atmega328 and ATmega2560 uses always same pins for OC1A and OC1B

0.15.1:
- Remove the check for specific avr board. This assumes, that all avr boards
  uses Pin 9 and Pin 10 for OC1A and OC1B respectively

0.15.0:
- For the commands in the queue, the minimum time in ticks to execute
  a command is limited to 10*MIN_DELTA_TICKS. For esp32 this relates to
  the time between interrupts of one channel
- AQE_ERROR_TICKS_TOO_HIGH removed, because it is already limited by the data type uint16_t
- esp32: Change from mcpwm up count mode to up-down count mode
- avr: adjust implementation to esp32: pulse at start of ticks period of a command
- merge pull request from ixil see (https://github.com/gin66/FastAccelStepper/pull/19)

0.14.0:
- Direction pins can be shared by several steppers
- enableOutputs() returns bool to indicate, output was enabled
- Possibility to supply external enable output control
- AddQueueEntry() return values changed: >0 => retry again, <0 => error
- ATmega2560: Allow to change the used timer module with preprocesser variable FAS_TIMER_MODULE

0.13.4:
- Automated github test identified a compile error introduced in 0.13.3

0.13.3:
- esp32: Cyclic rate increased from 10ms to 4ms.
	With a planning ahead time of 10ms, there was the risk
	of running out of commands as identified in issue #18

0.13.2:
- StepperDemo: Compact output for stopped motor
- Fixed a bug, where stepper 4-6 misconfigured stepper 1-3 pcnt.
	=> stepper 4-6 had erroneous behavior for speed <500us
    => stepper 1-3 could in trouble, if corresponding stepper 4-6 was running

0.13.1:
- try a mechanism to include application defined config file
- StepperDemo: for avr move messages into program code to reduce RAM usage

0.13.0:
- Support ATmega2560 for three steppers linked to timer 4 (currently hardcoded)

0.12.2:
- StepperDemo modification:
    - Enable direct drive feature in StepperDemo for esp32
    - While direct driving, check if the signals can be applied
    - Add test mode (enter with t). Here can select stepper, a test sequence and run it
    - In total four test sequences implemented until now
- Add detachFromPin() and reattachToPin() to the API. Shouldn't be used from an application.

0.12.1:
- implement runForward()/runBackward()
- avr: fix interrupt for direction change
- StepperDemo modification:
    - r: Call ESP.restart() to check for issue #6

0.12.0:
- reduce data type for command queue entries' ticks value from uint32_t to uint16_t
   => remove ABS_MAX_AQE_TICKS
- each command in queue can now emit up to 255 steps
- StepperDemo modification:
    - r: Call ESP.restart() to check for issue #6
    - Disable direct drive for esp32
- AutoEnable-Pin can be shared by steppers
- avr: fix interrupt for direction change

0.11.3:
- ABSOLUTE_MAX_AQE_TICKS is now 65535

0.11.2:
- auto enable on delay implemented by filling the queue with pause
  This allows approx. 60/120 ms delay for avr/esp32
- esp32: two motors in parallel could lead to uncontrolled running steppers.
         Reason was the wrong registration of the shared interrupt service routine

0.11.1:
- AVR works again
- Limit auto enable on delay to approx. 16ms due to further bugs

0.11.0:
- BROKEN ON AVR
- Slowest speed is TICKS_PER_S/0xffffffff, which is ~268s between steps
- ABS_MAX_TICKS renamed to ABS_MAX_AQE_TICKS. Only applicable to raw commands
- Done: Extend command queue entry to perform delay only without step (steps=0) to reduce the 1.0 steps/s

0.10.0:
- setSpeed() silently imposes lower limit for period
- esp32: step pulse length is for high speed with 50% duty cycle and for low speed fixed at 2ms
- addQueueEntry() receives a stepper_command_s struct
- esp32: Task priority of ramp generator task has been set to max Priority.
- StepperDemo extended:
	- Q: Quiet the usage info, which takes time to be transmitted.
      Try this NEMA-17 without load:
			M1 A1000000 V20 P1000 W P0 W P500 W P-500 W P0

0.9.5:
- Fix sudden CPU reset on high interrupt load for avr variant. Issue #12

0.9.4:
- Fix possible race condition in check_for_auto_disable()
- StepperDemo extended:
	- blocking wait for stepper stop by press W (dangerous: can deadlock)

0.9.3:
- Fix auto on delay: Delay way always replied, even if the output is still enabled

0.9.2:
- Implement new function applySpeedAcceleration()
- StepperDemo extended:
	- trigger applySpeedAcceleration by press U
- fix possible bug in move/moveTo while keepRunning is set

0.9.1:
- reduce interrupt load on esp32

0.9.0:
- implement forceStopAndNewPosition()
- StepperDemo extended:
	- trigger forceStopAndNewPosition by press X
    - set position with press @
    - keep motor running with press K
- addQueueEntry() returns now an int8_t instead of an int
- move and moveTo goes to the closest position (+/-2147483647).
  This means continues move(1000) will let the stepper turn in same direction,
  while the position wraps around: 0,1,...,2147483647,-2147483648,-2147483647,...,-1,0,1,...
- add keepRunning() to let the motor continuously run in same direction.
- rename isrSpeedControlEnabled() to isRampGeneratorActive()

0.8.3:
- AVR: timer compare interrupts are only enabled, if stepper is running.
- AVR: on arrival of a command, the queue is started with few µs delay
- Implement backwardStep() and forwardStep()
- Bug solved: Speed changes at very low speed with high acceleration values are not always performed
  Actually speed with period times > 268436µs has not worked at all before.

0.8.2:
- Solved issue: Queue is filled too much, which cause slow response to speed/acceleration changes
  => Queue is filled to max ~10ms into the future.

0.8.1:
- Fix issue #8: Long step times are less accurate than short ones
  => All time delta between steps are cycle accurate
- Add getPeriodAfterCommandsCompleted() to API
- Fix bug due to AutoEnable at ramp start (can find at low speeds)
- StepperDemo outputs: F_CPU/TICKS_PER_S and stepper period at queue end

0.8.0:
- Change direction with running motor is possible !!!
- stopMove() can be called from interrupt routine
- Refactor ramp generation code into RampGenerator.h/cpp
- StepperDemo: ramp state is written as plain text
- Mention platformio in README

0.7.1:
- StepperDemo extended with commands to 
		return status code from move/moveTo
		toggle motor info (I) to suppress info while steppers are running
		output usage (?)
		output motor info with usage
		test direct drive of stepper by port manipulation bypassing the library (T)
- move/moveTo return error codes

0.7.0: Changes towards 0.6.15
- Fix possible floating point exception (divide by zero), which could happen rarely in isr_single_fill_queue
- Remove deprecated functions:
	addQueueStepperStop()
    isStopped()
- internal: remove obsolete _stepper_num variable