Electrical – How to deal with PS/2 keyboard input and CPU interrupts

Since this is an electrical engineering site, I will attempt to give a lower level perspective.

Any device, such as a hard disk controller, must have some way of transferring data. This could be a parallel data bus or a serial one, it could be through radio waves or it could even be through human read LEDs and human set DIP switches (thus not necessarily needing a CPU at all). So then, the question comes up: How is the best way to connect a device to the CPU? You could make the device look for a specific address on the CPU address bus and then it would send or recieve data only when the CPU reads or writes on that address. This would skip RAM entirely, allowing the CPU to copy data directly from the device to a processor register. Of course in your architecture you would have to make sure that there were no conflict and that RAM doesnt also respond to the request generating a bus collision. To avoid that, you could add a special IO line in your CPU architecture that is asserted to read and write from devices and disables the RAM. You could even add a special IO bus to the CPU architecture if you wanted.

This was actually how many devices were connected to the CPU in the early days (ie 1970s and 80s). Consider, however, a hard drive and its typical use. Typically a processor manipulates data that is stored in registers, but registers are not very big so for large amounts of data RAM is used as a high speed place to store data. The hard drive would be too slow for such use. If this data needs to be stored permenantly, however, then the data must be transferred from RAM to the hard drive. Using the method I specified above, the CPU would have to be constantly tied up transferring byte per byte the data it wants to store in the hard drive. This turned out to be quite painful in the early days, so a mechanism called Direct Memory Access (DMA) was created to allow devices to read and write from RAM directly. The CPU could simply send a command to the hard drive controller, for example, to read some section of the hard drive and put it in RAM or vice versa. The CPU then would be free to do other things while the HD did its business. The transfer was also alot faster than the old CPU based method.

So to answer your question: Are there other ways to connect devices? Absolutely! But you'll find that the fastest way to tranfer large amounts of data from a device is not through the Processor, but directly from the device to RAM, therefore most modern devices use RAM as an intermediary store.

Unfortunately, there's really no good way to do this. When you call sleep, a system call is made and the OS goes off and runs other programs while you sleep. But the OS scheduler has a minimum timeslice it will do that on, and that's on the order of milliseconds, not microseconds. As a result, very small sleeps will tend to either not happen at all or take far too long, which is what you're seeing.

You have two realistic options: Write a kernel module that won't suffer under the same scheduling constraints, or use an offboard processor, such as a cheap 8-bit MCU to do the decoding, sending the results back via a serial port. I would recommend the latter.