>The one thing that stands out is that many of the classes only have one instance created,
To maintain proper levels of abstraction.
>Returning structures from functions requires a copy,
Which is extremely fast, simple, side-effect-free, and likely optimized away by RVO.
>The actual matrix-scan loop in HardwareController could also be simplified greatly;
Nothing you described would actually be an optimization. Turning off all the rows/columns takes 1 cycle.
>Getting the button number shouldn't require a multiplication
Nit-picking. This is fast and easy to read. I'm not going to worry about the few nanoseconds required for a multiplication.
That's also not an issue of "simplification"; it's just premature optimization.
>but USB shouldn't be that much more complex
PJRC wrote that library. Not sure what they do.
>There can be row/column combinations which don't have keyswitches at their intersection, but are scanned anyway. You can connect other units so that they act like keyswitches when they send information.
Why would I do that? Part of the design is that each individual board is responsible for translating button presses to USB keycode deltas. This allows for better distribution of responsibility, and also the boards can be connected in any configuration/order and maintain the same behavior.
>Transfers that occur in small bursts instead of one continuous serial stream.
What's the downside to this? The bursts occur way faster than human perception could hope to notice.
Besides, if you want to be pedantic, any serial protocol communicates in "bursts".
Abstraction is only a tool, a means to an end; not the end in itself.
> Which is extremely fast, simple, side-effect-free, and likely optimized away by RVO.
Copying is one of the fastest things a processor can do, but that's not a reason to do it unnecessarily, even if the compiler optimiser could simplify it.
> That's also not an issue of "simplification"; it's just premature optimization.
Really? I suppose that if you consider abstraction the ultimate goal, you might think that shorter, simpler code would be "premature optimization"...
> Part of the design is that each individual board is responsible for translating button presses to USB keycode deltas.
That functionality remains the same; the receiving board just collects each bit of the scancode and passes it through directly to the USB. The sending board is still the one doing the matrix scan and position-to-keycode translation. The receiving board is just a passthrough.
> What's the downside to this? The bursts occur way faster than human perception could hope to notice.
It adds complexity to the software, because it has to deal with start/stop conditions, etc.
> Besides, if you want to be pedantic, any serial protocol communicates in "bursts".
Not if the clock is continuous; once the receiver and sender are synchronised, the sender can e.g. keep transmitting 0 bytes when there is nothing to send, and keycodes (which are all nonzero) otherwise.
To maintain proper levels of abstraction.
>Returning structures from functions requires a copy,
Which is extremely fast, simple, side-effect-free, and likely optimized away by RVO.
>The actual matrix-scan loop in HardwareController could also be simplified greatly;
Nothing you described would actually be an optimization. Turning off all the rows/columns takes 1 cycle.
>Getting the button number shouldn't require a multiplication
Nit-picking. This is fast and easy to read. I'm not going to worry about the few nanoseconds required for a multiplication.
That's also not an issue of "simplification"; it's just premature optimization.
>but USB shouldn't be that much more complex
PJRC wrote that library. Not sure what they do.
>There can be row/column combinations which don't have keyswitches at their intersection, but are scanned anyway. You can connect other units so that they act like keyswitches when they send information.
Why would I do that? Part of the design is that each individual board is responsible for translating button presses to USB keycode deltas. This allows for better distribution of responsibility, and also the boards can be connected in any configuration/order and maintain the same behavior.
>Transfers that occur in small bursts instead of one continuous serial stream.
What's the downside to this? The bursts occur way faster than human perception could hope to notice.
Besides, if you want to be pedantic, any serial protocol communicates in "bursts".