I would like to retrieve a buffer of data from the BMI160 instead of just single samples. Is this possible? If so how would I go about doing it from user space?
Thanks
I would like to retrieve a buffer of data from the BMI160 instead of just single samples. Is this possible? If so how would I go about doing it from user space?
Thanks
There’s a bmi160_fifo
branch in the mangOH repository that takes a stab at this. There is also this corresponding app which performs a read. https://github.com/mangOH/mangOH/tree/bmi160_fifo/samples/BufferedImuRead
I haven’t looked at this stuff in a little while, so I don’t remember the exact status of it all.
@dfrey Thanks for pointing that out. I quickly reviewed it and I have some followup questions.
First, context. I’m trying to access, from user space, the trigger buffer of data that was captured when the interrupt fires. This should have the significant motion event. Once I have this buffer then I plan on performing some analysis in the user space.
Is libiio the only way to access the trigger buffer from user space?
The branch you pointed me to requires LIBIIO. I’m working with the WP85 module which doesn’t have the IIO builtin by default. Is LIBIIO compatible the WP85 as long as I am building in IIO?
Currently our BMI160 driver is set to generate interrupts on significant motion. When this happens a buffer is captured in IIO. Can’t I just call fscanf in a loop and read the contents of the buffer?
Thanks
The bmi160 driver sits on top of the IIO kernel framework. On wp85/75, IIO wasn’t built with the kernel. As a result, we pulled some of that code out of tree and built it as modules and bundled those modules with the Legato system.
libiio is a userspace library for accessing IIO devices. It provides convenience over manually traversing /dev
and /sys/bus/iio
. It’s not “magic” though, so anything you do with libiio can be achieved without it.
When I worked on the buffered reading for bmi160 I was focusing exclusively on the wp76. I don’t recall if all the necessary IIO kernel modules are provided for wp85/75.
@dfrey Thanks will dive in and give it a try. You mentioned here the Using Accelerometer on MangOH Red the the bmi160_fifo requires an unpublished kernel change. Can you elaborate further?
Unfortunately, I have forgotten what I was referring to. Let me know if you find that something is missing when you try to put this together. It may jog my memory.
Sorry if I’m late to the party, but we had pretty much the same requirement of needing chunks of data from the accelerometer instead of single samples.
I tried David’s bmi160_fifo branch, but wasn’t very familiar with IIO so ended up ditching that effort. Instead I switched to using the BMI160’s onboard FIFO to get a thousand samples every 250ms. You can tie the FIFO interrupt to your application so you know exactly when the FIFO’s full. I switched out the kernel module for BMI160 and instead used a user space driver from Bosch https://github.com/BoschSensortec/BMI160_driver to achieve this.
@ktanikel Better late than never, right Thanks for the tip I will consider doing that instead.
The bmi160_fifo branch uses both an IIO kernel FIFO and the bmi160’s hardware FIFO. The idea was to sample continuously and service the buffers quickly enough such that they would never overflow.
Very late to the party… Having issues with a WP77xx and the fifo branch.
It bombs out here:
if (devm_gpio_request_one(&pdev->dev, CF3_GPIO32, GPIOF_DIR_IN,
"gpio expander")) {
dev_err(&pdev->dev, "Couldn't request GPIO expander interrupt GPIO");
ret = -ENODEV;
goto cleanup;
}
root@swi-mdm9x28-wp:~# [ 130.757302] mangoh red mangoh red: Couldn't request GPIO expander interrupt GPIO
[ 130.764558] Unable to handle kernel NULL pointer dereference at virtual address 0000007c
[ 130.771828] pgd = c8318000
[ 130.774424] [0000007c] *pgd=00000000
[ 130.777984] Internal error: Oops: 5 [#1] PREEMPT ARM
[ 130.782926] Modules linked in: mangoh_red(O+) tem32j(O) ltc294x(O) led(O) bq27xxx_battery(O) bq24296(O) bmi160_i2c(O) bmi160(O) [last unloaded: bmi160]
Yes. It was caused by the GpioExpanderService trying to claim the same IRQ
Now I’m seeing this:
Jan 6 04:19:29 swi-mdm9x28-wp user.info Legato: INFO | imu[1912]/imuComponent T=main | main.c ReadImu() 65 | Got channels (anglvel_x, anglvel_y, anglvel_z, accel_x, accel_y, accel_z, timestamp)
Jan 6 04:19:34 swi-mdm9x28-wp user.emerg Legato: EMR | imu[1912]/imuComponent T=main | main.c ReadImu() 90 | Failed to refill buffer: Invalid argument
Any pointers?