Hi folks!
As always, I'll start with relevant environment details
===== Environment =====
nRF Connect SDK v2.5.0 (though not opposed to upgrading to one of the 2.6.X releases if helpful)
Designing for nRF52840
- Prototyping on nRF52840DK with attached (i2c) LSM6DSL breakout (https://www.st.com/en/mems-and-sensors/lsm6dsl.html)
- Production aimed at Xiao BLE Sense (https://wiki.seeedstudio.com/XIAO_BLE/)
===== Overview =====
I'm working on a project that involves significant use of many different IMU functionalities.
I need:
- Control over data rate and scale (very possible with current drivers)
- Control over interrupt source (harder, but possible through register setting via hw_tf)
- Ability to go check registers based on an interrupt (e.g. query wakeup source, tap direction)
- Ability to control power manager
As an aside, I cannot use the CAF sensor manager because:
- I cannot sync the CAF sensor manager frequency to the IMU's interrupt channel (constraint by integer req. on sampling ms) ( Common Application Framework and custom Sensor with Sensor Manager Module)
===== Questions =====
I'll have to write an expansion to the existing drivers (currently at ncs/v2.5.0/zephyr/drivers/sensor/lsm6dsl/<these files>)
I'm quite experienced with this IMU in particular. I'd be very willing to write up a driver that adds handles to the functionalities I need, but I'd like some preemptive structural guidance.
At first, I was just going to pull the drivers into my application and rework them there (alongside modules), but when including them in the CMake.txt I got quite a few problems regarding duplicate definitions.
As I read it, the build system always includes /drivers (/zephyr/CMakeLists.txt), and then dives into more detail based on KConfig options. (/zephyr/drivers/CMakeLists.txt) if sensor and (/zephyr/drivers/sensor/CMakeLists.txt) if lsm6dsl. The conclusion I draw there is that the right way to do it (modify sensor drivers to my own needs) is to modify it in /drivers/ and leave it out of my application modules.
If I were to go this route, (making my own driver with handles on the functionality I need), I have a couple questions:
- Where can I find style guides to make sure I'm conforming to zephyr best practices for a driver
- How can I best make that work available to other zephyr developers?
- PR into nrfconnect/sdk-zephyr? (not ideal -- I'd like to use it in my own project alongside v2.5.0)
- Fork ncs/zephyr? (not ideal -- I'd like to be able to transition my project forward to later Zephyr releases without having to fold in my own block of driver code)
I share a lot of the same needs and concerns as the author of this post: (Migrating LSM6DSL Custom FIFO and Interrupts Implementation from nRF to Zephyr SDK: Seeking Guidance)
And I'll call out here that ST Did publish drivers that I'm considering using as an external lib (https://github.com/STMicroelectronics/lsm6ds3tr-c-pid/tree/master).
However, I would like to utilize Zephyr's modularity and tie the LSM6DSL drivers in to the tools provided by sensor.h.
I'd be grateful for any advice, words of warning, or pointers to wisdom you think I'll need.
Best Regards,
- Finn
