ruwen wrote: ↑07 Apr 2020, 00:30
So if i build the 4.19 kernel and activated the devicetree in the boot-config i can directly plug my sensor to the Core3+ Bridge Adapter (in accordance to the pinout)?
Again, the SPI bus is only exposed on the RevPi Connect. Not on the Core3+. But other than that, yes, it is possible to place your sensor in the maker kit case, attach it to the right hand side of the Connect, and with a 4.19 kernel and addition to the devicetree it will be usable.
ruwen wrote: ↑07 Apr 2020, 00:30
If so, how can i access my sensor data? Can i configure it via Pictory or access the data via piTest?
There are actually two drivers in the kernel for this sensor: An older one in the input subsystem and a newer one in the iio (Industrial I/O) subsystem. Actually I realize now that the input driver is already in our 4.9 kernel. Only the iio driver requires 4.19:
The input driver is in this directory in the adxl34x* files:
https://git.kernel.org/pub/scm/linux/ke ... input/misc
The iio driver is in this directory in the adxl345* files:
https://git.kernel.org/pub/scm/linux/ke ... /iio/accel
I'm not familiar with accelerometers and their drivers, but the iio driver will expose a directory in /sys/bus/iio/devices/ with a bunch of files to access the sensor. Search for the string "accel" in this file to get an overview of the data that is made available:
https://git.kernel.org/pub/scm/linux/ke ... fs-bus-iio
I don't know how the input driver is supposed to be used. I suppose it sends input events to user space when something happens. I notice it requests an interrupt for that. There's an interrupt pin available on the ConBridge which you may use for this purpose. We use it on the Con CAN module to attach the interrupt of the hi3110 chip. The iio driver on the other hand does not seem to make any use of the chip's interrupt.
Something else I notice in the input driver is that adxl34x-i2c.c contains a "struct of_device_id" array which is referenced by a MODULE_DEVICE_TABLE() macro as well as in the struct i2c_driver. But adxl34x-spi.c is missing that. Thus, if you want to use the input driver, you need to hack adxl34x-spi.c to also contain those strings, otherwise it's not possible to bind the driver to the DeviceTree node. Hm, now we're firmly in kernel hacker territory...
If you want to be able to control the sensor via piControl/piTest, you'd have to extend the piControl source code to access the sensor via the iio driver and expose it in the process image. That's possible, but it's another piece of kernel-level code you'd have to touch. We're doing this on the upcoming RevPi Compact: It has an ADC and a DAC which are under the control of iio drivers. piControl uses the in-kernel iio API to access the sensors and expose them in the process image. So piControl is kind of like a shim between the iio drivers and the process image on the Compact:
https://github.com/RevolutionPi/piContr ... _compact.c
I'm sorry if all of this sounds complicated. But it's doable if you're willing to get your hands dirty and we're right here to answer your questions.
