RaspberryPi + 1-wire + i2c + camera and kernel pain
Our last research project was real fun: Build a Webcam with temp and light sensor to do some home/office automation.
We took a RaspberryPi model B, temp sensor (DS18B20) and light sensor (TSL45315).
The temp sensor had a 1-wire interface and the Internet had many tutorials to connect the sensor to a RasPi. It should be a trivial job, if you read the tutorials and it should be ready in max. 10 minutes. Should!
The theory wasn't the reality and the tutorials didn't cover our environment, because we had a new Raspbian ISO with kernel 3.16 and 3.18 some hours later.
We tried to connect the sensor as described (with and without pullup resistor, with parasite power and without) but it wasn't detected. It was horrible because the driver was loaded without problems and logged a simple success message.
We didn't find information about the problem because we didn't see an error. It simply did nothing and the filesystem didn't contain the relevant files and directories. Our /sys/bus/w1/devices directory was clean and empty. After some hours error searching, without any ideas we tried an older Raspbian image with kernel 3.6 and our sensor worked out-of-the-box without modifications. We saw additional log information from the 1-wire module which we didn't have with our 3.18 kernel. So we knew that something has changed in the kernel or kernel config...
But we weren't happy because the whole thing should work with an up-to-date setup. After we knew that the kernel caused our problems, we tried to find a solution and found: http://www.raspberrypi.org/forums/viewtopic.php?t=97216&p=676793 (first posting on 2nd page). There was a hint about the device tree. With this information, we found: https://github.com/raspberrypi/documentation/blob/master/configuration/device-tree.md
We disabled the device-tree by adding device_tree= to our config.txt and everything worked after a reboot, with our 3.18 kernel. So far so good.
It also worked with device_tree_overlay=overlays/w1-gpio-overlay.dtb. This option was our preferred one because it didn't disable the device_tree.
After our temp sensor worked without problems we connected the Raspicam and made some tests. Everything worked without problems. The last piece of our project was the light sensor. It was a littly bit tricky to use the sensor with our Pi because the source code example wasn't available for Java/Pi4J, but here it is:
I2CDevice device = bus.getDevice(0x29);
device.write((byte)(0x80 | 0x0A));
byte[] byData = new byte[1];
device.read(byData, 0, 1);
System.out.println(byData[0]);
System.out.println("Power on...");
device.write((byte)(0x80 | 0x00));
device.write((byte)0x03);
System.out.println("Config...");
device.write((byte)(0x80 | 0x01));
device.write((byte)0x00); //M=1, T=400ms
//device.write((byte)0x01); //M=2, T=200ms
//device.write((byte)0x02); //M=4, T=100ms
byData = new byte[2];
while (true)
{
device.write((byte)(0x80 | 0x04));
device.read(byData, 0, 2);
int l = byData[0] & 0xFF;
int h = byData[1] & 0xFF;
int lux = (h << 8) | (l << 0);
lux *= 1; //M1
//lux *= 2; //M2
//lux *= 4; //M4
System.out.println(lux);
Thread.sleep(1000);
}
We compared the output with an Arduino board and the values were "the same".
It wasn't possible to use the light sensor without required modules. We simply added device_tree_param=i2c1=on to our config.txt and I2C worked. You should install
to verify connected sensors, via:
After we thought that everything will work, we put all pieces together: temp sensor, cam, light sensor.
During development, we didn't use all parts together - only the relevant sensor, to rule out errors.
Everything worked fine after starting the Pi, but the cam stopped capturing after some minutes... frustrating.
So again we tried to find an error without detailed information and without logs. We thought it might be a module loading problem and found some hints: https://github.com/raspberrypi/linux/issues/435. But nothing worked for us. The only working solution was: disable the device tree 
The whole system is up and running for some days and there we no problems.
We currently don't know what's the problem with the device tree or what we should configure to avoid problems, but if you have similar problems, this posting could help. If you have a working solution with the device tree... leave a comment 
RSS-Feed