[ale] [Slightly OT] Prolific

[mike at trausch.us]

On 11/04/2012 09:19 PM, Michael H. Warfield wrote:
> On Sun, 2012-11-04 at 19:10 -0500, mike at trausch.us wrote:
>> Just out of curiosity, has anyone here actually seen a WORKING chip from
>> Prolific?
>
> I have stacks of them.  No problem...  They are the heart of most of my
> remote maintenance systems with serial consoles.
>

As is, more or less, my intention to do here.  The whole stupid reason I 
bought the bloody thing.

>> I'm finding myself wondering how the hell they're still in business.
>> Every USB cable I have purchased that has a PL* chip in it simply
>> doesn't work.  Doesn't matter if we're talking about serial or parallel
>> interfaces, they just never ever work.
>
>> And of course, you can never tell what chipset is in the stupid things
>> until you've bought them and hooked them up and then you have that
>> "D'oh!" moment.
>
>> Seems that Fry's only carries such cables, so I guess I won't be buying
>> from there anymore.  Linux kernel devs strongly suggest avoiding them.
>
>> The problem this time?  It will receive data from a modem, but not
>> transmit to the modem.  So I can see:
>
>> RING
>
>> RING
>
>> But if I try to send "ATA" nothing happens, no echo, no going off-hook,
>> no screeching, no nothing.
>
> Oh, I recognize this problem.  I've seen it many times in the past.
> It's a hardware flow control problem.  Something is hosed in your RTS /
> CTS (Request to Send and Clear to Send) or DTR / DSR (Data Terminal
> Ready / Data Set Ready) signal wiring and configuring.

Awesome.  So I bought a defective cable as opposed to one that is a 
counterfeit, then?  Because I assure you, I have not done anything to 
the wiring.  I have the serial modem (known good and tested working, 
when connected with a DB-25 to DB-9 straight-through to a PC with a 
"real" serial port), connected to the DB-25 to DB-9 cable, connected to 
the DB-9 to USB cable which is connected to the computer.

Obviously RD/TD aren't crossed, or RING wouldn't even come through.

> Most often, for me, this has been RTS / CTS in a cross over cable where
> you have two choices.  The simple choice is to loop the CTS on one side
> back to the RTS on the same side basically disabling the hardware flow
> control.  The PROPER way to do it is the connect the RTS on one side to
> the CTS on the other side but, then, both sides have to be configured
> for full hardware flow control or both have to be configure to ignore
> CTS/RTS hardware flow control.

No flow control settings work, hardware, software, none, mixed, nothing.

Based on what you're saying here, zero flow control should work just 
fine.  It doesn't.

But if I have the port set to 115200, 8-N-1, I get, well, 
"RING\r\n\r\nRING\r\n\r\n", and nothing else.

> You have to have your hardware (RS-232 signaling lines) match your
> software for the UARTS for flow control matching.  What you are
> describing is exactly the failure I see when this is not the case.

I'll bring the cable by.  $10 says you can't get it to work without 
voiding its warranty.  :-P

(If it even has one, anyway.)

>> Wonderful, yes?
>
>> SO anyway, just curious: has anyone heard of a chip from this
>> manufacturer actually performing as intended, or do they just hate me?
>
> Bottom line - it's not the chip.  It's your interconnect wiring and flow
> control setup.

Then why have I never had a working cable from this company?  I simply 
can't see that as being anything close to probable.

	--- Mike

-- 
A man who reasons deliberately, manages it better after studying Logic
than he could before, if he is sincere about it and has common sense.
                                    --- Carveth Read, “Logic”