search

SuperHouse / esp-open-rtos

Open source FreeRTOS-based ESP8266 software framework
BSD 3-Clause "New" or "Revised" License
1.53k stars 491 forks source link

MEMS sensor drivers in extras #534

Closed gschorcht closed 6 years ago

gschorcht commented 6 years ago

I have written some drivers for MEMS sensors like the gyroscope L3GD20H, the accelerator LIS3DH, the magnetometer LIS3MDL, and their combination like the LSM303D. All these drivers are working together with ESP8266 and esp-open-rtos as well as ESP32 and esp-idf.

Are these drivers of interest for the project's extra folder? If so, I could create according pull requests.

flannelhead commented 6 years ago

Sounds definitely interesting to me. Are the drivers I2C or SPI based?

I've also got drivers for MPU6050 and LSM6DS3 gyro + accelerometer combinations. What I've been wondering is if there should be some kind of a HAL or standardized interface for operating them. Oftentimes sensors from different manufacturers seem to be very similar, main differences being the registers and their values during configuration.

I'd very much like to see how you've handled the different sensors @gschorcht.

gschorcht commented 6 years ago

@flannelhead The drivers support I2C as well as SPI.

Yes, at least for the sensors from STM that I know, it seems that they have very similar interfaces and are used in a similar way. Therefore, I was also wondering whether it's possible to define a standardized interface. But, I had to learn that even though the interfaces seem to be similar and also the registers seem to be almost the same, their configuration and their usage can be quite different. So it seemed to be easier for me, to develop a specialized driver for each sensor. STM itself developed a specialized Linxu input driver for each of their MEMS sensors: https://github.com/STMicroelectronics/STMems_Linux_Input_drivers/tree/linux-3.10.y-gh/drivers/input/misc/st

From my point of view, at least some functions could be standardized, e.g., init_sensor, new_data_available, config_interrupt, get_interrupt_source, get_raw_data and propably get_float_data.

You can take a look to my fork. There is a separate branch for each of the sensors.

flannelhead commented 6 years ago

@gschorcht, that seems like a sensible approach, and I agree with you that the use cases could be quite different. Your drivers look good in my opinion and would be a nice addition to the OS.

The set of standardized functions you mentioned seems feasible. I've been using a somewhat similar interface in my project where I support MPU6050 and LSM6DS3 interchangeably - there actually are only init_sensor and get_raw_data implemented in the common interface. init_sensor takes in an array of register-value pairs for configuring the sensor. In my case that's the easiest route - the configuration is separately specified for both sensors so that they match each other (ODR, full scale range etc.) While that contradicts the idea of a high-level API, this reduces the maintenance surface for the cross-compatibility layer and also reduces the barrier of introducing new sensors, not having to implement a full-blown high-level API for the sensor.

Just some thoughts... IMO your drivers look really good :) An interface like this could even be added afterwards.