bkueng
commented
7 years ago The HMC5883 datasheet (pg. 12) recommends sampling at no more than 75 Hz in single measurement mode when not monitoring the DRDY interrupt pin, and in general there is no interrupt pin from the external HMC5883 normally packaged with many popular external GPS modules. On OcPoC hardware, there are also occasional glitches in the I2C line during the _measure() callback, and the subsequent write single-measurement setting would lock up the kernel just long enough to cause an Accel #0 TOUT! error. For this reason, we set the HMC5883 into continuous measurement mode during hmc5883_init() so we no longer have to continuously write the measurement mode after every read.
@julianoes you're actually in a better position to review this: should we generally switch to continuous mode?
Upon stopping PX4 we would find that the SPI devices were sometimes still accessible from testing scripts, and the I2C devices would entirely segfault or return corrupted data. It’s suspected that when the bus drivers leave their file descriptors open they continually allocate memory until the devices are closed
Seems to me there is more going wrong than just memory that is not freed until a close. Can you check with cat /proc/meminfo if one of the values keeps increasing? I'd like to have your hypothesis confirmed, otherwise it could very well be that the changes here just let the problem appear less often.
In general I'd keep the FD's open since we regularly access them with high frequency (I would not consider them as unused). Reopening causes unnecessary overhead if not strictly required. But I'm not sure what the recommondation/best practise for this use-case is.
alexshirley
julianoes
Our recent testing discovered some issues with DriverFramework on OcPoC hardware:
The HMC5883 datasheet (pg. 12) recommends sampling at no more than 75 Hz in single measurement mode when not monitoring the DRDY interrupt pin, and in general there is no interrupt pin from the external HMC5883 normally packaged with many popular external GPS modules. On OcPoC hardware, there are also occasional glitches in the I2C line during the _measure() callback, and the subsequent write single-measurement setting would lock up the kernel just long enough to cause an Accel #0 TOUT! error. For this reason, we set the HMC5883 into continuous measurement mode during hmc5883_init() so we no longer have to continuously write the measurement mode after every read.
As PR #155 disabled the scheduling adjustment for embedded platforms, we have now disabled that adjustment for OcPoC hardware as well.
During testing, there seemed to be a memory leak which would cause all DriverFramework devices to fail simultaneously leading to uncontrolled flight. Upon stopping PX4 we would find that the SPI devices were sometimes still accessible from testing scripts, and the I2C devices would entirely segfault or return corrupted data. It’s suspected that when the bus drivers leave their file descriptors open they continually allocate memory until the devices are closed. It is a poor practice to leave device files open for the majority of the operation, as that ties up machine resources. Thus we have introduced opening and closing of the device files during normal I/O transactions, keeping in accordance with NASA’s ‘94 C-Style guide, Chapter 8.2 as “Free allocated memory as soon as possible”.
Note that we have kept all changes board-specific to OcPoC to avoid unnecessary changes or unintended consequences on other hardware, but these changes may be worthwhile to test for more generic implementation.