in reply to Win32::SerialPort ; close / open problem

'RS-232' serial ports do not provide any hardware connected detection beyond handshake lines being in the correct state. Plugging and unplugging a serial cable does not affect the state of any software or drivers that is associated with the port. So for 'RS-232' ports there is no need to open/close the port because the cable has been connected/disconnected or the device at the far end of the cable has been turned on/off.

However, if you are using a USB/RS-232 device and it is the USB cable that is being plugged/unplugged, then you are in a whole different world and there may be nasty stuff going on that you have no control over. The OS's RS-232 drivers were not designed with the serial port hardware coming and going - the hardware was either on the mother or plugged in through a hardware buss so that just couldn't happen. As a result bad stuff can happen in the context of USB/RS-232 devices because they try to look like legacy serial ports to the OS, but don't behave like them. I wouldn't be surprised to see bad behaviour especially during connect and disconnect and that there may be no simple solution.

True laziness is hard work
  • Comment on Re: Win32::SerialPort ; close / open problem

Replies are listed 'Best First'.
Re^2: Win32::SerialPort ; close / open problem
by philipMac (Novice) on Jul 25, 2009 at 23:23 UTC
    Thanks Grandfather, right, I'm using a USB/RS-232 device.
    Hmm. No simple solution... I had a feeling this might be the case.
    I was just reading through the Win32API::CommPort docs, there is a section for Raw Win32 system API, but none of it seems to be useful for me.
    Maybe I can have a separate listener Daemon just start and stop the PortObj Daemon. When the Daemon gets stopped it can release whatever lock is in place. I'll have to try and find a Windows machine at home to test this theory.
[reply]

      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]

In Section Seekers of Perl Wisdom