Hello, all.
I’m trying to use the Build Hat to control a Lego motor using the vl53l1x laser range finder attached to GPIO pins 1,3,5,7,9. I have confirmed that the Build Hat can control the motor and that the vl53l1x works as expected, but when I try to use them at the same time, only one will work. Looking at the documents for the Build Hat, I see that it uses GPIO4 for reset. But GPIO4 is GPIO pin 7, to which ‘INT’ of the vl53l1x is connected, so I suspect this is the problem. Assuming I’m right, I have two questions. 1. GPIO4 is labeled ‘GPCLK0’ in the pinouts that I have seen. Is there something special about GPIO4 or could the vl53l1x driver be altered to use a different GPIO pin for ‘INT’ of the vl53l1x? 2. If so, does anyone have any experience of this? I’ve had a look at the Python files for the vl53l1x but haven’t yet spotted anything that appears to refer to ‘INT’ or GPIO4.
Thanks, Poja.
This is the old “pin numbers aren’t GPIO numbers” confusion, I’m afraid. Your range finder is using physical pins 1,3,5,7,9, which are GPIO 2, 3 and 4, plus power and ground. That conflicts with the Build Hat, which wants GPIO4 for RESET.
From the look of the range finder pins, I’m assuming it’s just an i2c device so you should be able to remap it - what device is it, so that I know I’m looking at the right Python (not that I’m very good with Python, but I might be able to point you in the right general direction…)
Hello, ahnlak and thank you for getting back to me so quickly.
The device is Pimoroni’s vl53l1x Time of Flight Sensor Breakout - VL53L1X Time of Flight (ToF) Sensor Breakout - Pimoroni.
Apologies if I’ve misunderstood your question: from your reply it sounds like you’ve had a look at the pinout of the vl53l1x - is ‘device’ a setting on the RPi that you’re after?
Thanks,
Poja
I was mostly just looking at the pins it wanted; i2c devices have a very familiar set of pins :)
So, the Python library looks like it will happily accept using a different i2c bus - in the examples:
tof = VL53L1X.VL53L1X(i2c_bus=1, i2c_address=0x29)
Means you can change the first parameter to use an alternate bus. Unfortunately, although the Pi does have bus 0 (on GPIO 0/1), that will also clash with the build hat.
I know that in theory you can drive i2c through any pins, but I confess I’m wildly outside my limited knowledge there - so I’m afraid all I can say is, it’s probably possible but I don’t know exactly how to do it!
OK. Thanks very much for the time that you’ve spent on this, Pete.
It’s useful to know that it’s theoretically possible to use another pin.
I might have tracked down the fellow who wrote the driver so I’ll see if he has any suggestions.
Failing that, I’ll get rid of the build hat and just use the LRF and a servo.
With best wishes,
Adam
It’s a shame that hat doesn’t break out an i2c interface somewhere, given that it hogs pins for both the primary and secondary buses - but I’m not a hardware engineer so maybe there was a good reason :-)
I think the way its supposed to work is,
If you say GPIO 2 that’s referring to the BCM GPIO number.
If you say Pin 3, that’s referring to the Physical Pin number.
It can be confusing.
The official Pi Foundation Hats use i2c 0 to read the Hat EEPROM. And if you were to follow the published guidelines for Hat creation, all Hats should too. Not many do though.
Raspberry Pi Documentation - Build HAT
GPIO Use Status
GPIO0/1 ID prom
GPIO4 Reset
GPIO14 Tx
GPIO15 Rx
GPIO16 RTS unused
GPIO17 CTS unused
Yeah, the trouble here is that i2c0 is taken up for the eeprom read, and i2c1 is blocked by the hat using GPIO4 for it’s reset.
I you know that theoretically drive stuff through other pins, but no idea if you have do do something special to make that work…
My post was meant as a general info post, for anybody reading this thread.
@ahnlak your one of the sharper tacks around here. ;)
Hats like the sense hat can be setup via a dtoverlay entry in the config.txt file.
- sudo nano /boot/config.txt
- Add the following line: dtoverlay=rpi-sense
Do the above and you can use i2c 0 for other things, as far as I know anyway. It’s what they do when its not detected automatically because something else is using those pins.
There likely is also one for the Build Hat? I didn’t find it in my searches though.
If it was me I’d repurpose i2c 0 and see what happens. You can always go back if it doesn’t work.
Of course, I’m completely overthinking this - surely if the eeprom read is over i2c, couldn’t you just use i2c 0 for the LRF at the same time?
Morning, both.
I’ll try using i2c 0 and let you know how I get on. Pete didn’t sound very optimistic about it in 3/10 but I agree it’s worth a try.
Have a good day,
Adam
I wouldn’t get too disheartened by my lack of optimism; I was very aware that my hands on experience around hats and i2c co-existence is very limited and didn’t want to give you (ironically) false hope!
The thing to remember is that literally the intended purpose of the Pi is for you to feel free to poke around and try stuff to see if it works.
Pete, Kerry,
I suggest we end this discussion here so that this message is at one end of the thread.
The ‘INT’ input connected to GPIO04 was definitely the problem as I’ve just disconnected it and both the range finder and the controller work together now. It turns out that vl53l1x doesn’t need its ‘INT’ input in normal use. So in the (admittedly unlikely) scenario that you need to use the Build Hat and the vl53l1x together, just leave the ‘INT’ input of the vl53l1x disconnected.
Thanks, both, for your suggestions,
Poja.