Ardupilot traditionally relies on a very mature 4.9 version of gcc/c++. Since then, gcc has improved vastly when looking at warnigns generated for common coding errors. Personally, I would really like to profit from these improvements, but this is currently not possible, as AP simply doesn’t compile when using e.g. gcc 7.1.0.
The reasons are mostly due to some marginal code style issues. So most libraries include cmath instead of math.h, but still use isinf() or isnan() without caring about namespace prefixing (they are in std:: now).
Are there any plans (or even work in progress) to improve the situation here? If not - are PRs welcome about this topic?
PR are always welcome !
And it is more that we use math.h instead of cmath
In fact, ardupilot should compile on gcc 7 , that is the default for chibios version I think.
But the blocking point is the Nuttx version that doesn’t compile with gcc > 4.9
Newer NuttX works fine with GCC 5, 6, 7 and Clang. PX4 NuttX is using GCC 7 (GNU Tools for Arm Embedded Processors 7-2017-q4-major) for release builds.
Compiling with a more recent gcc has turned up a couple of incorrect usages of snprintf() on too small buffers, which I have fixed in the PR.
There is one more issue which I did not fix (yet), because I do not really understand the intention of the author (no break in libraries/AP_Beacon/AP_Beacon_Marvelmind.cpp:330).
After resolving these issues, ArduPilot compiles fine for all vehicles with GCC 7.2.1 on both ChibiOS and PX4-NuttX.
nice ! thanks for that, I will try to review that as soon as possible. I just remember another thing that prevent us to use more recent gcc, it was the binary size. gcc > 5.4 tend to produce bigger binary and we didn’t want to get ouside the 1mb limit of some old pixhawk. This was solve recently with removal of some optional feature on px4-v2.
However, changing default gcc target will be subject on big talk I think… but it is good to be able to fix the compilation. Thanks again for looking into that
Regarding binary size: I was very curious how the newer compilers perform here. Therefore I have built for all vehicles and for both px4 and ChibiOs and recorded the output:
thanks for your work on this Holger.
I prefer using the newer gcc versions with ChibiOS as gdb support is so much better, so this makes the transition to ChibiOS easier as developers don’t need to switch compilers
I did a few flights today, one of them for about 40mins and containing lots of flight modes including a longer Auto section.
Configuration notes
cube 2.1
Copter, fmuv3 binary (ChibiOS)
motors connected to FMU ports (quad)
S.Bus radio (Crossfire) and telemetry
Tested modes: Stabilize, AltHold, PosHold, (New) Loiter, Auto
Issues:
no signal tones on flight mode switching, compass calibration and on reached way points (probably not yet implemented in ChibiOs build)
somewhat strange waypoint turning behaviour - probably a tuning issue of my crash-test airframe
NLon = 3 at one occasion while arriving at a waypoint (0 long lops otherwise after run up completed)
Log available on request, as I accidentially enabled high rate IMU logging (400MB). BTW, there seems to be zero log drops with high rate IMU logging on a normal TransCend consumer grade 16GB card - the first time ever!
