Bit of an inner-dialog rant here, as a particular kind of foolishness dawned on me this morning. 😅

I like hardware hacking, and coding, and discovering how things work. The retro computing hobby is also a veritable wonderland of voids that need to be filled with various little adapters and gizmos. Kind of a perfect match, really.

There have been several threads all of a sudden about PS/2 devices -- mice, mostly -- and how to use them on systems that lack native PS/2 mouse interfaces. Well, it so happens I have two similar needs myself. I have a Tandy RL with a PS/2 electrical interface but an XT protocol, so I need to convert that to AT. Then, the old classic PS/2 mouse with no PS/2 mouse port problem.

Since I like developing things, I took it upon myself to start coding a PS/2 library that I could use on a microcontroller. Yes, I'm reinventing the wheel because this stuff exists already, but that's no fun. It's about the journey and the destination in this case. So after a few days, I had a complete physical-layer implementation of PS/2 written. Host and device side. Great! I started on the KB protocol layer.

But this morning, something quite obvious occurred to me...

My timer interrupt runs every 5us to read and de-glitch the bus pin status. It then checks its state machine to see if there's anything it needs to do -- changes in bus status, expired counters, etc. If so, it updates its internal state and fires an event to the protocol layer, which does the same thing, and then fires an event to the application layer. Then, it all returns control to the main thread so the CPU can do other things in the idle period.

Except... at somewhere between 1 and 20MHz, 5us isn't enough time to do anything else. Duh - there isn't going to be an idle period. In fact, it's probably not even enough time to do what it's already doing. 🙄

I went to all this trouble to build an asynchronous event-driven interface to something that pretty much needs to be relatively tight loops running on bare metal.
Whoops.

Oh well. Half of writing code is defining the problem, and at least now I've pretty thoroughly wrapped my head around the flow between host and device. Now I just have to scale it waaaaay down.

I've always loved the idea of writing code modular enough that I can compile and test core functionality on a PC, and then re-compile building blocks on any target micro I want to use when I've gotten some of the obvious kinks worked out. It seems I often have to learn that, as elegant as it may seem to be, abstraction is difficult to pull off at this level. I think I'm going to have to pick a chip and dedicate it to the host or device role, and maybe lean on its hardware-implemented UART, SPI, or raw 8-bit I/O to deliver that externally. I'm kind of wondering if I would have the CPU time to run an instance each of AT/PS2 and XT on the same chip for that converter. It seems likely to run into timing issues trying to accommodate both bit-banged interfaces in something like 100 instructions per loop.