klipper
klipper copied to clipboard
i2c_software: Implementation of software i2c
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
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.
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
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
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
Okay, thanks. In general, it looks fine to me. I'll look to commit early next week.
-Kevin
Thanks.
-Kevin
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
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
seems changing line 10 of Kconfig from
select HAVE_GPIO_I2C if !MACH_STM32F031
toselect 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
then my commit/solution may be just a sticking plaster for other problems caused by this commit
See #6244 for code to optionally disable software i2c (and other features) on chips with small flash sizes.
-Kevin
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
Also ref https://klipper.discourse.group/t/possible-bug-in-recent-commit/8921