No need to repeat the same comments on 3 different places. Instead add a
single comment to explain how start_measurements() and read_raw() are
related.
Don't use a state machine in AK8963: the start_measurements() method
should be called only once. Even if there's a magnetic sensor overflow
the only thing we should do is to discard the new data.
This also moves the _collect_samples() method to be inside _update()
since it's the only place it should be called from, the one running on
the timer thread.
We need to check the AK8963's id before anything else Here we are
reordering the calls to _calibrate() and _check_id(). After that we
don't need to read and write again the AK8963_CNTL1 register.
While at it do some renames as well:
- _configure() -> _setup_mode(): since now there's a
_bus->configure() it became confusing what actually it's
doing.
- make error messages say what we were actually trying to do but
couldn't. Also remove PSTR since this is linux-only.
- start_conversion() -> start_measurements(): We are instructing the
bus to start to get the samples, not to tell the chip to start an
analog->digital conversion like in other sensors.
The MPUREG_PWR_MGMT_1 defines were used when we cared about the MPU9250
initialization code. Now all initialization is done by the MPU9250 class
itself, so remove these defines.
Also remove AK8983_SELFTEST_MAGNETIC_FIELD_ON that is never used and let
the defines always with 2 bytes to improve readability.
Similar code was added in the read_raw() implementation for each bus.
Add a new POD struct read_raw to contain the registers from the AK8963
and use it instead as argument.
Whenever next waypoint is within the loiter radius, maintaining loiter would prevent us from ever pointing toward the next waypoint. Hence for very close waypoints loiter_to_alt becomes verified by the altitude only.
DMA is getting stopped in the separate method now. This is the best we
can get at the current time. It does yield slightly better experience
and works in the majority of cases.
The patch is a no bulletproof solution, though.
There's a possibility of corruption in case of e.g. a SIGKILL. There's
no signal framework at the time and the commit doesn't add one. That's
why all signals are handled in the same erroneous way. This is not a
good nor a final solution to the issue.
For the issue at hand a better fix might be porting the code to kernel
space but it's a rather tediuos task that we cannot undertake in the
couple of weeks.
The issue has already come up. There's no deinitialization mechanisms at the moment. As APM is rather software than firmware on Linux, there're some clean-up work that needs to be done. This commit triggers deinitialization of RCInput on a panic.
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.
Ublox 7 and 8 seires use a UBX-CFG-GNSS message to enable satellite constellations. The default value does not enable any additional ones, and any constellations the reciever doesn't report knowing about are not configured.
Remove race condition on sending intial blob to the GPS, it was possible to send a blob that got the GPS configured enough to allow the autodetect to take over (and then some drivers like ublox would not finish sending the blob, which has potential details that the driver might have needed to send)
Limit the delay to checking for NMEA gps to only checking after all the available baud rates have been checked
Since a UBlox will actually report having DGPS (due to SBAS or RTCM data) actually report this as the highest supported mode
Merged a bug fix where mode would not revert on geo-fence disable.
The mode would not revert if the switch was in position 0.
Geofencing will soon be in Rover and I didn't want to forget this bug
and chase it later so committing it now. It works fine in Rover now
even though the geofencing code isn't in yet.