i2c_software: Implementation of software i2c

[bigtreetech]

Follow up https://github.com/Klipper3d/klipper/pull/6130 Software I2C tested on STM32H7 with both BME280 and sh1106, The actual test results are normal.

The following are some results captured by the logic analyzer.

• 100KHz i2c read

• 100KHz i2c write

• ~400KHz i2c read~

• ~400KHz i2c write~

Note

• ~The maximum rate in the .c source file is limited to 1MHz, and the actual rate captured by the logic analyzer is between 800KHz-1MHz~ Speed fixed to 100KHz
• Tested on Mega2560, it can control i2c devices normally, but even without the i2c_delay function, the occupancy rate of the mcu is still 100%, so it is not recommended to use software i2c on MCU like Mega2560

[thijstriemstra]

Tested on Mega2560, it can control i2c devices normally, but even without the i2c_delay function, the occupancy rate of the mcu is still 100%, so it is not recommended to use software i2c on MCU like Mega2560

Any other test results? e.g an Octopus board.

[bigtreetech]

Tested on Mega2560, it can control i2c devices normally, but even without the i2c_delay function, the occupancy rate of the mcu is still 100%, so it is not recommended to use software i2c on MCU like Mega2560

Any other test results? e.g an Octopus board.

It can work normally in Octopus F4/H7 versions

[KevinOConnor]

Thanks. I guess my main question is - which users are expected to utilize this and what hardware is it expected that they will use it with? Is this just general functionality that some users may find useful or is there a specific hardware setup that requires this functionality?

In general I prefer to only add code when we have a general idea of who will be using it and what they use it for. (That way, I can get a better feel for the maintenance costs of the extra code relative to the functionality obtained by that new code.)

Cheers, -Kevin

[bigtreetech]

Thanks. I guess my main question is - which users are expected to utilize this and what hardware is it expected that they will use it with? Is this just general functionality that some users may find useful or is there a specific hardware setup that requires this functionality?

In general I prefer to only add code when we have a general idea of who will be using it and what they use it for. (That way, I can get a better feel for the maintenance costs of the extra code relative to the functionality obtained by that new code.)

Cheers, -Kevin

This requirement is raised by some of our customers who want to connect BME280 temperature and humidity sensors to our motherboard (such as Octopus max ez). There is no hardware i2c port reserved on the motherboard, but there are many GPIO

[KevinOConnor]

Okay, thanks. In general, it looks fine to me. I'll look to commit early next week.

-Kevin

[KevinOConnor]

Thanks.

-Kevin

[JamesH1978]

This looks to break smaller STM32 builds like the 042 with an error of

Linking out/klipper.elf /usr/lib/gcc/arm-none-eabi/10.3.1/../../../arm-none-eabi/bin/ld: out/klipper.elf section.text' will not fit in region rom' /usr/lib/gcc/arm-none-eabi/10.3.1/../../../arm-none-eabi/bin/ld: region rom' overflowed by 904 bytes collect2: error: ld returned 1 exit status`

Seems to push it over the flash size

Thanks James

@KevinOConnor @bigtreetech

[JamesH1978]

seems changing line 10 of Kconfig from select HAVE_GPIO_I2C if !MACH_STM32F031 to select HAVE_GPIO_I2C if !MACH_STM32F031 && !MACH_STM32F042 fixes it at least for the 042, i havent tested other STM32F0XX mcu's

[Lefuneste83]

seems changing line 10 of Kconfig from select HAVE_GPIO_I2C if !MACH_STM32F031 to select HAVE_GPIO_I2C if !MACH_STM32F031 && !MACH_STM32F042 fixes it at least for the 042, i havent tested other STM32F0XX mcu's

This seems to allow compilation of FW for STM32F042. I have one in a Voron 0 display board. But the commit 645a1b seems to break i2c communication nonetheless. I have made several attempts, including a complete reinstall of klipper, but they all failed and I had to rollback to previous commit, which works without a problem, both in compiling FW and communication with the display board.

Protocol error
Traceback (most recent call last):
  File "/home/pi/klipper/klippy/klippy.py", line 180, in _connect
    cb()
  File "/home/pi/klipper/klippy/mcu.py", line 753, in _connect
    self._send_config(None)
  File "/home/pi/klipper/klippy/mcu.py", line 683, in _send_config
    cb()
  File "/home/pi/klipper/klippy/extras/bus.py", line 177, in build_config
    self.i2c_write_cmd = self.mcu.lookup_command(
  File "/home/pi/klipper/klippy/mcu.py", line 873, in lookup_command
    return CommandWrapper(self._serial, msgformat, cq)
  File "/home/pi/klipper/klippy/mcu.py", line 84, in __init__
    self._cmd = msgparser.lookup_command(msgformat)
  File "/home/pi/klipper/klippy/msgproto.py", line 315, in lookup_command
    self._error("Unknown command: %s", msgname)
  File "/home/pi/klipper/klippy/msgproto.py", line 243, in _error
    raise error(self.warn_prefix + (msg % params))
msgproto.error: mcu 'display': Unknown command: i2c_write

[JamesH1978]

then my commit/solution may be just a sticking plaster for other problems caused by this commit

[KevinOConnor]

See #6244 for code to optionally disable software i2c (and other features) on chips with small flash sizes.

-Kevin

[JamesH1978]

This also seems to break some rp2040 boards, at least a couple of SB2040 mellow owners have tmc uart issues on this commit, that i have seen on the discord

Thanks James

[Sineos]

Also ref https://klipper.discourse.group/t/possible-bug-in-recent-commit/8921