in reply to Can't set baudrate with Win32::SerialPort and Belkin USB adapter

I'm sorry, but your lead-in description makes me wonder if this is really a hardware question rather than a Perl (or any kind of software) question.

Does the perl script work as expected when "comport A" is something other than the Belkin USB adapter?

I gather that the problem is shown at the point in the output where it says "SUCCESS" given that "A-COM5" is supposed to be going at 9600 and "B-COM1" is supposed to be going at 1200 -- which means that "A-COM5" actually must have 1200 as some sort of default pre-set, and when you tried setting it to 9600, it remained at 1200. Is that it?

If baudrate changes work as expected on the Belkin when this is done by things other than the perl script, and if the perl script succeeds in changing the baudrate on a COM port when some device other than the Belkin is attached, you have my sympathy. Alas, that's all I can offer.

(Well, maybe you'd have to look up details on things like data bits, stop bits, parity, handshaking, xon/xoff, etc, to see if maybe there's something among that set of parameters that the Belkin doesn't support. I could well imagine a situation where the device would ignore any change request if one of these details were "out-of-spec". Have you verified that these settings in the perl script match the ones you used with Hyperterm, etc?)

  • Comment on Re: Can't set baudrate with Win32::SerialPort and Belkin USB adapter

Replies are listed 'Best First'.
Re^2: Can't set baudrate with Win32::SerialPort and Belkin USB adapter
by TGI (Parson) on Sep 24, 2005 at 06:13 UTC

    I would write it off as a hardware/driver problem if I other software didn't work.

    So I am left with three possibilities:

    1. My code is wrong
    2. Win32::SerialPort is broken
    3. The belkin drivers are broken (and so W32::SP can't configure the port normally)

    Naturally, my assumption is that 1 is the case. At least until I've looked a bit more at what's happening. It is possible, though, that W32::SP is showing its age, it hasn't been updated in a few years. If 3 is the case, I don't know how I'll ever straighten this out, as I am definitely not an Win32 API guru.


    TGI says moo