#Wiring looks okay as far as I can tell.

1 messages · Page 1 of 1 (latest)

twilit shard
#

I'm currently running this:

# 
"""CircuitPython I2C Device Address Scan"""
import time
import board

i2c = board.STEMMA_I2C()  # For using the built-in STEMMA QT connector on a microcontroller

while not i2c.try_lock():
    pass

try:
    while True:
        print(
            "I2C addresses found:",
            [hex(device_address) for device_address in i2c.scan()],
        )
        time.sleep(2)

finally:  # unlock the i2c bus when ctrl-c'ing out of the loop
    i2c.unlock()
#

borrowed from here:

#

the output from that is showing:

# 
I2C addresses found: ['0x19', '0x3a']
#

looks like the first one ('0x19') matches up with the accelerometer. I plugged the second one ('0x3a') into ChatGPT and it said that's the LED driver. I was hoping to see an output that corresponds to the STEMMA QT I2C Breakout (apparently that's 0x20) but no luck

#

the power indicator light on the STEMMA QT I2C Breakout is on/green so that looks right

green vessel
twilit shard
#

ugh. good callout. I'll confess I've been lazy since ChatGPT

#

thank you so much

#

really appreciate this

south sierra
#

I have a question if I may butt in. I often see the various I2C scan programs use the i2c.try_lock(), i2c_lock(), i2c.unlock() type commands. My understanding doing a very tiny bit of research is the lock is simply to keep other parts of your code from trying to also access the I2C bus. So why do I rarely see it in, for example, Adafruit learning guides with lots going on but often see it in simple scans where the scan code is so singule purpose there is nothing else to butt in on the I2C bus? Is this some old convention that has simply perpetuated itself into every I2C scan code that no one thought to simply drop?

green vessel
# south sierra I have a question if I may butt in. I often see the various I2C scan programs us...

My understanding is that the i2c.try_lock() is similar to the concept of using while(!Serial.begin(115200)); where we want the code to wait for the bus to be ready before continuing. Most of the other learn guide examples have plenty of other blocking lines of code like larger imports and memory initializations to provide enough of a delay to the rest of the code to not poke the bus before it's actually ready, but the I2C scan is light on extra lines and sensitive to each singular attempt to read what's on the bus.

You COULD potentially use a time.sleep() delay instead, but this is just a cleaner way to ensure the bus is fully ready for action before starting.

green vessel
twilit shard
#

cool! thanks again!