INTERPRETING THE OUTPUT
Each cell in the output table will contain one of the following
symbols:
· "--". The address was probed but no chip answered.
· "UU". Probing was skipped, because this address is currently in use
by a driver. This strongly suggests that there is a chip at this
address.
· An address number in hexadecimal, e.g. "2d" or "4e". A chip was found
at this address.
My understanding is that the bcm2708 is at address 0x40, which is what your output shows.
You may have to compile your own module for the bcm2708.
For the MPU-6050, the address should be 0x68 or 0x69, which doesn’t appear in your table above. You will probably need to check the voltage, and make sure that the clock and data lines are connected correctly. The correct voltage is dependent on how the breakout board is setup.
obj-m += i2c-bcm2708.o
all:
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
clean:
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean
Now i have an error during compilation when #include <linux/module.h> :
make -C /lib/modules/4.4.15-tegra/build M=/home/nvidia/Documents/BCM2708 modules
make[1]: Entering directory '/usr/src/linux-headers-4.4.15-tegra'
CC [M] /home/nvidia/Documents/BCM2708/i2c-bcm2708.o
In file included from ./arch/arm64/include/asm/sysreg.h:23:0,
from ./arch/arm64/include/asm/cpufeature.h:13,
from ./arch/arm64/include/asm/hw_breakpoint.h:20,
from ./arch/arm64/include/asm/processor.h:33,
from ./arch/arm64/include/asm/spinlock.h:21,
from include/linux/spinlock.h:87,
from include/linux/seqlock.h:35,
from include/linux/time.h:5,
from include/uapi/linux/timex.h:56,
from include/linux/timex.h:56,
from include/linux/sched.h:19,
from ./arch/arm64/include/asm/compat.h:25,
from ./arch/arm64/include/asm/stat.h:23,
from include/linux/stat.h:5,
from include/linux/module.h:10,
from /home/nvidia/Documents/BCM2708/i2c-bcm2708.c:25:
./arch/arm64/include/asm/opcodes.h:5:43: fatal error: ../../arm/include/asm/opcodes.h: No such file or directory
compilation terminated.
Mmm, I don’t think that’s right. You will need to compile either the Invensense MPU devices or maybe the Invensense MPU6500 module in the Jetson kernel sources and install it. I don’t have experience with that device to say which one it is. After you compile the module, you will have to install it.
You may also have to run any application using the module using sudo if you don’t have a udev rule for permissions.
There may not be a mpu6050 module? If you can talk to the i2c bus directly, you could talk to it straight from the user mode.
If i2cdetect doesn’t find it, then one of the following is true:
the MPU6050 is broken
the MPU6050 is not getting powered
the MPU6050 uses different voltage than the Jetson (3.3v vs 1.8v can be a problem, depending on options/jumpers)
the MPU6050 runs at a slower i2c max clock than you’re using on the Jetson
the MPU6050 is not connected with correct pull-ups
you’re talking to the wrong i2c bus on the Jetson and the MPU6050 is connected to another bus
the GPIO pins are not configured to output the I2C signals
Depending on which of those are the problem, you will need to do different things to fix them.
I’d recommend hooking up a logic analyzer to the I2C bus and ground when doing the i2cdetect, to make sure you actually see the clock/data wiggle correctly.
Once you can make sure that happens, you can start debugging the actual communications protocol.
A good logic analyzer for hobby and semi-pro work is the Saleae Logic series. I started with their cheapest option (when it was $89) and have kept upgrading until I now have the Logic Pro 16. For a beginner, the $109 Logic 4 is probably sufficient – it lets you debug one SPI or two I2C or two UART at the same time.
The reason I like the Logic is that the software Just Works, and is very easy to use, and the devices are robust. There are cheaper options from China, and more complex options from various technical vendors, but I’ve found them to be harder to use and less robust.