"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > While I realize this is more on a driver/hardware level it's > interesting that it's so difficult to use a different protocol for an > existing driver. For example, all serial does is a series of high and > low voltages on specific pins. Why should it be so hard to use an > existing driver and hold a pin on high?
It's been a long time since I've looked at this low-level hardware, but the answer is almost certainly, "No just 'so hard', but 'impossible'". A serial port is driven by a thing called a UART (Universal Asynchronous Receiver/Transmitter). Back when I was playing with these things, a UART was a discrete chip; these days I'm sure it's just a minor part of a more complex I/O processor, but I suspect the basic idea is the same. You load a character to be transmitted into a register on the UART and the hardware takes care of all the low-level gunk like clocking the bits out at the correct rate, adding start and stop bits, and computing parity. And the reverse for the receive side of the house (which is usually the more complicated part). There just isn't any way to tell the hardware to do anything other than it was designed to do. Could you design a piece of hardware which could function as both a serial port and what you want? Sure you could, but it would cost more, and PC design today is a matter of shaving 10 cents here and 30 cents there. It's like looking at a microwave oven and saying, "Can't this thing be reprogrammed to be a communications relay?" Well, sure, it's got some of the same parts, but the parts were put together in a way that makes food get hot, not in a way that makes data bits get transmitted to someplace. -- http://mail.python.org/mailman/listinfo/python-list
