I suggest that if possible never disconnect the USB cable, but instead connect/disconnect the serial cable and use the state of handshake lines or the cessation/resumption of data flow to indicate the connect/disconnect. You are stymied if the 'serial port' is internal to a hardware device however and you can't break the serial connection.
Maybe you need to tell us a little more about the bigger picture for better advice? In particular, why are devices connected and disconnected and what sort of device are thy?
True laziness is hard work
| [reply] |
More details, certainly;
I've just been given a Freescale mc1322x chip to interface to and run. The chip lives on a tiny dongle board, and communicates with a FTDI FT232R chip, which then is connected to the USB connection. So its a USB Serial bridge, they cannot be disconnected.
This dongle will be plugged in and out all the time.
I wonder,
...wait a second...Amazing. OK, so there's actually a perl module built for the FTDI interface directly. This means I don;t actually have to use Win32::CommPort or Win32::Serial, I can use Win32::FTDI::FTD2XX.
I never thought to look until you asked for a bigger picture. Very silly. This is what happens when you have a three week old baby keeping you up all night.
I spent about a year working on the previous version of the Freescale chip, mc1312x, the USB R232 bridge for that was completely unsupported by anyone, and I actually had to write my own Linux driver for it to work. I was handed the new version, I noticed the FTDI chip, and forgot about it since my previous code worked.
But I never did this plugging / unplugging business.
OK, so I will have to see if this new module makes my problems go away. Roll on Monday morning. Yay.
I'll report back with my results. Assuming this baby doesn't drive me mad in the mean time.
| [reply] |
Ah, that is somewhat what I suspected! Some time later in the year I suspect I may be facing a similar problem, although I'll be tacking it in C++ and possibly with a device driver so I'll have a degree more control over the process.
You'll notice when the device is installed that it actually installs about three separate devices that build a driver stack. Talking to the Serial API that talks to a serial driver that sits on a hardware abstraction layer that sits on a USB driver makes that sort of device a little dodgy! I'll be very interested to hear how you get on.
True laziness is hard work
| [reply] |