-
Notifications
You must be signed in to change notification settings - Fork 17.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow Periph to compile with !AP_GPS_ENABLED #25119
Allow Periph to compile with !AP_GPS_ENABLED #25119
Conversation
a3aef8d
to
95f3060
Compare
d43b575
to
5cb0416
Compare
5cb0416
to
747589c
Compare
747589c
to
48bc344
Compare
I've run this through size-compare-branches.py and it's all-stars except Durandal (due to some optimisation things in AP_AHRS.cpp), and HerePro which now gets AP_AHRS_ENABLED. HerePro has scripting enabled, that has methods in it into the Location library which require AP_AHRS - so we need to compile the AP_AHRS library in. It will still die if it ever calls the AHRS methods as we won't be instating the singleton. Can't use PH's new per-method |
Closes potential problem with HerePro if it calls AP_AHRS methods
... added a patch that creates the AHRS singleton if AP_AHRS_ENABLED is true, which would stop HerePro from dying if you were to call AHRS methods on it. CubeOrange-Periph-heavy got 880 bytes smaller as it doesn't include scripting and thus no AHRS is required. |
No description provided.