I2C bitbanging ?

[doublehp]

Hello.

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.

http://kedei.net/raspberry/raspberry.html
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).

[joan]

This isn't quite what you want but may be close enough.

http://abyz.co.uk/rpi/pigpio/pigs.html#BI2CZ

[doublehp]

Joan, thank you. It does the job.

I will have to write wrappers, and change a few things, but it's in the scope of what I can do.

I was very stupid; I forgot to put pullup on SCL. But even with the pullup, my code still does not work:

Code: Select all

root@rpi:~# ./i2c.sh
* 0x27 : ok
* 0x48 : NOPE
* 0x72 : NOPE
* 0x73 : NOPE
* 0x74 : NOPE
* 0x75 : NOPE
* 0x76 : NOPE
* 0x77 : NOPE
* 0x78 : NOPE
* 0x79 : NOPE
* 0x27 : ok
root@rpi:~#

while your pigpio does the job. Here are main steps; documentation was confusing to me at start.

In a seperate console, start the daemon:

Code: Select all

root@rpi:~# pigpiod
root@rpi:~#
# or
root@rpi:~# pigpiod  -g
# to keep it foreground

Then, in an other console, here are main steps to communicate with 9803:
root@rpi:~# pigs bi2co 30 31 5000
root@rpi:~# pigs bi2cz 30 "0x04 0x4b 0x02 0x07 0x01 0x00 0x02 0x06 0x02 0x03"
2 18 0
root@rpi:~# pigs bi2cz 30 "0x04 0x4f 0x02 0x07 0x01 0x00 0x02 0x06 0x02 0x03"
2 19 0
root@rpi:~# pigs bi2cc 30
root@rpi:~#

In this illustration, I open I2C bit banging on GPIO 30(SDA) and 31(SCL) at low speed, and read 2 bytes at address 0x00 on chips 0x4b and 0x4f. There seem to be a few problems with this: I have the feeling it's returning less bits that I want; not sure if this is a bug in pigpio, my souvenirs of the I2C bus, or the specifics of the 9800, but to get really two bytes, I need to read 3:

Code: Select all

# pigs bi2cz 30 "0x04 0x4b 0x02 0x07 0x01 0x00 0x02 0x06 0x03 0x03"
3 18 0 1

and this is temperature 18.0°C

Code: Select all

# pigs bi2cz 30 "0x04 0x4b 0x02 0x07 0x01 0x00 0x02 0x06 0x03 0x03"
3 17 128 1

this is probably 17.5°C.

... and values are returned as decimal; very strange it takes hexa as input, but pushes decimal as output; maybe there is an option to change this behaviour. No time to dig this aspect now.

[joan]

You can also bit bang with a kernel module on any spare GPIO. This would normally be the best option.

Add the following line to /boot/config.txt and reboot.

dtoverlay=i2c-gpio,i2c_gpio_sda=18,i2c_gpio_scl=19,i2c_gpio_delay_us=5

Replace 18/19 with the GPIO you want to use for SDA/SCL.

This will create a device called /dev/i2c-3 which can be used with all the standard software (e.g. i2cdetect etc).

[doublehp]

I will try your solution tomorrow, but:
- i could not find in google a trivial tuto like the one you just gave me
- depending on how far KeDei disabled stuff in the kernel config, your solution may fail as well.

But for community archives, I will give it a try.

[doublehp]

I was 100% convienced the test would fail, and I would come back here to say you were wrong.

You were right:

# tail -n1 /boot/config.txt
dtoverlay=i2c-gpio,i2c_gpio_sda=30,i2c_gpio_scl=31,i2c_gpio_delay_us=5
# ls /dev/i2c-3
/dev/i2c-3
# i2cdetect -y 3
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- 27 -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- 4b -- -- -- 4f
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

So, dtoverlay works even with KeDei I2C LCD screens.