Thoughts on hardware architecture

This issue is to explore our thinking about arranging our micro-controllers

Core design

A split key board
fully wireless*
can be extended. not limited to just the two splits
each split has multiple modules, e.g.
- Thumb-module (buttons and/or track-ball, and/or scroll-wheel, for example)
- finger: what your non-thumb fingers use
- base: mouse optics, or just nothing
- internal: limited only be packaging up modules.
Slots are designed such that you can mix and match. You mich switch out your button-only thumb-slot for joystick + scroll wheel + 4 buttons, for example.

[!IMPORTANT] The pain, both to developer and end-user, of bluetooth is not worth it.

Context

I'm fine when it comes to writing rust, and I'm starting to get a feel for writing basic firmware. I have no frame of reference, though, for how to think about how to sort out hardware architecture in the physical world, beyond how it relates to the code I'd need to write. To put it another way: In my head, the physical micro-controllers are a purely abstract concept, where cost doesn't exist, power consumption is just code-style guide, and multiple devices are just esp-now code.

Previous approaches

Our first idea was to work with two splits, one designated primary, the other secondary. The primary would be the link to the host, the secondary would feed input events to the primary:

Because the world of BT/BLE is &$(#ed, this would have to be over USB, or esp-now to a device plugged into the computer directly.
To make it an option to have either device as primary, high(er) cost hardware would be in both, making the secondary over-specced for its role

Because we want wireless, and BT/BLE is mostly considered deprecated to us, we decide to go with the "esp-now to a USB adapter". This put me on the path of: "Why not make the more than just an adapter? Let's make it the central hub?"

Current/Proposed design approach

Something with a lot of oomph plugged into a USB-port as the core device
Without connected peers, it's function-less.
It peers-up with event-providers (e.g. thumb-slot/mouse/keyboard modules)
Each event-provider module is an esp32 connected to input hardware (KB-matrix, mouse optical, etc). Its only role is to send raw event data (e.g. de-bounced key down/up events) to the core device.
the core device fuses the events and provides the HID reports to the host

But I'm not confident in my ability to consider trade-offs...

pros:

So long as each module is accounted for when flashing the core, it seems like hot-swapping modules will become trivially easy?
extremely easy to scale: the network of input-generators is only limited by esp-now
cost: I've found esp32c2 boards for less than 3 euros.
cost: only one higher-cost device needed.
GPIO: If there's just one board per split, GPIO-pins are limited: 2 kb-matrixes, mouse hardware, joystick, accelerometer, etc. What if we wanted to add a display? With per-module boards, there will always be pins to spare.
power: all battery-powered components only need to concern with checking GPIO pin data, and relaying that to the core device. A rush-to-sleep power-saving model will be easy.
flexible: Adding another device to the network is just a matter of adding the event-data handling to the core device code, and setting them up to allow pairing.

cons:

cost: each input-module has to come with its own micro-controller.
power: multiple devices have a much higher potential consumption.
power: would multiple "pin-checkers that only send data over esp-now" still use less battery?
development complexity: getting debug logs, isolating error-sources, etc.
power management: one battery per module? could a battery be shared between modules? How to recharge? I don't know these things, and wouldn't know where to start.

Thinking:

core device is something with some oomph: s3, for example
for each input module, something like this
core device will be a bpi-leaf-s3 or something similar

LYNXware / cat_esp32s3_rust