I just posted Software I2C enhancement on Task Tracker. Feel free to discuss and make suggestions here.
Software I2C enhancement was updated.
Status went from Proposed to Closed.
I don’t understand why there was such a rush to reject it, @ Gus. You could at least give us chance to vote…
@ iamin - for the reasons explained.
@ Gus -
“This requires a significant amount of work in the firmware” - So? Do you automatically reject every request that “requires a significant amount of work”?
“A simple work around would be to break up the individual transactions if the slave sports it” - And if it does not?
“Or simply use the hardware I2C” - Based on this logic, why do you offer software I2C at all? We can “simply use the hardware I2C”.
It is your right to choose what to implement and what not, but if you don’t like someone’s idea/suggestion, reject it at least politely.
Politely? I am sorry the response came across that way. I happen to know exactly what is involved in solving this and what other features we are working on and this falls way down on the list. But that I do not like the idea, we just would never get to it ever. Plus this is very much not necessary.
I have an idea. If the community builds the driver in rlp then we can take it into the firmware.
1 Like
Software I2C was introduced when it was noted that not every target processor had I2C pins that were usable, perhaps they had duplicated functionality that was even scarcer than I2C, or were tied up when for example a shield occupied those pins with something that couldn’t be moved. I’d always use hardware driven device if I had the choice, and the software option I see as a backup - but messy, because you still have to add resistors on whatever random pins you choose to use. If that has a consequence, so be it. At least it’s an option, before this there was nothing.
1 Like