prog_char and prog_char_t are now the same as char on supported
platforms. So, just change all places that use them and prefer char
instead.
AVR-specific places were not changed.
Now variables don't have to be declared with PROGMEM anymore, so remove
them. This was automated with:
git grep -l -z PROGMEM | xargs -0 sed -i 's/ PROGMEM / /g'
git grep -l -z PROGMEM | xargs -0 sed -i 's/PROGMEM//g'
The 2 commands were done so we don't leave behind spurious spaces.
AVR-specific places were not changed.
The PSTR is already define as a NOP for all supported platforms. It's
only needed for AVR so here we remove all the uses throughout the
codebase.
This was automated with a simple python script so it also converts
places which spans to multiple lines, removing the matching parentheses.
AVR-specific places were not changed.
Follow the following order for includes:
- Corresponding header file (if exists)
- System headers
- Other ArduPilot library headers
- "Local" headers (from the same library)
This was introduced with the HAL rework:
In file included from /p/ardupilot/libraries/AP_HAL/AP_HAL.h:11:0,
from /p/ardupilot/ArduCopter/Copter.h:35,
from /p/ardupilot/ArduCopter/ArduCopter.cpp:76:
/p/ardupilot/ArduCopter/ArduCopter.cpp: In function 'int ArduPilot_main(int, char* const*)':
/p/ardupilot/libraries/AP_HAL/AP_HAL_Main.h:11:26: warning: no previous declaration for 'int ArduPilot_main(int, char* const*)' [-Wmissing-declarations]
#define AP_MAIN __EXPORT ArduPilot_main
^
It's due to PX4 using that warning as opposed to Linux. Since it harmless, add
the prototype for everybody.
Since we are using uint8_t and uint16_t types we need to include the
correspondent system header. Otherwise it would depend on the include
order of who is including this particular header, causing failures as we
move headers around.
This is going to be used by vehicles that already have an object with
setup/loop functions. The vehicle object will just implement the
HAL::Callbacks interface.
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.
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.
Instead of requiring every program to specify the HAL related modules,
let the build system do it (in practice everything we compiled depended
on HAL anyway). This allow including only the necessary files in the
compilation.
The switching between different AP_HAL was happening by giving different
definitions of AP_HAL_BOARD_DRIVER, and the programs would use it to
instantiate.
A program or library code would have to explicitly include (and depend)
on the concrete implementation of the HAL, even when using it only via
interface.
The proposed change move this dependency to be link time. There is a
AP_HAL::get_HAL() function that is used by the client code. Each
implementation of HAL provides its own definition of this function,
returning the appropriate concrete instance.
Since this replaces the job of AP_HAL_BOARD_DRIVER, the definition was
removed.
The static variables for PX4 and VRBRAIN were named differently to avoid
shadowing the extern symbol 'hal'.
This method is not used anymore since the introduction of channel map and
allowing motors to be enabled/disabled in AP_Motors.
Later we may introduce a method to write multiple values with a default
implementation that supports the channel and enable maps rather than
requiring all subclasses to implement this method.
This commit changes the way libraries headers are included in source files:
- If the header is in the same directory the source belongs to, so the
notation '#include ""' is used with the path relative to the directory
containing the source.
- If the header is outside the directory containing the source, then we use
the notation '#include <>' with the path relative to libraries folder.
Some of the advantages of such approach:
- Only one search path for libraries headers.
- OSs like Windows may have a better lookup time.
Add a deinit() counterpart. This is needed for some ports that require some deinitializtion logic. The default implementation is empty. I'm not sure whether we need to inforce it for all.
This adds the backend driver for LSM9DS0. This implementation is based on the
legacy driver coded by Víctor Mayoral Vilches (under folder LSM9DS0) and makes
some necessary adaptations and fixes in order to work properly. The legacy
driver folder was removed.
It both reduces flash size and move symbols to read-only sections.
The scheduler_tasks table is one known not to be in read-only section before due
to the FastDelegate implementation. Before and after this patch:
APMrover2 $ size APMrover2.elf{.old,}
text data bss dec hex filename
611406 4832 40920 657158 a0706 APMrover2.elf.old
609686 4824 38936 653446 9f886 APMrover2.elf
APMrover2 $ nm -C APMrover2.elf{.old,} |grep tasks
0000000000696f80 B Rover::scheduler_tasks
000000000047c440 R Rover::scheduler_tasks
As can be seen above, now the scheduler_tasks symbol is in a read-only data
section and in all of them we decreased the total size.
For APM2 we have a similar situation, but the table was already in text section
because it was using plain C pointers:
APMrover2 $ size APMrover2.elf{.old,}
text data bss dec hex filename
189518 1038 3494 194050 2f602 APMrover2.elf.old
189216 1038 3480 193734 2f4c6 APMrover2.elf
APMrover2 $ nm -C APMrover2.elf{.old,} |grep tasks
00001f92 T Rover::scheduler_tasks
00001f8a T Rover::scheduler_tasks
Now that we are using C++11 we can use variadic templates to simplify
the FastDelegate classes. It also simplifies moving away from the
FastDelegate implementation.
Start to add code behind APM_BUILD_FUNCTOR to support changing the
functor implementation (without breaking the build while the change is
not complete).
This is a Functor implementation that should cover the use cases we have
for FastDelegate. In contrary to the latter, it can be constructed at
compile time so the compiler can safely put it in a read-only section
which covers the cases in which we are not using it.
