Camera module blocks access to second i2c bus on port5?

[Joel_Mckay]

Once the second i2c bus is enabled the camera becomes unusable:

Code: Select all

>raspistill -o image.jpg
mmal: mmal_vc_component_create: failed to create component 'vc.ril.camera' (1:ENOMEM)
mmal: mmal_component_create_core: could not create component 'vc.ril.camera' (1)
mmal: Failed to create camera component
mmal: main: Failed to create camera component

1.)
Is it possible to enable the Camera module, and still access the second i2c bus on port5?

2.)
Am I better off bit-banging an emulated Master in software if I currently have a low speed device on bus-0 and 400000 baud capable devices on bus-1 ?
i.e. is there a way to have two different bus bauds defined for the modules...

Cheers,

[jamesh]

Hmmm. We have been discussing this one at work. There should not be any conflict between the camera port and the secondary I2C at all. They are completely separate clocks, dividers etc.

Can I ask what software you are running on the second port? We did have a thought that maybe, if the code was trying to discover which port it was on (in order to distinguish rev1 and rev 2 boards), then maybe that was trashing the I2C for both. But we are still thinking about it.

[Joel_Mckay]

Custom C program to enable io access with the i2c-0 kernel module character device (based on offset noted in this thread). They can work when configured independently, but the camera seems to enter into a resource contention when the port 5 interface is enabled.

For your situation, one could probe i2c-1... then i2c-0 looking for devices, and bind the bus that has the chip addresses of interest. In Rev.2, the i2c-0 bus in the Debian distro appears to act like /dev/null unless explicitly enabled using the chip flags.

In terms of application, the main slave devices we use are PCA9685, and custom chips to handle some other odd tasks. The poll rate is very low, so avoiding the Camera contention issue seems like the only practical solution if people have already attempted to solve this issue and failed.

Thanks,
J

[jamesh]

Custom C program to enable io access with the i2c-0 kernel module character device (based on offset noted in this thread). They can work when configured independently, but the camera seems to enter into a resource contention when the port 5 interface is enabled.

For your situation, one could probe i2c-1... then i2c-0 looking for devices, and bind the bus that has the chip addresses of interest. In Rev.2, the i2c-0 bus in the Debian distro appears to act like /dev/null unless explicitly enabled using the chip flags.

In terms of application, the main slave devices we use are PCA9685, and custom chips to handle some other odd tasks. The poll rate is very low, so avoiding the Camera contention issue seems like the only practical solution if people have already attempted to solve this issue and failed.

Thanks,
J

We've only just had reports of I2C problems, so have no idea yet of what any problem might be. We did wonder if probing each bus was actually causing the problem, but I'm not expert on this, and I think Dom decided the driver didn't do that. We need to investigate further, no idea of timescale.

[tasanakorn]

Hi, jamesh
Do you know how the camera driver accessing i2c port ? Is it access register directly or via i2c driver ?. (I guess, It access i2c register directly because camera can operate without i2c driver)

Might be we have to looking inside camera driver not i2c driver.

Custom C program to enable io access with the i2c-0 kernel module character device (based on offset noted in this thread). They can work when configured independently, but the camera seems to enter into a resource contention when the port 5 interface is enabled.

For your situation, one could probe i2c-1... then i2c-0 looking for devices, and bind the bus that has the chip addresses of interest. In Rev.2, the i2c-0 bus in the Debian distro appears to act like /dev/null unless explicitly enabled using the chip flags.

In terms of application, the main slave devices we use are PCA9685, and custom chips to handle some other odd tasks. The poll rate is very low, so avoiding the Camera contention issue seems like the only practical solution if people have already attempted to solve this issue and failed.

Thanks,
J

We've only just had reports of I2C problems, so have no idea yet of what any problem might be. We did wonder if probing each bus was actually causing the problem, but I'm not expert on this, and I think Dom decided the driver didn't do that. We need to investigate further, no idea of timescale.

[jamesh]

Hi, jamesh
Do you know how the camera driver accessing i2c port ? Is it access register directly or via i2c driver ?. (I guess, It access i2c register directly because camera can operate without i2c driver)

Might be we have to looking inside camera driver not i2c driver.

Custom C program to enable io access with the i2c-0 kernel module character device (based on offset noted in this thread). They can work when configured independently, but the camera seems to enter into a resource contention when the port 5 interface is enabled.

For your situation, one could probe i2c-1... then i2c-0 looking for devices, and bind the bus that has the chip addresses of interest. In Rev.2, the i2c-0 bus in the Debian distro appears to act like /dev/null unless explicitly enabled using the chip flags.

In terms of application, the main slave devices we use are PCA9685, and custom chips to handle some other odd tasks. The poll rate is very low, so avoiding the Camera contention issue seems like the only practical solution if people have already attempted to solve this issue and failed.

Thanks,
J

We've only just had reports of I2C problems, so have no idea yet of what any problem might be. We did wonder if probing each bus was actually causing the problem, but I'm not expert on this, and I think Dom decided the driver didn't do that. We need to investigate further, no idea of timescale.

Camera accesses the I2C via a I2C driver on the GPU. This code is closed source, but the I2C driver on the GPU is a very well tested bit of code. Camera driver itself isn't so well tested - I'll be looking at that when time allows.

