using with alternative to Wire.h or non-blocking I2C communication

[kurogedelic]

I am currently using the U8g2 library to control an SSD1306 OLED display via I2C on a Seeed XIAO (SAMD21).
However, I am experiencing severe blocking issues with the Wire.h library.
This might have been discussed before, but I couldn't find a clear solution.

I noticed that the U8g2 constructor only allows me to choose between hardware (HW) and software (SW) I2C configurations.
I was wondering if there is a way to use alternative I2C libraries, such as I2C_DMAC for the SAMD21, with U8g2 to alleviate the blocking problem.

The blocking issue is causing problems in other parts of my application.
For example, in an audio application, the audio glitches every time the buffer is sent to the OLED.
(audio rate is 48khz, by TC4 hardware timer interrupting)

If anyone has experience using U8g2 with other fast I2C libraries on the SAMD21 or similar microcontrollers,
I would greatly appreciate any insights or suggestions.

Thank you in advance for your help!

[olikraus]

U8g2 for Arduino will just use the existing Arduino Wire. It is the advantage of Arduino to have a common interface but a disadvantage in cases you have special needs.

One solution could be to implement your own low level output with the method used here:

u8g2/sys/arduino/u8g2_page_buffer/I2CLCDBoard/I2CLCDBoard.ino

Lines 460 to 488 in b82f49a

	U8G2 u8g2; // create a plain U8g2 object
	void setup(void)
	{
	/*
	Do a manual update of the plain U8g2 object with the C API for the display.
	Use a special byte function, which includes the support for the I2C LCD GFX board.
	The C init functions are listed here: https://github.com/olikraus/u8g2/wiki/u8g2setupc
	Just replace the function name accordingly.
	Note:
	For T6963 / ST7920 displays, use the "u8x8_byte_i2c_lcd_gfx_board_t6963_8080" callback function.
	For LC7981 displays, use the "u8x8_byte_i2c_lcd_gfx_board_lc7981_6800" callback function.
	For SBN1661 / SED1520 use the "u8x8_byte_i2c_lcd_gfx_board_sed1520_6800" callback function.
	*/
	//u8g2_Setup_t6963_240x128_2(u8g2.getU8g2(), U8G2_R0, u8x8_byte_i2c_lcd_gfx_board_t6963_8080, u8x8_gpio_and_delay_i2c_lcd_gfx_board); // J4
	//u8g2_Setup_t6963_128x128_2(u8g2.getU8g2(), U8G2_R0, u8x8_byte_i2c_lcd_gfx_board_t6963_8080, u8x8_gpio_and_delay_i2c_lcd_gfx_board); // J2
	//u8g2_Setup_sed1520_122x32_2(u8g2.getU8g2(), U8G2_R0, u8x8_byte_i2c_lcd_gfx_board_sed1520_6800, u8x8_gpio_and_delay_i2c_lcd_gfx_board); // J5
	//u8g2_Setup_st7920_128x64_2(u8g2.getU8g2(), U8G2_R0, u8x8_byte_i2c_lcd_gfx_board_st7920, u8x8_gpio_and_delay_i2c_lcd_gfx_board); // J3
	//u8g2_Setup_lc7981_240x128_2(u8g2.getU8g2(), U8G2_R0, u8x8_byte_i2c_lcd_gfx_board_lc7981_6800, u8x8_gpio_and_delay_i2c_lcd_gfx_board); // J3
	u8g2_Setup_ks0108_erm19264_2(u8g2.getU8g2(), U8G2_R0, u8x8_byte_i2c_lcd_gfx_board_ks0108, u8x8_gpio_and_delay_i2c_lcd_gfx_board); // J9 (requires 2024 PCB)
	/*
	After providing the callback function, start the communication with the display by using u8g2.begin()
	*/
	u8g2.begin();
	}

The setup function (line 482) allows you to provide your own custom (and non-blocking) I2C functions.

Another approach is to avoid Arduino and build your own C based approach, for example see here: https://github.com/olikraus/u8g2/tree/master/sys/arm/stm32l031x6/u8x8_test

In both cases you need to write a low level API for u8g2, which is discussed here:
https://github.com/olikraus/u8g2/wiki/Porting-to-new-MCU-platform#hardware-i2c-communication

Due to the differences in microcontrollers, the support from u8g2 is limited.

For my own time critical applications I usually let the real time part run in interrupts while the display output runs in the main loop. I2C obviously shouldn't be shared if the real time function also requires I2C. In such a case I did fallback to software emulated I2C if required, which also can be interrupted.
The above referenced project will implement a SW emulated I2C communication, see also: https://github.com/olikraus/u8g2/blob/master/sys/arm/stm32l031x6/u8x8_test/u8x8cb.c