Closed MichaelJonker closed 4 years ago
The BRZO_I2C library was specifically written for the ESP8266 and predates the ESP32. So on the ESP32 there is no need to use the BRZO_I2C library (this should be clarified in the readme).
This whole library was written when there was no ESP32 so the documentation is written with only the ESP8266 in mind (in most cases at least).
For the performance difference on the ESP8266 you can have a look at this video.
Hi, thanks for your reply and clarifying the origin of brzo.
Indeed, it would be a very good idea to explain this explicitly in the readme, header files and examples.
I joined the ESP crowd with the esp32 and I am unfamiliar with the details of esp8266 (and I would not mind to remain ignorant in this matter). However, when investigating your example, I also investigated the brzo_i2c option (curiosity and lured by ‘false’ promises of speed). When I understood brzo I was a bit surprised, (most chocking was, disabling interrupts and not respecting the primary disabled interrupt level when re-enabling the interrupts before returning). Although I learned from the exercise, I still think you can avoid quite some confusion (if not frustration) to many ignorant esp32 users, by making this clear in the readme/headers/examples.
Thanks!
From: FWeinb notifications@github.com Sent: 13 May 2018 18:23 To: ThingPulse/esp8266-oled-ssd1306 esp8266-oled-ssd1306@noreply.github.com Cc: Michael Jonker michael.jonker@cern.ch; Author author@noreply.github.com Subject: Re: [ThingPulse/esp8266-oled-ssd1306] Is the BRZO_I2C library really faster and better than Wire ?? (#200)
The BRZO_I2C library was specifically written for the ESP8266 and predates the ESP32. So on the ESP32 there is no need to use the BRZO_I2C library (this should be clarified in the readme).
This whole library was written when there was no ESP32 so the documentation is written with only the ESP8266 in mind (in most cases at least).
For the performance difference on the ESP8266 you can have a look at thishttps://vimeo.com/168362918 video.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/ThingPulse/esp8266-oled-ssd1306/issues/200#issuecomment-388638590, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AJdhEiBRP82qFsICA25HE77kGygSF2kbks5tyF3OgaJpZM4T6Bdd.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Hello, I am very impressed by the oled library you have made available, nice product!
I have a question related to what you write about Hardware Abstraction.
I strongly doubt that (at least nowadays in the ESP32 environment) the BRZO_I2C is as brzo (fast) as you claim. The BRZO_I2C is a software implementation of the I2C protocol (with all its tiny wait loops and bit checking coded in assembly instructions), whereas Wire.h is an interface to the ESP32 hardware access layer (device driver) esp32-hal-i2c.h. The later directly interacts with the embedded I2C hardware device on the ESP32. This should makes the Wire.h implementation much faster and immune for external interrupts (without blocking them!), as all the tiny wait loops and bit checking is now done through logic baked into the silicon of the ESP chip. (Possibly there may be opportunities to improve the performance of your library by directly interfacing to esp32-hal-i2c.h as it allows messages up to 32 bytes).
I am unaware if such a hardware I2C device exists on the ESP8266, and if not, the BRZO_I2C might be an interesting contribution for that environment. However, unless I have overseen some important arguments (as I did not do any implementation checks), Wire.h is the option to recommend (at least for today’s ESP32 environment). You may save your users some frustrations due to missing interrupts.
Best regards
Michael Jonker