[tasanakorn]

Thank you for the hints.

Now, I can work around my problem (Use i2c-1 and camera as same time) by just unbind i2c-0 from linux kernel.

http://www.raspberrypi.org/phpBB3/viewt ... 37#p367237

Camera accesses the I2C via a I2C driver on the GPU. This code is closed source, but the I2C driver on the GPU is a very well tested bit of code. Camera driver itself isn't so well tested - I'll be looking at that when time allows.

[Joel_Mckay]

Camera accesses the I2C via a I2C driver on the GPU. This code is closed source, but the I2C driver on the GPU is a very well tested bit of code. Camera driver itself isn't so well tested - I'll be looking at that when time allows.

It is rumoured a V4L interface is in the development path as well, and I look forward to seeing the projects this will enable. However, the GPU licencing seems to be a recurring issue for several people. I guess it is time for me to look at the errata documents for possible solutions.

Thanks,
J

[AmandaDavies]

In this setup i'm using a Rev 2.0 Pi.
A desktop Power Supply Unit (capable of delivering 5 amps).

I have a HD44780 PCF8574T 20x4 LCD display connected to the I2C bus on pins 3 & 5 of the P1 header.
The display is powered at 5v. 2N7000 MOSFETS are used to do the logic level conversion of both I2C bus wires.
Using "i2cdetect -y 1" I see the LCD on address 0x20. "-y 0" shows all addresses free.
The display software has no memory leaks and is stable. "i2cdetect" always shows just 0x20 present.

If I disconnect the LCD and connect an RPi Camera Rev 1.3, taking stills using raspistill in a loop is stable (I can take photos every 5 seconds for days). "i2cdetect" shows both -y 0 and -y 1 as empty throughout.

When I have both LCD and RPi Camera connected and running, within a second the LCD screen freezes.
Running "i2cdetect -y 1" shows the following:
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
10: 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
20: 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f
30: 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f
40: 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f
50: 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f
60: 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f
70: 70 71 72 73 74 75 76 77

The camera continues to take stills, but the LCD cannot be accessed.
When kill and restart my software I continue to get stills from the camera from raspistill, bu the LCD remains inaccessible, and i2cdetect shows the above.
A "shutdown -r now" fixes it.

Any ideas? (at present I cannot have the camera and LCD working at the same time)

[AmandaDavies]

In this setup i'm using a Rev 2.0 Pi.
A desktop Power Supply Unit (capable of delivering 5 amps).

I have a HD44780 PCF8574T 20x4 LCD display connected to the I2C bus on pins 3 & 5 of the P1 header.
The display is powered at 5v. 2N7000 MOSFETS are used to do the logic level conversion of both I2C bus wires.
Using "i2cdetect -y 1" I see the LCD on address 0x20. "-y 0" shows all addresses free.
The display software has no memory leaks and is stable. "i2cdetect" always shows just 0x20 present.

If I disconnect the LCD and connect an RPi Camera Rev 1.3, taking stills using raspistill in a loop is stable (I can take photos every 5 seconds for days). "i2cdetect" shows both -y 0 and -y 1 as empty throughout.

When I have both LCD and RPi Camera connected and running, within a second the LCD screen freezes.
Running "i2cdetect -y 1" shows the following:
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
10: 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
20: 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f
30: 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f
40: 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f
50: 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f
60: 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f
70: 70 71 72 73 74 75 76 77

The camera continues to take stills, but the LCD cannot be accessed.
When kill and restart my software I continue to get stills from the camera from raspistill, but the LCD remains inaccessible, and i2cdetect shows the above.
A "shutdown -r now" fixes it.

Any ideas? (at present I cannot have the camera and LCD working at the same time)

My problem may be related to /dev/ttyAMA0
I've just found that the LCD freezes exactly when some unexpected data is seen on /dev/ttyAMA0

[spaceharrier]

Did you ever find a resolution to this? I'm looking to drive an Adafruit LCD panel while I have the camera connected as well, but am running into what looks like this same issue.

[jamesh]

I'm not sure there is a fix. At least not with sane timescales.

The problem as I remember it is that the GPU need access to the I2C to talk to the camera. If you start using it from a different driver on the Arm at the same, all hell breaks lose. There isn't an easy fix.

[elpidiovaldez5]

I have been trying to use Rasperry Pi camera V2 with devices on i2c bus 1. I had the i2c working, but I could not get the camera to work (it gave ENOSPC error). I did a complete reinstall of O/S (I am using Ubiquity Robotics sd image of Lubuntu with ROS). Now I can use the camera, but i2c does not detect devices.

I realise this thread died years ago, but it comes the closest of any I have found to explaining my problems. Can anyone tell me whether this issue still persists, and makes it impossible to use i2c devices at the same time as the camera ?

[elpidiovaldez5]

Ok, I've found the answer. Firstly my problem was just a bad connection in the i2c.

Secondly, the clash between Raspberry camera and I2c only affects i2c bus 0, which the camera, display and HAT EEPROM use. It is possible to use i2c bus 0 if you are not using the camera, display and HAT EEPROM. This hardware issue only affects the Raspberry Pi 3 Model B.