16x2 I2C Display on Arduino M0 Pro very slow

[NormanSchuetze]

Hi.
I checked out your monochrome display on both boards Arduino Micro and M0 Pro with the same "HelloWorld" example provided by you. There is one big difference which is confusing me! The time how long it takes to display the "Hello world!" message is 43 msec with the Arduino Micro and 2171 msec with the Arduino M0 Pro. Checking the SCL clock speed, the Arduino Micro clock is 200 kHz compared to 360 kHz from the M0 Pro.

I also checked the time between each SCI data package. Using the M0Pro there are ~85 ms between each package while I have measured ~200 µs on the Micro. So it seems, the inter-message time on M0Pro is 400 times greater than Atmega 32U4.

Obviously , only the lcd.write() function is affected by the bug. Looking on the I2C data stream, I can see the I2C communication which belongs to the BUTTON status communication which is very fast.

Since it takes a long time to display information, my M0 projects is jeopardized. But I need the power of the SAMD21 controller.


Do you have an idea why the response time is different?
Thanks

Screenshot from Scope showing the SCL speed and messages

I2CDisplayTimings_on_Arduino_Micro.JPG (124.52 KiB) Viewed 659 times

[adafruit_support_mike]

They're completely different processor architectures with completely different ways of connecting the I2C peripheral to the microcontroller.

A 16x2 LCD is hard pressed to handle 10ms updates though. How does a sub-millisecond delay interfere with what you're doing?

[NormanSchuetze]

Hi Mike.

Thanks for your reply. In your simple sketch "HelloWorld", I can only insert delays between single lcd commads like " lcd.setCursor(0, 1)"... I have checked it but there is no difference.

I am looking for the reason why I have ~80 msec breaks between each communication burst on the SAMD21 compared to the 32U4. Below I have two screenshots of the same function where a counter is rising up each second. As you can see, on 32U4 there are no longer breaks within the communication stream.
Thanks.

HelloWorld_I2C timing Atmega 32U4

HelloWorld_Atmega32U4.png (24.26 KiB) Viewed 612 times

HelloWorld_I2C timing SAMD21

HelloWorld_SAMD21.png (24.47 KiB) Viewed 612 times

[adafruit_support_mike]

Apparently I misread your original post as reporting gaps of 80 microseconds. I apologize for that mistake. 80 milliseconds is a much larger problem.

I just hooked up an LCD Shield to a Feather M0 Proto and scanned the traffic with a logic analyzer. I don't see any gaps larger than about 100 microseconds between I2C transactions.

What version of the Arduino IDE and board support files are you using? There's been a lot of work on the SAMD libraries, and there are all sorts of version compatibility issues. For reference, I'm using version 1.6.9 of the IDE, version 1.6.6 of Arduino SAMD Boards, and version 1.0.13 of Adafruit SAMD Boards.

[NormanSchuetze]

Hi Mike.
Thanks. The tip hits the bull's eye. The problem are the different IDEs from Arduino.cc and Arduino.org! Since I got the M0 Pro, only Arduino.org officially supports the board. (I have already installed the latest IDE version 1.7.10)
The current solution is:
- Install the latest IDE from Arduino.cc - now version 1.6.11
- Install the latest board files - here Arduino SAMD Boards with version 1.6.6
- Install the Adafruit RGB LCD Shield-library
- Choose the Arduino/Genuino Zero board which is nearly similar from hardware point of view and burn the bootloader. (Pin 2 and pin 4 are swapped)
=> So you get nearly a Arduino/Genuino Zero board.
With that hardware and software configuration the response times are faster - same like using 32U4.
By the way: Testing my advanced project with the "Zero", I observed the same bug within the SPI communication using the Arduino.cc IDE. Between each SPI transmission, the interframe delay time was round about 2 ms. I did not observe any relevant idle times using Arduino.cc IDE.

So there must be a huge bug in the SAMD core files. Maybe the SERCOM library.
I think, it is a great pity and confuse users. Two IDEs are existing and they work not synchronously on the bug fixes.
Thank you for testing and checking with your Feather M0. Only with that tip I could solve the issue.

Regards,
Norman

[adafruit_support_mike]

Yeah, we kind of forget arduino.org exists. We're the US manufacturer for arduino.cc hardware, so all our development is geared toward that group.

Glad to hear you got it working!