Tag Archives: i2c

Odroid W ADC Fail!

2 days and 5 forum posts later and the picture is clearer. Let’s start from the beginning. To simplify I’ll refer to the Raspberry pi rev. 2 board and ignore rev. 1 and the A+/B+ (** check the notes for details).

The Raspberry pi has the i2c-0 and i2c-1 busses. The former** is used by the GPU to talk to the camera while the latter can be used by the user however she/he wants. Each of the 2 busses can be redirected to several physical pins by changing the mode of these pins:

GPIO 0/1  – ALT0 mode
GPIO 28/29  – ALT0 mode
GPIO 44/45 – ALT1 mode

GPIO 2/3 – ALT0 mode
GPIO 44/45 – ALT2 mode

Only one of these pairs can be activated at any moment per bus.

The camera is physically connected to GPIO 0/1 **. These pins are setup as inputs by default and the GPU will change them to ALT0 whenever it needs to talk to the camera but _switches them back_ to INPUT immediately after. If you monitor the mode of GPIO 0/1 you’ll see that most of the time they are INPUT with random switching to ALT0 0-30 times per second. It seems that the more movement the camera sees the more it talks to the GPU. It seems to be related to AWB and shutter speed.

So far – no problem. It’s pretty clear from the design of the Raspberry pi that i2c-0 is off limits and there is no way to synchronize the GPU access with the CPU – so i2c-0 cannot be shared between the camera and any other device. If one attempted to use i2c-0 and started ‘raspivid -t 0’ he would see weird things ranging from i2c errors, the image freezing for seconds, random noise on the screen or even the board completely freezing.


The OdroidW has a nice PMC 5t619 chip that provides 2 free ADC pins that I intended to use to monitor voltage and current of silkopter. The PMC uses i2c-0 to talk to the CPU so care must be taken to synchronize somehow with the GPU. This is what I’ve been trying to achieve the whole weekend…

– 1st  try: After every use of mmal I switched GPIO 1/2 mode from IN back to ALT0 so I can talk to the PMC. Didn’t work as it seems the GPU uses the bus even between calls to mmal (in hindsight it makes sense as the camera has to inform the GPU about starting and finishing transfers and the GPU has to set awb, gains and shutter speeds).

– 2nd try: Use a semaphore to trigger the ADC measurement in the mmal callbacks – hoping that after the callback I get a period of silence from the GPU. No such luck

– 3rd try: Give up using the hw i2c-0 bus and try bitbanging on GPIO 0/1. This was such a nice idea – let the GPU use the hardware i2c-0 bus and I’ll use bitbanging… Didn’t work as both the GPU and the PMC are connected to GPIO 0/1 pins – so they share the same physical pins….

So basically it looks like the OdroidW is not capable of using both the camera and the PMC at the same time because they share the i2c-0 bus but _also the pins_!!!. This could have been easily avoided by putting the PMC on some other GPIO and bit banging, or at the very lease putting it on i2c-1.

So now I’m back to the drawing board and started considering an Arduino mini board as ADC + PWM generator. Connected through i2c-1 probably..



** Rev.1 boards have i2c-0 and i2c-1 reversed. So i2c-0 is free while i2c-1 is the camera one. ** A+ and B+ have the camera using GPIO 28/29 pins to access i2c-0.


Odroid W ADC

One of the advantages of the Odroid W is that is has 2 onboard ADCs that are perfect for the current/voltage sensor. They support up to 2.5v max while the AttoPilot 90A/50V goes to 3.3v max. This reduces the range to 67A and 37V which is more than enough for the 50A silkopter will use at max throttle.

Hardkernel provided a Raspbian image with the modules needed to get the 5T619 chip functional – including the adc – but when I tried it a few weeks ago the mpu9250 was getting regular bus errors and even kernel panics.

A few days ago I decided to test some more on a raspberry pi model A, to eliminate any unknowns from the odroid w board. So I connected a SRF02 sonar to i2c-0 to simulate the 5T619 and the mpu9250 to i2c-1. Simply trying to talk to both of them resulted in kernel panics. After 2 evenings of debugging it turns out that the hardkernel raspbian kernel had combined transactions turned on and the i2c-bcm2708.c kernel module has an issue with combined transactions if one or both of the busses has heavy traffic. I managed to find the bug – a small one actually – and the kernel panic was gone.

So I could talk to the mpu and I could talk to the sonar and also the adc chip on the odroid board.

However, as soon as I started raspivid or raspistill – or anything using the camera – i2c-0 stopped working even after killing the process. Turns out that the GPU makes use of the i2c-0 to talk to the camera and it changes the SCL.0 and SDA.0 pins from ALT0 to IN. And it leaves them like that until a reboot or I manually change them back…

So now I have the ADC working, the camera working as well but not both together. My only chance is to change the i2c-0 pin mode back to IN after every call to mmal and hope the camera doesn’t use the bus between mmal calls. Hopefully this will fix the issue but it’s a very ugly hack.

At least I have ADC working, the battery module committed in the brain and integrating the battery capacity from the current readings.

Next I want to autodetect the number of cells in the battery and estimate the capacity at startup.

Also it would be nice if the ground station detected when the battery was replaced and ask for the capacity of the new one.