RPi Zero and I2C Clockstretching

[milito]

So I tried it now with higher baudrate uo tp 100 000 Baud = 100 KHz and I had no errors with your bitbanging library.
Thanks a lot for your help.

I have two questions: 1. I saw that your library supports maximum 500 000 baud so that means max. 500KHz, do you know what is the maxiomum baudrate for i2c of the RPi zero?

2. I tested it with the bauds (50000, 100 000 and I saw that there are a lot some stretched signal (see Picture for 100 000 baud, but the reading is correct.)
It does mean that this Bitbanging method supports clock stretching?

Because before I tried this i decreased the baudrate in the Rpi settings in the i2c.conf file and the question is know, should I change the settings again there its set to 50Baud or with the cmd pi1.bb.i2c_open(4,5,100000) its enough?
Because how i understood it this i2c.conf is fpr the hardware I2c in pins 2 and 3 and emulated ois different right?

[joan]

The maximum achievable bit rate is down to your hardware. The standard I2C fast bit rate is 400 kbps. I understand this is chosen because of signal rise times and capacitance issues. I'm not an electronics person so don't know if these factors would apply to your set-up.

Be aware that this bit banging is done in software. This matters most because the timing between bits is software timed. Once the bit time is less than 100 µs (a bps of 10k or greater) the timing is done by busy spins. So in effect once you are using a speed of greater than 10kbps you are using 100% CPU. The result is it's most efficient to use the highest bit rate you can (to finish the transaction as fast as possible, and free the CPU).

The software is designed to clock stretch. I have not tried to test whether it actually does or not, but various people have said is does clock stretch properly.

[milito]

Hi ok thanks a lot , that means its better to use 500 000 baudrate to finish as fast as possible so that the cpu is not busy correct?

i tried other measurements and the result is write so 0x28 , Write, 0x3D and 0x0C but on the picture I see a strange behavior of the clock line there is a tick that is too long, normally this shouldn't be like this right ?

[joan]

Yes, once you want to go faster than 10kbps you might as well go as fast as you can.

Clock stretching is achieved by the device holding SCL low. The long signal you see is with SCL high so it's not a clock stretch. It will be the result of a Linux reschedule during the bit delay busy spin.

[milito]

ah ok but normally it shouldnt influence the communication right? Iam learning a lot from you thank you.
Why Iam asking is because normally the clock ticks should be equal. To understand what are you meaning with linux reschedule bit delay?

[joan]

No, it will not affect the communication. The communication is timed solely by the SCL line. The slave device will wait until it is in the correct state.

If Linux needs to service a piece of hardware or another program it will suspend pigpio. What you are seeing is when that suspension happens when pigpio is holding SCL high (the line will stay high until pigpio is taken out of suspension).

[milito]

OK thanks. What i saaw is when i increase the baudrate, this suspension happens more frequently , and Iam wondering why? - Because normnally I am faster to and the cpu should be in idle state faster than with a lower baudrate?

[joan]

OK thanks. What i saaw is when i increase the baudrate, this suspension happens more frequently , and Iam wondering why? - Because normnally I am faster to and the cpu should be in idle state faster than with a lower baudrate?

I agree with your thinking. What sort of transactions are you doing? How long in read/write bytes and how often per second? What else are you doing in the background? Are you still using the Pi Zero.

[milito]

Iam running the skript with the writing command in I2C (bitbanging) and then I have connected my RPi Zero to the Internet via a Ethernet cable, and i have openend the directory where the the command script for i2c is and the console is openend, where the script is running.
I have an sd card where the OS is running.

These are the transactions in the phyton srcipt that Iam doing:
pi1.bb_i2c_open(4,5,100000)
pi1.bb_i2c_zip(4,[4,bno055_address,2,7,2,bno055_op_reg,bno055_NDOF_MODE,3,0])
pi1.bb_i2c_close[4]

these cmds are in the loop
Could it be because of these things? How I understood you you explained me, that the bitbanging method is done by software, that means when a Hardware task from the OS is coming this has priority?

[joan]

Iam running the skript with the writing command in I2C (bitbanging) and then I have connected my RPi Zero to the Internet via a Ethernet cable, and i have openend the directory where the the command script for i2c is and the console is openend, where the script is running.
I have an sd card where the OS is running.

These are the transactions in the phyton srcipt that Iam doing:
pi1.bb_i2c_open(4,5,100000)
pi1.bb_i2c_zip(4,[4,bno055_address,2,7,2,bno055_op_reg,bno055_NDOF_MODE,3,0])
pi1.bb_i2c_close[4]

these cmds are in the loop
Could it be because of these things? How I understood you you explained me, that the bitbanging method is done by software, that means when a Hardware task from the OS is coming this has priority?

Nothing wrong there. However I would take the open and close out of the loop. They only need to be done at the start and end of the script.

[milito]

Do you mean like this:
pi1.bb_i2c_open(4,5,100000)
while True:
pi1.bb_i2c_zip(4,[4,bno055_address,2,7,2,bno055_op_reg,bno055_NDOF_MODE,3,0])
pi1.bb_i2c_close[4]

?
So its quite normal the behavior?

[joan]

More like.

Code: Select all

pi1.bb_i2c_open(4,5,100000)

try:

while True:

   pi1.bb_i2c_zip(4,[4,bno055_address,2,7,2,bno055_op_reg,bno055_NDOF_MODE,3,0])

except KeyboardInterrupt:
   pass

pi1.bb_i2c_close[4]

I really don't know what normal is in this situation, but if that's what happens then there is not much you can do about it.

[milito]

ok a question you explained me that bitbanging is viasoftware and when the scl line is for long time high it means, that linux give the priority to hardware tasks. Does it mean that HW-task as priority before SW-tasks?

[joan]

ok a question you explained me that bitbanging is viasoftware and when the scl line is for long time high it means, that linux give the priority to hardware tasks. Does it mean that HW-task as priority before SW-tasks?

There is no such thing as a hardware task or a software task on a Linux system.

There are hundreds of software processes running on a Linux system. At any one time (on a single processor system like the Pi Zero) all but one will be sleeping. If a process needs to do some work (e.g. process a wifi message arrived interrupt) then it will be woken up and the current process will be put to sleep.

As a general rule Linux will try to ensure that the highest priority process which has work to do will be the one running. If there is more than one process which has work to do Linux will try to share the CPU time between them.

[milito]

ok thanks fpr the information. I tried the code with the open and close outside the loop and its not working well, i ve got wrong values. I use it inside the loop. In the datasheet its written that after every write access i should send a a sop and terminate the protocoll. Thats the reason because i do it inside the loop.

[milito]

Hi I have a question regarding the Bitbanging, is it possible to scan the i2c bus like i2cdetect to see if all devices are recognized in the bus?

[joan]

Hi I have a question regarding the Bitbanging, is it possible to scan the i2c bus like i2cdetect to see if all devices are recognized in the bus?

I don't remember what i2cdetect actually does.

What you could try is to read one byte from each address. If the read succeeds the device exists, if it fails the device is not present.

[DougieLawson]

i2cdetect has three modes.

Quick mode just does a i2c_smbus_write_quick() call to each address.
Read mode does a i2c_smbus_read_byte() call.
Default does a i2c_smbus_read_byte() for a range of addresses 0x30-0x37 & 0x50-0x5F and does a i2c_smbus_write_quick() to the rest.

If the call works it assumes the address has a device connected. If the call gets EBUSY it assumes the address is in use by a kernel module.

Some of those probes can have a really bad effect on some I2C devices which is why it asks you to confirm that you're stupid enough to run it (-y flag)

The source code is available at: https://fossies.org/dox/i2c-tools-3.1.2 ... ource.html