I have a few I2C probes, and they stopped working after some update. I used to use official Raspbian, but I am not trying to use a KeDei screen on my rPi-v1.
works fine, as long as you don't need I2C.
All I2C pins seem to refuse to move, even when using the GPIO interface.
So I have moved my physical I2C bus to GPIO 30 and 31. Now, those pins work fine as GPIO.
I have grabbed a very old I2C bit banging bash script I wrote years ago, and now test it on my setup. Being a bash script, it's slow.
Here is a selective scanner:
* 0x27 : ok
* 0x48 : NOPE
* 0x72 : NOPE
* 0x73 : NOPE
* 0x74 : NOPE
* 0x75 : NOPE
* 0x76 : NOPE
* 0x77 : NOPE
* 0x78 : NOPE
* 0x79 : NOPE
* 0x27 : ok
So, my script can find the chip 0x27 (expander), but now the two temperature probes (9803) I have around 0x72 and 0x74. Frogot who 0x48 should be; not sure the chip is plugged around.
0x27 is the proof that my script respects the I2C standard, and sends correct signals, and does a proper bus reset before trying a new address. I think the temp probes refuse to ACK because my script is too slow. This small test against 11 adresses takes 4.4s.
Who can provide me a software I2C bit banging, usable from shell ? The app can be any language, as long as, later, I can call it from bash scripts. Here is an example of use, in my parent scripts:
Code: Select all
printf -v add %x $((72+$1)) i2cdetect -y 1 0x$add 0x$add | grep -e "--" >/dev/null && return 1 val=$(/usr/sbin/i2cget -y 1 0x$add 0x00 w)
It's easy for me to grep for similar calls, and update by code; as long as the new app can completely be called from a bash script (some API require full immersion, for example, inside a perl or python code - I can't do that).