search

BusPirate / Bus_Pirate

Community driven firmware and hardware for Bus Pirate version 3 and 4
625 stars 130 forks source link

3WIRE clock is not correct. #111

Open USBEprom opened 5 years ago

USBEprom commented 5 years ago

By testing 3WIRE protocol with the new firmware U_1-28102018 I built (http://dangerousprototypes.com/forum/viewtopic.php?f=28&t=8498&start=105#p67796) I found the same issues as for I2C SOFTWARE protocol. By choosing ~5KHz, ~50KHz or ~100KHz, does not matter what of them, the 3WIRE clock is alway about ~700Hz, while by choosing ~400KHz it is about ~200kHz that is the half of the value set.

23

39

USBEprom commented 5 years ago

@ChristopherSamSoon

thank you very much sir for your invaluable code!

@ALL About this I must write that I am not 100% sure it totally works now because I tested 3-WIRE protocol in an unorthodox manner. Surely the things ar better with the new code and for 3-WIRE where ~5kHz and ~50kHz are the same as for I2C, but ~100kHz and ~400kHz are respectively ~80kHz and ~170kHz. I tested the 3-WIRE behaviour simply entering in the protocol and sending 1hex while connected to the same Arduino on which was running the I2C sketch provided by agatti and then acquiring the traffic with the logic analyzer setted for I2C decoding. Maybe that did the result, maybe did not, but I do not know other way to test the matter. However I would dare to say that even #111 has now gone, although I will furthermore dig the matter.

ChristopherSamSoon commented 5 years ago

@ChristopherSamSoon

thank you very much sir for your invaluable code!

@ALL About this I must write that I am not 100% sure it totally works now because I tested 3-WIRE protocol in an unorthodox manner. Surely the things ar better with the new code and for 3-WIRE where ~5kHz and ~50kHz are the same as for I2C, but ~100kHz and ~400kHz are respectively ~80kHz and ~170kHz. I tested the 3-WIRE behaviour simply entering in the protocol and sending 1hex while connected to the same Arduino on which was running the I2C sketch provided by agatti and then acquiring the traffic with the logic analyzer setted for I2C decoding. Maybe that did the result, maybe did not, but I do not know other way to test the matter. However I would dare to say that even #111 has now gone, although I will furthermore dig the matter.

3-WIRE mode involves additional arithmetic and an additional read operation in between clock cycles. This slows down the software and it's effect is not accounted for when specifying the delay parameter to bp_delay_us(). This is why you are seeing a speed reduction at 100kHz, and 400kHz (remember that at 400kHz, the software does not introduce any delay, and for I2C mode, the max speed achievable was 240kHz (#23), whereas for 3-wire it is only 170kHz.

Based on calculations, the extra delay for the read (performs a function call) and arithmetic operation is about 2us (1/80kHz - 1/100kHz). 2us is about 32 instruction cycles at 16MIPS. 32 instruction cycles is what we would expect for the extra read operation and arithmetic logic for 3-WIRE.

USBEprom commented 5 years ago

@ChristopherSamSoon

Thank you sir for the very useful explanations you provided, now the matter is much more understandable. However aware of the limits you have explained I have customized my firmwares by changing the message ~400kHz with ~240kHz even if in reality above all the 3-WIRE protocol has more stringent limits. Thanks.

USBEprom commented 5 years ago

https://github.com/BusPirate/Bus_Pirate/issues/131?_pjax=%23js-repo-pjax-container#issuecomment-529147061