Consider adding support for "weak" controllers as initiators

[kdb424]

I have gotten the Itys Bitsy M0 to work as a proper uart slave (with a single pin remapped to converter). The changes are... somewhat messy. This can be seen in the topic-slave-uart for an example of a very quick and dirty example change. It involved slimming down the firmware massively, along with the internal state for ram savings or something this weak wouldn't even boot. Keyboard is just stripped of everything that isn't needed, and target set to the new circuitpython_samd21 mcu, which then knows it's a slave, and calls the slave versions instead. Thoughts?

[klardotsh]

Given the relatively low price difference between SAMD21/SAMD51 boards I don't see much value in adding such a dramatic change, complicating both developer maintenance cost and understanding of the deployment process for end users.

If we were talking about the difference between a $5 Clone Micro and the $50 MakerDiary NRF52840, I'd probably want to play ball. However, the Feather M0 Express is $20 USD compared to the Feather NRF52840 which is.... $25 USD.

Even converting to Socialism Dollars up here in the north, that's not a steep enough difference to most builders, methinks.

[klardotsh]

That all said - the overall ticket as worded in the title is still interesting to me. "Dumb controllers" for the secondary/tertiary controllers in split keyboards could cut costs tremendously if we're talking about the difference between $5 and $25-50, at the project cost of adding C/Rust/whatever to the codebase and a bit more complicated of an installation tutorial (but then - split keyboards are inherently kinda weird, so maybe that's not so bad)

[kdb424]

That was more the point, of saving money on more expensive controllers. The controller added in the example was just what I had on hand as I mistakenly ordered, more so than an actual recommendation in that exact case. The uart protocol (actually, the entire kmk split protocol) is really simple to implement on any controller in any language, so anything that supports the control at hardware (uart, bluetooth, irc, ect) that we use in the main firmware could actually work very easily as long as it knew haw to scan matrix, and transmit 3 bytes. The issue references a quick and dirty implementation that was never intended to be PR'd, but to start a discussion over a proven work. It truly is a mess on that branch.

[klardotsh]

It's worth noting that use of "dumb" controllers inherently kills the ability to use EEHands-style functionality, and also MASSIVELY complicates (or makes me outright want to call them unsupported) adding things like rotary encoders to the "remote" pieces of the keyboard. This would only really be supported for basic matrix scanning, otherwise we're stuck reimplementing tons of CircuitPython/KMK functionality in C/etc. for ATMega, which.... pass.

I think that's probably still a fine tradeoff to make.

[dzervas]

In terms of budget, I think the best would be an MCP23017 - it's I2C and costs about a dollar. It can handle 16 pins (can even be chained with up to 3 others) so it can handle a matrix of 8x8 which is good enough for splits (right side is about 7x9 on most splits - still totals to 16 pins). The config is super easy, as you can pass in both right side's columns and rows MCP pins.

[kdb424]

I think that this adds a lot of complexity, along with very few users actually needing this done. I'll close this for now as I believe that I'm the only one has ever used this "feature" and all because I didn't want to wait for shipping. Controllers aren't THAT expensive, and it's likely not worth the work or complexity until someone actually comes up with a good reason to do this. Closing for now.