-> What do you mean by "rely on the computer to time the process.."
-It's a WinCam. They traded off the $5 microcontroller for absurdly
-tight timing requirements imposed on the host CPU. This is how you
-sell product in the mass PC market.
-WinWidgets suck. :-(
Yes they do. The bottom line is though is that such constraints simply will
not work in Linux's multitasking environment. Turning off interrupts means
missing disk accesses and totally locking up the system while a picture is
scanned. It's flat out a bad idea.
I'd advise testing out a do nothing driver that simply disables interrupts
and sleeps for 20 seconds at each access and verify that your system
continues to operate properly. I have a sinking suspicion that your Linux box
will lock up hard because some essential process is locked out (disk would
be my guess followed closely by the network) while the interrupts are off.
Here's a couple of different ideas that may better suit the task at hand:
1) Add the $5 microcontroller. Use a cheap 8051 or a PIC 16CXX type part
as an interface to the CCD. Then the uC can maintain (easily) the tight
timing requirements, dump the image to the buffer, and then leisurely present
the image to the Linux box using a standard (and interruptable ;-) interface
like the serial port.
2) Dedicate a DOS box to the CCD, then interface the DOS box to the Linux box
via the LAN.
-> Just because some DOS driver written some time ago for a 4.77 Mhz 8088
-> needed interrupts off doesn't mean you will.
-This quite likely does. For one thing, it probably uses the host CPU
-as the source of its process timing - no interrupts 'cause there's
-nothing smart enough in the WinCam to generate an interrupt, let alone
-queue up a decent chunk of data. And CCDs can make pretty strict
-demands for _stable_ timing to keep the light response constant from
-cell to cell, IIRC.
All true. But you've found the one sticking point that Linux boxes simply
cannot compete with DOS. Sice DOS was single tasking, locking it up for 20
seconds had no significant effects. Essentially the application had all the
control. As a real OS, the Linux kernel has all the control and simply grants
applications limited rights to resources. But the responsibility of that is
the system will be available to all applications.
Bottom line. It's very unlikely to work and you'll have to find another way
do to it.
Go back and ask the engineer if the device has an NT interface and if so,
how was it done... This will give you more insight on how Linux would
have to do it.
Sorry for the doom and gloom...
Another random extraction from the mental bit stream of...
Byron A. Jeff - PhD student operating in parallel - And Using Linux!