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 transmitter. 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.
…tion. Any faster or more simple timing may be used. Also update the timings as measured with the DS4014.
No output change except when those options enabled along with RCP_ALIAS. This fixes github issue #75.
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.
…_pr*). No output change for anything else.
… 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.
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.
…by Achim, issue #72.
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.
…d after beeping.
properly implement the original purpose of e1c44c0. This should be safer again, regardless of the size or page alignment of the initialization code.