control inclusion of FFT based on HAL_WITH_DSP and HAL_GYROFFT_ENABLED. target appropriate ARM cpus
define hanning window and quinn's estimator
start/analyse version of FFT to support threading
allocate memory in a specific region
calculate frequency and noise bandwidth of two noisiest peaks
control inclusion of DSP based on board size
For certain basic functionality, there aren't much benefit to be able to
vary the implementation easily at runtime. So instead of using virtual
functions, use regular functions that are "resolved" at link time. The
implementation of such functions is provided per board/platform.
Examples of functions that fit this include: getting the current
time (since boot), panic'ing, getting system information, rebooting.
These functions are less likely to benefit from the indirection provided
by virtual interfaces. For more complex hardware access APIs the
indirection makes more sense and ease the testing (when we have it!).
The idea is that instead of calling
hal.scheduler->panic("on the streets of london");
now use
AP_HAL::panic("on the streets of london");
A less important side-effect is that call-site code gets
smaller. Currently the compiler needs to get the hal, get the scheduler
pointer, get the right function pointer in the vtable for that
scheduler. And the call must include an extra parameter ("this"). Now it
will be just a function call, with the address resolved at link time.
This patch introduces the first functions that will be in the namespace,
further patches will implementations for each board and then switch the
call-sites. The extra init() function allow any initial setup needed for
the functions to work.
Add run method, that encapsulate any mainloop logic on behalf of the
client code. The setup/loop functions are passed via a HAL::Callbacks
interface. The AP_HAL_MAIN() macro should be kept as trivial as
possible.
This interface should be implemented by the existing vehicle objects. To
make easy for the examples (that don't have the equivalent of vehicle
objects), a FunCallbacks was added to bridge to the functions directly.
the idea of a separate console class was never really used, and just
added confusion in a HAL port. It also consumes some much needed ram
and flash space on APM2
* I'd love to build a proper abstraction for logging, but I don't have the
time to do so right now.
* The dataflash libs need to be pushed into the AP_HAL_AVR anyway, so I'll
do that now and replace the interface with a better logging driver later.
* BetterStream Means AP_HAL depends on AP_Common, for now, in order to have
the AVR specific pgm_char_t defined.
I'll need to factor that out in the future but for now it can stay
Andy Piper
Andrew Tridgell
night-ghost
Eugene Shamaev
Lucas De Marchi
Julien BERAUD
Caio Marcelo de Oliveira Filho
Andrew Tridgell
Pat Hickey