Disable hardware checking on Afro HV until driver situation is sorted out.
Limit zero crossing filter backtracking while running.

The back-EMF from some motors when clipping through the high side body
diode seems to create noise that can significantly delay the ZC filter
and lead to significantly retarded timing that can then blind the next
commutation event due to the blanking period and not completing until
after the zero crossing has already passed. This tends to be a problem
at lower speeds and higher currents.

For example, dragging the bell of the 16 pole Multistar (HengLi) 4822
390KV at about 30% duty cycle at 16V would cause significant current draw
and broken timing. Heavy acceleration would also cause synchronization
loss that even the demag_timeout handler could not help with.

Limiting the backtracking (the amount at which we will "back off") from
an accepted zero crossing point seems to greatly help here. This also
seems to help other cases such as switching directions as quickly as
possible. The tendency for some motors to get stuck in slow rotation in
the wrong direction also seems to be fixed.

The only downside seems to be that the unbalanced filtering now seems to
have more tendancy to align to magnetic harmonics than actual motor
timing. This causes a squeak or squeal until the power level is changed
or the motor moves slightly, affecting the inductance. Traces on the
oscilloscope seem to look very much like those from a micro motor in this
case, so it seems difficult to avoid. Please report any such cases where
this is a problem.
Return to 120 degree zero crossing timeout (from 240 degrees).

This seems to further help rapid direction changing since the ZC
filter backtracing was limited.
Some simple fixes and updates to README.md.
Limit zero crossing filter backtracking, take 2.

The approach in 7e76349687 was to just limit the maximum amount of
backtracking that the ZC filtering will do while running. A counter is
initialized based on the timing period and must reach zero to consider
the ZC complete. If the comparator output is the wrong level, the counter
may build back up to the value it started with. We simply set the "value
it started with" to a fixed smaller number while in running state. This
works well on the Multistar 4225 390KV 16-pole motor when dragging by
hand at moderate PWM, but there are some problems.

The previous long filtering method worked much better with tracking of
stalled motors and motors transitioning from starting to running (or
starting where the motor is already spinning). So, with the change, it
can be quite easy to get ahead of the actual back-EMF and align to the
electrical properties of the motor.

When this occurs, we typically spiral up to maximum timing, making a
squeak or squealing sound. Eventually, a zero-crossing timeout occurs or
TIMING_MAX is hit enough times for it to shift the power down to 0 (part
of the RPM limiter) and a zero-crossing timeout occurs. In some cases,
such as with brushless gimbal motors, this happens repeatedly and it is
not possible to actually run the motor unless accelerated externally.
Higher maximum backtracking values help for the gimbal motor, but we then
re-introduce the original problem with the 390KV.

This approach reuses the late demagnetization timer as a trigger for
changing the filtering backtracking whenever timing is slow enough that
the backtracking value is higher than ZC_CHECK_FAST. This idea is based
on the observation that there are no early transitions due to noise,
only late erroneous backtracking, which is what prompted the original
demag_timeout handling. So, after 24 degrees, we now detect more easily
that a ZC has occurred.

This method seems to have the same improvement with the 390KV, while
still working fairly well with the gimbal motor (not quite as good as
before, but once it is running, it is OK). Dragging the the 390KV slowly
still causes the detected ZC to become late, but it doesn't seem to be a
problem anymore for rapid acceleration and this only seems to happen at
very low speeds. The filtering backtracking limit can also be adjusted
(ZC_CHECK_FAST) to help.

In the same conditions, wii-esc with fixed-time ZC filtering seems to
show similar problems. Once the 390KV is started, it continues to trip
the sync recovery code continuously until accelerated past a certain
speed. This turns off power at every commutation, making it easily
visible on the 'scope. The result seems to be reduced torque until
sufficient speed is reached.
Changed CPU frequency to 12MHz. Stops chashes (watchdog timeout) on ESC.