Initialization was also changed a little bit so we don't try to
initialize 25 times. We rather use the same methods as in the
AP_InertialSensor drivers.
Also move up the call to is_zero() in read_raw so we don't set
_mag_[x|y|z] in case of failure.
These are not used. The only place where raw fields are used are in the
compass calibrator and we don't need to store them.
Additionally remove duplicated documentation about the meaning of the
functions to avoid them getting out of sync.
We still need the BusDriver (in some places called SerialBus) interface
since this driver can also be used on an AuxiliaryBus and that has a
different interface.
- Capitalize and rename constants
- Make clear what gain is applied in calibration and what is the
"normal" gain
- Make the separation between HMC5883L and HMC5843 explicit when it
makes sense to improve readability
- Remove spurious delay in calibrate function
We still need the BusDriver (in some places called SerialBus) interface
since this driver can also be used on an AuxiliaryBus and that has a
different interface.
Besides the usual conversion some more improvements:
- Use generic function to convert endianness
- Minor cleanups
- Reorder per-board ifdefs in compass instantiation: distinguish when
there's a default compass to when it should probe other compasses
The find_realexec_path function was used for finding the toolchain path mostly
because of two reasons:
1) We couldn't really use CXX or CC variables because the user could set those
from the OS's environment and Waf wouldn't look for the executable file in
that case.
2) Our CI configuration sets up symlinks for ccache and find_realexec_path
works around that issue.
The bad side about using find_realexec_path() is that, besides working aroung
symlinks, it does the same thing that is done by Waf. This patch removes the
dependency for such a function by addressing each of the reasons above stated:
1) We create a local copy of os.environ and, if there's a variable with the
same name we are using, we remove it from the local copy.
2) As done before, we are looking for the cross ar program instead of gcc
program, since that is not used for ccache symlinks.
This is a better approach than checking command line options
--check-cxx-compiler and --check-c-compiler. Those values expect a list of
compilers to try instead of the compiler to use.
The benefits of this approach are:
- Allowing correct use of options --check-cxx-compiler and --check-c-compiler.
- Allowing user to pass CXX and CC environment variables, which is a common
way of selecting the compiler.
- Configuration is done *and committed* only for the specific compiler.
This is a better approach than checking command line options
--check-cxx-compiler and --check-c-compiler. Those values expect a list of
compilers to try instead of the compiler to use.
The benefits of this approach are:
- Allowing correct use of options --check-cxx-compiler and --check-c-compiler.
- Allowing user to pass CXX and CC environment variables, which is a common
way of selecting the compiler.
- Configuration is done *and committed* only for the specific compiler.
It makes more sense the toolchain Waf tool to be responsible of loading the
compilers. Furthermore, that allows toolchain tool to have control on doing
configuration before and after loading compiler tools.
- Use early return and reduce one indentation level.
- Set AR for both GNU compilers and clang just once and reduce redundancy.
- Reduce indentation level for clang-specific setup. There's no need to nest it
inside check if compilers are GNU or clang.
Cherry-pick the upstream commit:
f556c6e "Add commit() method to ConfigSet"
That will be used for transactionally loading compiler-specific tools for
cross-compilation configuration.
PX4 isn't supported at the moment and sitltest always use GCC, so we include the only ones that build
Travis has old LLVM installed and old Clang in a strange path (not a package) which interfere with the use of clang-3.7
0-length arrays are supported in C but forbidden in C++. GCC allows it
but clang is more strict:
../../libraries/AP_HAL_Linux/SPIDriver.cpp:75:35: fatal error: no matching constructor for initialization of 'Linux::SPIDeviceDriver [0]'
SPIDeviceDriver SPIDeviceManager::_device[0];
^
../../libraries/AP_HAL_Linux/SPIDriver.h:20:7: note: candidate constructor (the implicit move constructor) not viable: requires 1 argument, but 0 were provided
class SPIDeviceDriver : public AP_HAL::SPIDeviceDriver {
^
../../libraries/AP_HAL_Linux/SPIDriver.h:20:7: note: candidate constructor (the implicit copy constructor) not viable: requires 1 argument, but 0 were provided
../../libraries/AP_HAL_Linux/SPIDriver.h:25:5: note: candidate constructor not viable: requires 9 arguments, but 0 were provided
SPIDeviceDriver(const char *name, uint16_t bus, uint16_t subdev, enum AP_HAL::SPIDeviceType type, uint8_t mode, uint8_t bitsPerWord, int16_t cs_pin, uint32_t lowspeed, uint32_t highspeed);
^
1 error generated.
In file included from /home/lucas/p/dronecode/ardupilot/libraries/AP_Compass/Compass.h:6:
/home/lucas/p/dronecode/ardupilot/libraries/AP_Compass/CompassCalibrator.h:86:5: warning: struct 'param_t' was previously declared as a class [-Wmismatched-tags]
struct param_t _params;
^
/home/lucas/p/dronecode/ardupilot/libraries/AP_Compass/CompassCalibrator.h:44:11: note: previous use is here
class param_t {
^
/home/lucas/p/dronecode/ardupilot/libraries/AP_Compass/CompassCalibrator.h:86:5: note: did you mean class here?
struct param_t _params;
^~~~~~
Not having data ready during initialization is normal. Don't print error
message since it can mislead people to think the compass was not
initialized successfully.
Lucas De Marchi
Gustavo Jose de Sousa
ashwinvasudevan
Peter Barker
Randy Mackay
Nitay Megides
Andrew Tridgell
Francisco Ferreira
raspilot