Commits on Jan 13, 2017
Commits on Aug 8, 2016
Commits on May 16, 2016
Commits on Oct 10, 2015
Commits on Oct 5, 2015
  1. Add note for new binary download location:

    sim- committed Oct 5, 2015
    After over 25,605 downloads at ,
    it's clear that people are still confused where the latest version is.
    I don't want to clutter the source with the binary outputs since there
    are so many boards and variants. So, reference the other location in
Commits on Oct 2, 2015
Commits on Sep 13, 2015
  1. Fast-path timing calculations and raise maximum speed to 312,500eRPM.

    sim- committed Sep 13, 2015
    Previous maximum was about 178,571eRPM. Divide by "pole pairs" to find
    actual RPM; for example, for a 12N14P motor, divide by (14 / 2) or 7.
    The trade-off is slightly more code because of the two paths: one for
    the usual full 24-bit calculations, and one for 16-bit calculations when
    they are sufficient as a result of the shorter timing period.
    Note that TIMING_MIN isn't even enforced since 48fe82e -- Oops.
  2. Add support for blue LEDs.

    sim- committed Sep 13, 2015
  3. Mirror complementary PWM state at commutation advance.

    sim- committed Sep 13, 2015
    This will increase braking force (proportional to commutation rate) with
    software complementary PWM, and improves consistency.
Commits on Sep 10, 2015
  1. Change PWM macros to mirror the previous state rather than specifying…

    sim- committed Sep 10, 2015
    … on/off.
    This really fixes COMP_PWM with HIGH_SIDE_PWM with tristate-style drivers,
    and allows a future fix for traditional driving as well (no output change
    for them here).
Commits on Sep 9, 2015
Commits on Aug 25, 2015
  1. Don't spray back at signals we can't follow.

    sim- committed Aug 25, 2015
    The boot_rx4 loop was intending to fall through to boot_rx_bit, but got
    sidelined by trampoline-avoiding interleaving with boot_tx, and so does
    exactly that in the case of receiving crap or pulses too quickly from the
    I was hitting this when trying to communicate at a 3 microsecond quarter
    bit time (0-bit pulse length). The current reliable minimum speed seems
    to be about 5 microseconds (20 microsecond bit time) which seems to be
    mostly a result of jitter resulting from the timer prescaler not being
    cleared when the timer counter is cleared, and late clearing. Boo.
Commits on Aug 17, 2015
  1. Note that the timings are as measured, not required for correct opera…

    sim- committed Aug 17, 2015
    Any faster or more simple timing may be used.
    Also update the timings as measured with the DS4014.
Commits on Jul 7, 2015
Commits on May 5, 2015
  1. Fix LOW_BRAKE and RC_PULS_REVERSE with RCP_ALIAS ("oneshot125").

    sim- committed May 5, 2015
    No output change except when those options enabled along with RCP_ALIAS.
    This fixes github issue #75.
Commits on Apr 28, 2015
  1. Workaround for building with AVRA 1.3.0 on Mac OSX (github issue #29).

    sim- committed Apr 28, 2015
    Note that the fact that this breaks at all is perhaps an indication that
    bad things are happening, and there could also be issues with the output.
Commits on Apr 20, 2015
  1. Fix COMP_PWM with HIGH_SIDE_PWM with tristate-style driver mode (afro…

    sim- committed Apr 20, 2015
    …_pr*). No output change for anything else.
Commits on Apr 12, 2015
  1. Disable (by default) rapid beeping at stop if invalid PWM pulses were…

    sim- committed Apr 12, 2015
    … received.
    This is perhaps useful, but happens as a result of flight boards changing
    timers or in other situations that probably make this more of a nuisance
    than useful data. However, it is worth trying this option if sync loss is
    suspected since it should indicate if the problem is related to PWM noise,
    as in github issue #50.
  2. Support high side PWM optionally for all boards (HIGH_SIDE_PWM).

    sim- committed Apr 12, 2015
    No output change except pin ordering for the mkblctrl1 target as a result
    of un-faking the high and low side FET pin mappings. This was necessary
    in order to accomplish this before this option existed.
Commits on Apr 7, 2015
  1. Comment updates only.

    sim- committed Apr 7, 2015
Commits on Apr 3, 2015
Commits on Mar 30, 2015
Commits on Feb 26, 2015
  1. Add automatic support for 1/8th PWM pulse length aliases ("oneshot125").

    sim- committed Feb 26, 2015
    Why so complicated? This implementation works almost as if we just added
    a conditional multiply by 8 in the PWM RX interrupt, except without doing
    that. This means that no additional cycles are used that would increase
    software PWM jitter.
    Also, switching between aliased and non-aliased inputs is like switching
    between any other input type in that invalid pulses are rejected until
    the armed session times out, at which point other options (such as the
    opposite alias state) become available again. This avoids the possibility
    that a wire falling off looks like full power in another input alias.
    With some other tricks (such as MIN_RC_PULS * CPU_MHZ & 0xff == 0), the
    RC processing path has only 4 cycles of overhead for length checking that
    isn't part of the interrupt checking, or 1 cycle less than before for the
    non-alias case.
    Calibration is supported when aliased or not, and is carried across. So,
    one can calibrate with long pulses and arm with short pulses, and the
    calibration will line up exactly. This should help with comparing modes
    without introducing any other changes.
    Note to flight controller software people: "oneshot" should really be
    separated into two options such as "syncpwm" (synchronous PWM, which is
    where the "one shot" name comes from), and something like "8xpwm" (1/8th
    PWM pulse lengths), since they really are totally separate things. This
    would also help with actually producing fair test results, and "syncpwm"
    could be used on all ESCs (KK1 says hello).
    Note that boards with PWM input on the ICP1 pin (USE_ICP set in the .inc
    file) such as all Afro ESCs and Team BlackSheep (TBS) ESCs have hardware
    capture of the pulse edges. This means they can measure pulse lengths
    with no jitter, which becomes more important at shorter lengths. Other
    ESCs will incur some PWM input jitter due to multi-cycle instructions,
    areas of code which block interrupts, and when other interrupts are
    already executing.
    Finally, note that we still report out of range PWM pulses by beeping
    rapidly once the motor stops. The purpose of reporting this is that
    pulses being corrupted by power noise or ground offset or some other
    electrical problem could cause other problems in flight. Twisted wires,
    proper grounding, or opto-isolation may be required for reliable
    operation. Please report any abnormal cases.