Adding a hardware real-time-clock to the GoPiGo?

GoPiGo
1

Greetings!

One of the new “toys” I bought for Charlie is an Adafruit hardware RTC module for the Pi. They come in two varieties, ones with female headers that push down on the first six GPIO pins, and ones with open solder holes that can be placed where convenient and wired to the i2c buss.

There are also “plain vanilla” and “high precision” varieties.

The main reason I want to do this is so that - among other things - my logs make sense. As it is, especially in DexterOS, the dates/times in the logs are meaningless which makes the data virtually impossible to analyze in any meaningful way.

Question 1:
What i2c addresses are used by the GoPiGo and it’s associated add-on boards, such as the IMU board or the distance sensor? The Adafruit hardware RTC boards use 0x68 as their i2c address - will that conflict with anything on the GoPiGo?

Question 2:
Though I am sure I could make this work in Raspbian for Robots, has anyone tried implementing a hardware RTC in DexterOS?

Thanks!

Jim “JR”

2

The IMU uses: (https://github.com/DexterInd/DI_Sensors/blob/master/Python/di_sensors/BNO055.py)

ADDRESS_A                   = 0x28
ADDRESS_B                   = 0x29

The TOF Distance Sensor uses 0x2A
(https://github.com/DexterInd/DI_Sensors/blob/master/Python/di_sensors/VL53L0X.py)

 # The I2C address is software programmable (volatile), and defaults to 0x52 >> 1 = 0x29.
    # __init__ changes the address (default to 0x54 >> 1 = 0x2A) to prevent conflicts.
    ADDRESS = ADDRESS_DEFAULT

    def __init__(self, address = 0x2A, timeout = 0.5, bus = "RPI_1SW"):

Thank you for mentioning I2C address 0x68. I thought I recognized that address, it turns out to be the same address the MPU-9250 IMU uses. I bought the 9250 IMU because it is $8.50 and received a slightly better review than the BNO055 of the DI IMU, but I had a typo (0x6B) instead of 0x68 that I have been chasing for an hour this morning. To save $20, I will probably have to spend a month writing the GoPiGo3 interface.

1 Like
3

So, the IMU used 0x68? That’s bad. That’s what the RTC is programed to use, baked into the kernel. Can it be reprogrammed to use a different, non-conflicting address?

4

Yes, there is a jumper on this MPU-9250 board to move it to 0x69, but early results make me wary of investing much time into it.

1 Like
5

Why? Does it cause problems?

I, myself, would be wary of using an i2c address that is already allocated as a standard address for something else and baked into the kernel all the way back to the kernel maintainers.

6

Oops! Re-reading your post, I realize that you are using a different IMU board.

Can you please re-type the i2c addresses? The code blocks truncate the lines - at least on my phone. . . . :roll_eyes::face_with_symbols_over_mouth:

7

Your (the DI IMU) uses:i2c 0x28 and 0x29 (from the code),
and I know the DI Distance Sensor uses 0x2A (from code and using i2cdetect -y 1 on mine)

1 Like
8

So, the IMU and the distance sensor have conflicting i2c addresses? Are they incompatible or do they resolve the conflict somehow in software?

9

No, I can’t type hex today. 28 and 2A - no conflicts

1 Like
10

Maybe this should be a separate posting, but it seemed relevant here too:

Adafruit sells an i2c address multiplexer that allows you to place more than one device with the same address on the same i2c buss.

11

While I haven’t tested this, I know you can put the IMU in one of the AD Ports, which puts it in a different I2C bus than the Pi default. So there would be no conflict.
To be tested, though.

1 Like