I2C - can't find device address
@Zogg-Baubas I am also seeing those false positives when using i2cdetect on my Omega2+, but I haven't yet dug into it or tried to use I2C on mine. I don't know where those false positives come from and it kind of bothers me.
i2cdetect -q -y 0makes them go away, but they shouldn't appear in the first place.
I may take a better look later on today.
I still don't know why i2cdetect fails, but actually using I2C seems to work fine. I've got an I2C LCD-module that I just tested and sure enough, text gets printed on it without an issue. Non-functional i2cdetect is less than useful, unfortunately.
Just a quick word from some of my own frustrated testing with I2Cdetect:
The reason -q causes the false positives to disappear is because -q is "quick write". It tells you this if you leave out -y, since -y removes the prompt that tells you what's going on.
Conversely, you will get nothing but false positives if you instead use -r, which is "read" the first byte of every address to find out who's where.
I think this has to do with how reading from something that isn't there results in 0xff.
If you've managed to get I2C working with your Omega2, I'd be real interested in hearing what your setup is. I'm about two seconds away from giving up on the I2C libraries and just bit banging to figure things out.
@ziger-zigs Actually I had some success with the bit-banging i2c-gpio-custom kernel module. Unfortunately it is not part of the official repo, I had to compile the needed kernel modules myself. I am asking for adding it here.
I used this little script to scan all of the addresses.
for i in $(seq 3 122 )
echo "PORT -- $1 -- "
printf '0x%x' $i
i2cdump -y $1
printf '0x%x' $i
got me a list of the available busses. My bus shows up as
so I ran
The only address that had anything different was 0x3f
Apparently 0x3f is the correct address, but I still am not getting anything to show up on the LCD using the tutorial.
I finally got the LCD screen to run properly from the Python library in the tutorials.
I can't say I had to change anything. I did have to adjust the voltage (err contrast? brightness?) on with the potentiometer on the back of the LCD. It was set either too high or too low. I thought I had adjusted it before, but apparently everything wasn't lined up. This last time around, I had SCL plugged into 19 and SDA into 20. I will go sit in a corner later.
Changes to the Tutorial that I had to discover.
- opkg install ca-bundle (to install the certificate bundle to let git work right)
- The script I used above to help me find the right address, but the address was the same as in the documentation from the gentleman who made the library.
- The script fails if you don't add the address.
python lcd.py --line1="HELLO WORLD" --line2="LET FREEDOM RING!" --address=0x3f
is what worked for me.
- Adjusting the brightness with the blue Trim Pot (Trimming potentiometer) after something has been written to the screen.
Hope this helps someone. I ran around in circles for quite awhile.
@Brad-Tittle Thanks for this, Brad ... saved me a bunch of time. I didn't get anything on my LCD until
I cranked the contrast pot all the way to its limitI connected the backpack to 5v on the expansion dock (first attempt was with the breadboard dock, which doesn't have 5V). seems like bad design on the backpackthe backpack should be 3v not 5v.
TL;DR: Serial LCD backpack is 5V.
Trying to resolve this on my Omega2+ with the 16X2 LCD, and using your script (Thanks for sharing it!). What could be causing this error when running it?
Thanks in advance.
I am interested in this topic as well. I am trying to get a Si470x to run on the Omega2. On the Pi this was trivially to do.
On the Omega2, I cannot even get the Si470x to show up in i2cdetect. On top of that I also see the false positives.
I am using the Breadboard dock with a massive 3A USB PSU.
Hi @Arne-Schmitz ,
Please try and use "bit-banged" I2C, you may find this post usefull:
I2C Detect Slave Method
@UFD thanks, I will try that. So the i2c implementation really seems to be buggy?