FYI -- a fast i2c implementation in Assembly (brzo i2c)

[pasko-zh]

Hello!

I would like to share this with you: I have implemented an i2c master in (inline) assembly for the esp8266 called brzo i2c. It can be used as an alternative to the wire library. It features:

• Robust implementation with SCL cock stretching support and handling of all those nasty i2c errors
• Clean and exact timing for SCL and SDA, e.g., removal of ACK spike
• Fast mode plus SCL speeds:
  800 KHz @ 80 MHz CPU
  1 MHz @ 160 MHz CPU
• Introduction of i2C transactions: Group any combination of i2c writes or reads together, either with or without repeated start

Further infos are available on the wiki and the library is available here.

The wiki and the code contains many infos/hints around i2c, so I thought it could be useful to you guys. And of course you may use the library :-)

cheers
paško

ps: with some (slight) modifications it will work for the native tool chain, too.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[danxn]

BTW, as I can see onReceive handler disabled in ESP Wire library (https://github.com/esp8266/Arduino/blob/master/libraries/Wire/Wire.cpp#L203-L246) so it is impossible to use nodeMCU in multimaster mode on I2C bus. It will be great if this feature will be available again.

[FWeinb]

Thanks for building this library I made a little comparison video showing the performance of driving a ssd1306 oled display using this library instead of wire library. Have a look here.

[pasko-zh]

Wow, this looks very nice!! Very smooth! So, I am happy it was useful to you!

btw: Hmm, how do you get the current time? Are you using the Time library or the native SDK sntp_ functions? Are you able to adjust for "Sommerzeit" aka daylight saving time? (For another project I want to display the current time, but of course not on such a fance display like you did, instead on an old Split Flap Display from the swiss railways (SBB))

[FWeinb]

Thank you. For this I am using configTime so there is no adjustment for "Sommerzeit".

[hallard]

@pasko-zh, my godness, nice works, thanks for sharing this
@FWeinb nice comparison, would you mind sharing the code of the example ? I love OTA progress bar ;-)

[igrr]

@pasko-zh awesome work, do you think it's possible to make a variant of Wire library based on bzro-i2c? I.e. make API compatible with Wire.

[FWeinb]

I had the same idea it is tracked in pasko-zh/brzo_i2c#1

[pasko-zh]

@igrr Thanks :-)
Yes, it should be possible -- but please allow some time for that to happen.

[d-a-v]

@pasko-zh any news regarding integration in the core ?

[pasko-zh]

@d-a-v I am not involved in the esp core development, thus I cannot give you an answer...

[5chufti]

@pasko-zh

@igrr Thanks :-)
Yes, it should be possible -- but please allow some time for that to happen.

I think d-a-v's question relates to your message quoted above

[devyte]

Given recent I2C slave support integrated into the currennt Wire lib, this requires further investigation.
Removing milestone for now.

[devyte]

@suculent is there any chance you could help with testing this?

[suculent]

Well, I know Brzo and I'm already using it in some project as a replacement of the current I2C lib.
However I don't have much of a suitable testing hwardware (oscilloscope). This is nice work, but I'm currently very busy with drivers for APDU-9900, Network Interface Manager (allowing multiple network connections like WiFi/GSM at once; seamless connectivity switching and shared MQTT client)... not speaking of maintaining whole THiNX.

[devyte]

@suculent The fact that you're using it in one of your projects tells me what I wanted to know 😆
So it's just slave support in brzo before it can be wrapped and integrated.

[suculent]

Indeed, slave support is now required. What we've merged from @bjoham can be happily replaced with Brzo, expecting it will share existing Wire interface.

Reason why I don't use Brzo in all projects is merely interoperability issue with all existing libraries based on Wire. It's great with displays where you need speed, however it gets complicated in cases where I have 60+ I2C devices to manage; 1 master MCU, 3 slave MCUs and a bunch of various adressed peripherals. I don't even speak about the hacks where SDA goes through 16-bit analog multiplexer to devices which do not have configurable I2C address.

[suculent]

Also, I'd look into the Wire.begin() thing. For slave mode it needs both pin and address setting in the initializer... and most of the libs call Wire.begin() itself, which can be an issue.

Wire should be able to act properly, in case it has been already initialized, so the libraries calling just Wire.begin(); do not reset explicit SDA/SCL pin settings or interfere existing callbacks.

[pasko-zh]

Well, I just followed the discussion here and I am of course happy to support you 😄

My other job (aka the job) keeps me quite busy doing many many many power point presenations 😫 thus, my motivation for these topics here is huge... but allow some time for me to answer your questions, it wont be always as fast as brzo_i2c ...

[devyte]

@pasko-zh I'm glad you're here 😄
Essentially, what I would like to do is integrate your great work into our Arduino core as a subrepo, wrap it with a Wire lib interface, and have it accessible to everyone. That would give the best of all worlds, I think, by getting your code to more users and having those users get the fastest implementation.
However, before that can proceed, at least one functional gap has to be closed: I2C slave support, which was added only recently to our current I2C implementation.
One thing that is imminent are some examples for I2C master and I2C slave to have 2 ESPs communicate. With that, we can test using P2P ESPs without external hardware.
Is there any chance you can implement slave support in your code? There is no hurry, so it's ok between powerpoints 😆
Then, your repo is currently licensed as GPL-3.0. That is inherently incompatible with apps that are to be distributed in any way due to the closed source nature of Espressif's libs. In other words, any app that makes use of your code in conjunction with the closed Espressif libs can only be used personally and can't be distributed to others. Is there any chance you can change the license to a more permissive one, or at least provide an exception to re-license your code under our license when built in conjunction with our code?
I'm available on gitter in case you would like to discuss directly.

[pasko-zh]

@devyte Somewhere in between powerpoints this should be possible 😄
Concerning GPL, I have to think again. I have to find a compromise between as free as possible (in the sense of free software) and giving as few "restrictions" as possible. LGPL is certainly a good option.

[phrxmd]

Any news on this? It would be great to see @pasko-zh's work integrated into the core with a Wire lib wrapper.
I've started to port some sensor libraries to brzo-i2c and keep on thinking what potentially unnecessary work I'm doing ;)

[d-a-v]

I am closing this issue.
GPL is still ongoing with this library so there's nothing we can do here.

However documentation on how to use it has been available for more than one year:
https://github.com/pasko-zh/brzo_i2c/wiki#how-to-migrate-from-wire-library-to-brzo-i2c

[suculent]

Hi, I don't have currently time to do that (releasing the project I was using it in). I've also dropped software I2C from my project because of low realiability/scalability and no forward compatibility with multi-core MPUs (ESP32) / I've exchanged that with CAN bus. M.

…

On 1 Oct 2019, at 14:02, david gauchard ***@***.***> wrote: I am closing this issue. GPL is still ongoing with this library <https://github.com/pasko-zh/brzo_i2c> so there's nothing we can do here. However documentation on how to use it has been available for more than one year: https://github.com/pasko-zh/brzo_i2c/wiki#how-to-migrate-from-wire-library-to-brzo-i2c <https://github.com/pasko-zh/brzo_i2c/wiki#how-to-migrate-from-wire-library-to-brzo-i2c> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2055?email_source=notifications&email_token=AABWFR6RRHIQ7VN4BTMGMGTQMM35VA5CNFSM4CE2XA6KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEABAOYQ#issuecomment-537003874>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABWFR6IABO64S4UIRMCJWTQMM35VANCNFSM4CE2XA6A>.