http://www.udoo.org/docs-neo/Hardware_&_Accessories/Bricks_snap_in_sensors.html I've copied and pasted the code from the above and get an error like this: cat: /sys/class/i2c-dev/i2c-1/device/1-0060/iio:device0/in_pressure_raw: No such file or directory (much the same for the second "cat") and the end result is I get a syntax error from the shell because the variables are not set. I can get down as far as this: /sys/class/i2c-dev/i2c-1/device/1-0060 but that only contains the following: -r--r--r-- 1 root root 4096 Jun 26 21:04 modalias -r--r--r-- 1 root root 4096 Jun 26 21:04 name drwxr-xr-x 2 root root 0 Jun 26 21:04 power lrwxrwxrwx 1 root root 0 Jun 26 21:04 subsystem -> ../../../../../../../bus/i2c -rw-r--r-- 1 root root 4096 Jun 26 21:04 uevent Yours, Baffled from England.
Did you connect the brick after you booted the Neo? Because then you have to restart the module. sudo rmmod mpl3115 sudo modprobe mpl3115
I've never actually removed it. I'm actually asleep right now and this is my subconscious writing. That's worth a try though. Barometric and temperature are the something that interest me so that brick is a godsend. At least, it would be If I could get it to work. The more pocesses I "kill" on the A9, the more reliable the M4 output (via serial) becomes. With some tweaks, I might be able to coax it to work enough of the time. Simply a case then of "spotting" rouge data, which should be easy enough with JSON and some string mangling. I wonder if turning off the M4 (required for some other modules) might help?
Not an electronic sausage unfortunately. Uname gives this just to make sure we're all on the same page: Linux udooneo 3.14.56-udooneo-02013-gabdce68 #1 SMP PREEMPT Mon Mar 14 17:12:34 UTC 2016 armv7l armv7l armv7l GNU/Linux If that's any help. On a hunch, I did look at "dmesg" to see what the kernel was saying and when I try to remove the module (the brick is attached) I get the following error log (nothing on the console). mpl3115: probe of 1-0060 failed with error -110 The same message appears much earlier in boot which, I expect, probably explains what's going on: [ 6.070142] fxos8700_probe succ [ 6.142828] (stk) :ldisc installation timeout [ 6.147040] (stk) :ldisc_install = 0<6>[ 6.149623] CSI: Registered sensor subdevice: fsl_vadc [ 6.163080] wait vadc auto detect video mode.... [ 6.195314] FAT-fs (mmcblk0p1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck. [ 6.402881] lm75: probe of 1-0048 failed with error -110 [ 6.913719] mpl3115: probe of 1-0060 failed with error -110 [ 7.027165] random: nonblocking pool is initialized I also note there's an FSCHK recommended here. I'll see if that is related. EDIT: fsck doesn't even try to run... (it should warn about a mounted FS). Error -110 (might, again I can't be sure) be error 110: ETIMEDOUT (from errno.h)?
The only thing I can advise you is to use a clean udoobuntu image. Perhaps someone of the Udoo team can help with your I2C problem? @Andrea Rovai
Thanks Walter that sounds like the way to go. This has a lot do with getting my kids interested in the IoT and computing as a functional part of our lives - not just games! However, I'm going to drop it for the moment - I've actually discovered (gasp!) what is potentially a better use of the Neo as a motion sensor which has a number of applications including stabilising my video camera (a project that's driven me nuts for several years!) and even as a seismometer/datalogger. I've written a simple kludge in C and it's already thrown me a loop - but it's a different issue so I'll start a thread about it. ========== QUICK UPDATE: got both the LM75 and the MPL3115 bricks working with a clean install of the minimal image. I haven't tried the desktop image yet as it's way past my bedtime.
@I Hate Google! Do you still meet the same problems after following the wise suggestions of @waltervl?
I have! Although I used the minimal image rather than the GUI version. I've found the GUI is loading the processor so hard (as discussed elsewhere) it's affecting the serial connection to the A9. The shell example to read the barometric brick does give odd results though. The temperature is highly accurate (the LM75 reads several degrees high) but the pressure is off by a huge factor- perhaps 1000x? The raw result comes back with figures around 100.9 (unitless) which I assume is supposed to be 1009 millibars or 100900pa. This is a little less than the local weather station is reading, 1016 millbars, but sufficient to get a register of change. Exciting stuff!
Hi @I Hate Google! It should be Pascal but you'll find more information in these links: the driver: https://github.com/UDOOboard/linux_kernel/blob/3.14-1.0.x-udoo/drivers/iio/pressure/mpl3115.c the datasheet: http://cache.freescale.com/files/sensors/doc/data_sheet/MPL3115A2.pdf
Right now, my local pressure (mbar) is 1007 from the nearest station. The brick is reading (uncorrected): pressure: 99.95125 pressure: 99.95675 pressure: 99.9595 pressure: 99.95775 TL;DR - I've had a look at the source and it's delivering kiloPascals instead (line 124 where the author kindly noted in a comment): *val2 = 250; /* want kilopascal */ 99kpa = 990 millibars * 10 to get millibars and *1000 to get pascals. So all's well that ends well!
Hi All, We are using mpl3115.c - Support for Freescale MPL3115A2 pressure/temperature sensor driver code posted on the Github. Link to driver on the Github is https://github.com/torvalds/linux/blob/master/drivers/iio/pressure/mpl3115.c We have connected the MPL3115 sensor to IMX8MQ-EVK board. We are able to probe the sensor but not able to find a way on how to read from the sensor. We tried to read /sys/class/i2c-dev/i2c-1/device/1-0060/iio\:device0/in_temp_scale but it doesn’t exist. We are able to see till /sys/class/i2c-dev/i2c-1/device/1-0060/ but not the iio\:device0/in_temp_scale The mpl3115 device is probed successfully and creates a folder /sys/class/i2c-dev/i2c-1/device/1-0060/. But we can’t find iio:deviceX directory or the in_pressure_raw files to access the sensor data. We would appreciate if you can help us. Thanks, Girija
@waltervl No I am not using Udoo Neo. We are using IMX8MQ-EVK board on Ubuntu operating system. But the drivers used for sensor is same.
