Mark F
October 13th, 2002, 12:55 PM
Bottom line:
Any support for the Tweakhardware IR receiver device, that is written EXCLUSIVELY as a Girder plugin, may use a large amount of CPU. More important for YOUR situation, the IR input will be non-deterministic and software DVD will probably suffer.
Very long and boring explanation:
In the tweakhardware design, the IR information is placed on one of the handshaking lines of the com port instead of in the data buffer. This means the supporting software must either poll the port continuously at a rate where it won't miss edge transitions (using large amounts of CPU) OR it has to set up a thread which sleeps and waits for handshaking events (these events are not time stamped). Either way, the code is dispatched at the whim of the Windows scheduler. The Windows scheduler is not a real time scheduler so the basic rule is "your code may run sometime". (non-deterministic) To increase the chances of being dispatched when it should, most programmers increase the priority of their thread to a high value. If you add a task with a high priority CPU-hog thread to a system which is decoding DVD in software, the DVD picture will probably studder and the sound may break up with any press of a button.
I don't know how much you know, or want to know :smile:, about the Windows family of operating systems but this is the IR equivilent of a WinModem. It includes just enough hardware to talk to the outside world and then relies on a very stable and deterministic host CPU environment to decode the data. To get to such an environment under Windows, a device driver, tuned to the specific task, is required. Inside a device driver, software can do whatever it wants and WILL be dispatched in a "timely" manner to handle the interrupts generated by the device. By writing a device driver (or possibly just a port driver) to replace the default VCOM processing and a Girder plugin to use this new driver, someone could support this device with minimal interference to the rest of the environment. The problem - A device or port driver is not a simple piece of code to write CORRECTLY and will do EXTREME things to a system if written poorly.
My advice (as if you asked for it :smile: ) - if you can build one of the designs which use a uC (like the PIC-based UIRT (http://people.a2000.nl/rwvgesse/FixFrame.htm?Uirt.htm) design), do it.
Any support for the Tweakhardware IR receiver device, that is written EXCLUSIVELY as a Girder plugin, may use a large amount of CPU. More important for YOUR situation, the IR input will be non-deterministic and software DVD will probably suffer.
Very long and boring explanation:
In the tweakhardware design, the IR information is placed on one of the handshaking lines of the com port instead of in the data buffer. This means the supporting software must either poll the port continuously at a rate where it won't miss edge transitions (using large amounts of CPU) OR it has to set up a thread which sleeps and waits for handshaking events (these events are not time stamped). Either way, the code is dispatched at the whim of the Windows scheduler. The Windows scheduler is not a real time scheduler so the basic rule is "your code may run sometime". (non-deterministic) To increase the chances of being dispatched when it should, most programmers increase the priority of their thread to a high value. If you add a task with a high priority CPU-hog thread to a system which is decoding DVD in software, the DVD picture will probably studder and the sound may break up with any press of a button.
I don't know how much you know, or want to know :smile:, about the Windows family of operating systems but this is the IR equivilent of a WinModem. It includes just enough hardware to talk to the outside world and then relies on a very stable and deterministic host CPU environment to decode the data. To get to such an environment under Windows, a device driver, tuned to the specific task, is required. Inside a device driver, software can do whatever it wants and WILL be dispatched in a "timely" manner to handle the interrupts generated by the device. By writing a device driver (or possibly just a port driver) to replace the default VCOM processing and a Girder plugin to use this new driver, someone could support this device with minimal interference to the rest of the environment. The problem - A device or port driver is not a simple piece of code to write CORRECTLY and will do EXTREME things to a system if written poorly.
My advice (as if you asked for it :smile: ) - if you can build one of the designs which use a uC (like the PIC-based UIRT (http://people.a2000.nl/rwvgesse/FixFrame.htm?Uirt.htm) design), do it.