[FR] Software I2C for LCDs and general use

[DejitaruJin]

Is your feature request related to a problem? Please describe.

No response

Are you looking for hardware support?

No response

Describe the feature you want

I'm currently replacing my Longer LK4 Pro's DWIN LCD screen with an I2C screen. Unfortunately, this board only has SCL broken out in some random unlabeled connector, with SDA not broken out at all. There are apparently at least a few other boards like this as well.

I see in eeprom_if_i2c.cpp that SOFT_I2C_EEPROM is a configuration option that triggers initializing SlowSoftWire, and it looks like the rest is handled invisibly without anything in Marlin code having to care whether it's hardware or emulated. My intent is to basically move that initialization somewhere more general, so that the same hardware abstraction can be used for LCDs, temperature sensors, and other devices that don't need critical timing.

This shouldn't be something I need help doing, but I wanted to make a formal post to make sure A) I'm not stepping on anyone's toes, and B) I'm not overlooking some existing functionality that handles this already.

Additional context

No response

[DejitaruJin]

Well that's a little trickier, Marlin is apparently using at least two solutions for emulated I2C - digipot_mcp4018.cpp uses SlowSoftI2CMaster directly, where eeprom_if_i2c.cpp is using SlowSoftWire, which is a wrapper for the former that allows the previously mentioned abstraction.

I actually have some MCP401x chips I could test restructuring with, but there's no way I'm going to use them as intended, and... well the "creative" method of splitting up I2C channels like that is a pretty good reason for me to just leave that file alone.

[DejitaruJin]

Upon much deeper research, I think I'm going to have to rescind this request. The New-LiquidCrystal library does actually have a software I2C mode that could be switched to! Unfortunately, A) It hard-codes which pins to use without any consideration for external override (please don't do that in a library) and B) The pins, compile-time #defines, are AVR pin & port, not Arduino pins, because the software I2C library is written in Assembly.

I've looked pretty thoroughly and there does not seem to be any capacity to convert Arduino pins to AVR pin & port, those are runtime functions. I might consider jumping through those hoops to make my own devices work, but it's not something I'd deploy to production code. Really though, I don't think I want to fool around with yet another low-level library that hasn't been tested for how it might interfere with what Marlin is already doing.

At this time, the only solution I see for a unified emulated I2C experience is physically replacing the Wire library with something like SlowSoftWire and actually renaming the files so nothing that calls the library realizes something's changed.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.