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.
Move the macros to a single place and reduce the variations not based on
board, but based on
- The name of the entry-point function, specified by AP_MAIN;
- Whether it contains argc/argv arguments or not.
The goal here is that programs (vehicles and examples) don't need to
include all possible boards to define a main function. Further patches
will change the programs.
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
Siddharth Purohit
Andy Piper
Andrew Tridgell
Peter Barker
Eugene Shamaev
Lucas De Marchi
Julien BERAUD
Caio Marcelo de Oliveira Filho
Andrew Tridgell
Pat Hickey