I've been working on a project using the Edison and was hoping to get some feedback from everyone. I'm trying to read data from an IMU (http://www.analog.com/en/products/sensors/inertial-measurement-units/adis16448.html ADIS16448) by synchronizing to the "Data Ready" output on one of the IMU's DIOs. I'm hoping to use this data in a Java, so timing is critical.
I found that ADI has IIO https://wiki.analog.com/resources/tools-software/linux-drivers/iio-inertial-measurement-units/adis16... adis16400_iio_inertial_measurement_unit_linux_driver support for the IMU in the Linux kernel, so I attempted to re-compile it with new features without success. I'm not 100% sure what SPI port the IIO driver is expecting to use nor whether I should be able to see the device listed in /sys/bus/iio/devices/ even though it may or may not be present. In an attempt to get something working, I built some software based on MRAA to pull data from the sensor and pass it to Java using a network socket, but unfortunately the overhead and data loss is terrible. I'm not sure whether there are any SPI examples for triggering data reads using external interrupts, or whether any of this is possible from within Java.
Does anyone have any suggestions?
Thanks for your help!
Could you please let us know what changes you made to the sources to enable IIO support? Also, which image are you using?
If you could provide your code that would also help us.
I set up the environment as per the Intel documentation https://software.intel.com/en-us/node/593593 here on Ubuntu 14.04 LTS. I used menuconfig to disable the two IIO ADC modules and enabled both Analog Devices iSensor modules (adis16400 and adis16480) as documented https://wiki.analog.com/resources/tools-software/linux-drivers/iio-inertial-measurement-units/adis16... here.
I've moved away from using IIO since the driver will not support synchronous data acquisition from the sensor. I implemented a driver (similar to the upm driver) in C++ using mraa but have also been unsuccessful in synchronously acquiring data from the sensor at rates > 100Hz. Unfortunately, it looks like there is no way to service interrupts in a similar manner to a microcontroller without using the MCU built into the Edison (which doesn't currently support SPI). In addition to servicing the data acquisition interrupts, performing any calculations (position/heading) on the data synchronized to sensor inputs is also not trivial.
Does anyone have any suggestions on how to improve the Edison's performance in real-time applications?
Have you tried with Fast Memory-Mapped I/O? You might get better results using that. Look at this tutorial from the i-Programmer guys http://www.i-programmer.info/programming/hardware/8770-exploring-edison-fast-memory-mapped-io.html http://www.i-programmer.info/programming/hardware/8770-exploring-edison-fast-memory-mapped-io.html. Fast Memory mapped IO allows better synchronization by letting the software write directly to the memory locations. Along with this tutorial they also provide some examples for other sensors.
It looks like FMMIO isn't what I'm looking for. My issue is not generating pulses or performing read operations (SPI) from the sensor. My issue lies in not being able to react to an external signal in a timely manner or in microcontroller terms, trigger on an external interrupt, due to the Yocto operating system not being deterministic. The most basic portion of my project is to perform data collection without missing any samples at reasonably low rates ~200Hz, but it's looking like the Edison isn't capable of this.
I agree, Yocto is not an OS, but rather one of many Linux variants available. I do have a few questions about what you mention arfoll. What is the difference between adding an intermediate microcontroller used to synchronously sample data from a digital sensor and pass it to the Edison and reading the sensor directly? If the Edison is not capable of reading data synchronously, is the Edison useful for inertial navigation applications at all?
I agree, the Edison isn't a good platform to use for embedded, time-critical applications.
juchong well typically in these use cases people want to make a decision based on the accelerometer pattern, so generally people will do the pattern detection on the microcontroller, detecting what movement they wanted and then send a message to the edison to process that message, for example if you need to send it to the cloud etc... For something like inertial navigation you could do the calculations on the micro and then let people access that data via the edisons connectivity, BLE, wifi or even doing post processing/graphing/mapping of that data. It really depends what you'd like to do.
Hi Juan, arfoll,
You're right, Fast memory mapped IO is not what you need for such application. If you want to use the Edison on your application, then Arfoll's suggestion would be the way to go, doing the sampling from an external microcontroller and handle/analyze the data from the Edison.
Are you still interested in setting up and running ADIS sensor on Edison?
I have positive experience with ADIS 16480 / 16488. There is small data loss on 1230 Hz, lower rates work better.
I'm using native Analog device IIO driver. Biggest issue was dig into the kernel to setup a new spi device.
I've attached the patch. Settings are hardcoded since there is no device tree support.