<...> because CAN have a lot more bigger barrier to entry on learning it, at least on me.
don't use CAN, it's super complicated.
CAN controller has a complexity much more than UART has, I agree. I talked about usage and forgot about knowledge.
I cannot see a difference between using RS485 or CAN bus from the Application Layer protocol point of view.
I guess you mean a kind of protocol over RS485 like MODBUS. Then yes, usage of Application Layer should be almost as simple as usage of keys of UI. My statement about easiness was not precise. I thought not about using a library, but making stack from scratch - in that case CAN controller takes most of burden, CAN bus itself without upper layers is well suited for transmission of discrete signals, while configuration is not really a hard task. My estimation was biased. And it was my mistake to compare RS485 and CAN bus here.
I'd suggest using MODBUS.
MODBUS is an overkill here. CAN bus too.
Two slaves, each pair master-slave communicates by sending 2 bits of data.
Master polls slaves by packets that fit in one byte (or 9 bits) including CRC : [master-mark, slaveaddress(0 or 1), status(2 bits), CRC].
Slaves respond with packets that also fit in one byte: [slave-mark, slaveaddress, keys(2 bits), CRC].
So the protocol handling becomes exceptionally simple:
Master periodically sends prepared bytes - appropriate slave responds after checking address and CRC - master reads task from received byte. finish.
CRC check is performed by one comparison using table of 16 bytes. CRC for sending is generated using the same table.
Not scalable but very compact solution.
I personally would use CAN even for that task for two reasons:
1) I am familiar with CAN bus, and probably will start use it before thinking over alternative. biased. mea culpa
2) I remember its scalability and built-in functionality that unloads software.