It turns out that two calls to micros() and the calculation of
directionChangeDurationUs took 581 cycles, vs 396 cycles without the
calls to micros() and deferred calculation of the duration which is only
needed in the CLI.
This brings the time down from around 7 microseconds to 5.5 microseconds
on an F3 at 72Mhz.
This makes the difference between 100% invalid telemetry and 4% invalid
telemetry on the first motor on the F3.
Squashed commits:
* Remove the forward declaration for `pwmDshotSetDirectionInput` and make
it static.
* Remove unneeded forward declaration of `motor_DMA_IRQHandler`.
* Remove duplication in DMA IRQ Handler.
Doesn't affect resulting code but improves readability.
* Use an inline function to read DWT->CYCCNT.
* Remove unneeded forward declarations from cli.c now that the correct
header is included.
* Update DWT unlock method.
Current micros() may return past time when called from ISR or elevated BASEPRI context. This is because a call to the SysTick interrupt handler sysTick_Hanlder(), which is responsible for 1ms rollover is blocked in these contexts.
This PR introduces microsISR() that is guranteed to return correct time in these contexts. Legacy micros() was also modified to call microISR() in these contexts.
The microISR() uses SysTick's COUNTFLAG to detect a pending rollover and use it to compensate the return value on its own. Actual rollover to sysTickUptime variable is still handled in the sysTick_Hanlder().
Fixes the `Waiting for Data` problem in configurator when:
- Clicking on `Save and Reboot` button
- Clicking on `Flash Firmware` button
When the system reboots after programming the new firmware it still
needs a connect/disconnect cycle to work normal. This cannot be solved
since the bootloader is a fixed program in ROM.
Fix is for F1 targets and only tested on naze boards.
hardware failures by counting the number of long flashes.
Fix up sensor read API so that code that uses sensors can detect
malfunctions.
If a failure mode occurs in a debug mode the code reboots the system
rather than rebooting to the bootloader.
The problem was the MPU6050 EXTI handler was not registered due to baro
detection taking the only callback handler slot. When the MPU6050 EXTI
was configured the interrupt flag was never cleared which results in the
CPU being starved.
Currently the interrupt handler is unused. Later it can be used as a
potential source for watchdog checking or to syncronize the system
around new acc/gyro data availability.
Verified on Naze32 rev 3/4/5 and SPRacingF3 targets.
- NVIC priorities are moved to separate file, all values are replaced wit symbolic names. Priorities should be the same.
- tiny change in DMA initialization
