Searching \ for '[EE] USB to serial converter' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/io/serials.htm?key=serial
Search entire site for: 'USB to serial converter'.

Exact match. Not showing close matches.
PICList Thread
'[EE] USB to serial converter'
2005\09\27@181837 by olin piclist

face picon face
I got back to my Windows 2000 system and looked more carefully at the
driver.  It turns out there are 3 drivers on the disk which Windows is
willing to install.  After picking the one that had the best sounding
pathname given my system, the USB adapter worked like it did on the Windows
XP Home system.  The path to this driver was quite different than the one
shown in the installation instructions that came with the unit.

The converter would work with an EasyProg with my loopback adapter inserted
in between, but would not work directly.  This adapter has pins 1-4-6
shorted and 7-8 shorted at the COM port end.  I suspected that it probably
was only responding to CTS and not DSR or DCD.  To test this I opened pins
1, 4, and 6.  It still worked as I expected.  So, this USB serial adapter
has a bug where it wants CTS driven even when RTS/CTS flow control is
expclicitly disabled in the software.

I then modified an EasyProg by shorting pins 7 and 8 on the bottom of the
DB-9 connector.  This allowed the USB serial port to work with the EasyProg
directly without any adapter.  It was still slower than a real serial port.
Programming a full 16F876 and reading it back at two voltages took 64.2
seconds instead of 55.5 with a real serial port.  That's 16% slower, which
may be acceptable in many cases.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\09\27@184540 by Dave Tweed

face
flavicon
face
olin_piclist@embedinc.com (Olin Lathrop) wrote:
> I then modified an EasyProg by shorting pins 7 and 8 on the bottom of the
> DB-9 connector.  This allowed the USB serial port to work with the EasyProg
> directly without any adapter.  It was still slower than a real serial port.
> Programming a full 16F876 and reading it back at two voltages took 64.2
> seconds instead of 55.5 with a real serial port.  That's 16% slower, which
> may be acceptable in many cases.

My guess is that this additional time (8.7 seconds) simply represents
the latency induced by the basic 1 ms USB frame period. Every transaction
will experience a delay that averages 0.5 ms, or half the frame period.
I would estimate that the process you describe above requires about 16k
to 17k individual messages back and forth to the EasyProg. Does that
sound about right?

If you want really high bandwidth on USB, you need to transfer data in
bigger batches (e.g., 1k bytes or more at a time at Full Speed). In this
application, it's a don't-care.

-- Dave Tweed

2005\09\27@190310 by olin piclist

face picon face
Dave Tweed wrote:
> My guess is that this additional time (8.7 seconds) simply represents
> the latency induced by the basic 1 ms USB frame period. Every
> transaction will experience a delay that averages 0.5 ms, or half the
> frame period.
> I would estimate that the process you describe above requires about
> 16k
> to 17k individual messages back and forth to the EasyProg. Does that
> sound about right?

There should have been at least 24K of them, plus a few extra, say around
25000.  Worst case you get one command and response per mS, but with the USB
otherwise unloaded the driver is allowed to use remaining bandwidth to go
back and allow devices that still have outstanding requests to use the bus
again.  In this case, the USB to serial adapter was the only device using
the USB at the time.  I imagine is uses bulk transfers, which would let it
essentially have the whole USB bandwidth when no other device requests it.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\09\28@001831 by Dave Tweed

face
flavicon
face
olin_piclist@embedinc.com (Olin Lathrop) wrote:
> Dave Tweed wrote:
> > My guess is that this additional time (8.7 seconds) simply represents
> > the latency induced by the basic 1 ms USB frame period. Every
> > transaction will experience a delay that averages 0.5 ms, or half the
> > frame period.
> > I would estimate that the process you describe above requires about
> > 16k
> > to 17k individual messages back and forth to the EasyProg. Does that
> > sound about right?
>
> There should have been at least 24K of them, plus a few extra, say around
> 25000.  Worst case you get one command and response per mS, but with the
> USB otherwise unloaded the driver is allowed to use remaining bandwidth
> to go back and allow devices that still have outstanding requests to use
> the bus again.  In this case, the USB to serial adapter was the only
> device using the USB at the time.  I imagine is uses bulk transfers,
> which would let it essentially have the whole USB bandwidth when no other
> device requests it.

It isn't quite that simple. The low-level packet scheduler (part of the
OS driver for the USB host chip) implements a strict 1 ms frame even
when there is only one device on the bus.

Now, it may be that outbound bulk transfers don't have to wait for a 1 ms
boundary, but the status request that tells the scheduler that there's
inbound data waiting in the device definitely does. So, if we only have
to account for latency on the inbound messages, that probably explains
the difference in time you saw. (12500 messages @ 0.7 ms each)

-- Dave Tweed

2005\09\28@080226 by olin piclist

face picon face
Dave Tweed wrote:
> Now, it may be that outbound bulk transfers don't have to wait for a 1
> ms boundary, but the status request that tells the scheduler that
> there's inbound data waiting in the device definitely does.

I'm not in my office now where the USB spec is, but I thought the scheduler
was free to use any remaining slot time after isochronous and other
hard-scheduled activity on bulk transfers in any way it wants to.  Are you
saying that the scheduler is not allowed to re-poll a bulk transfer device
to see if it has input data during left over time?  I don't remember any
such limitation, but it's been a while since I read thru the spec.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\09\28@110201 by Dave Tweed

face
flavicon
face
olin_piclist@embedinc.com (Olin Lathrop) wrote:
> Dave Tweed wrote:
> > Now, it may be that outbound bulk transfers don't have to wait for a 1
> > ms boundary, but the status request that tells the scheduler that
> > there's inbound data waiting in the device definitely does.
>
> I'm not in my office now where the USB spec is, but I thought the
> scheduler was free to use any remaining slot time after isochronous and
> other hard-scheduled activity on bulk transfers in any way it wants to.
> Are you saying that the scheduler is not allowed to re-poll a bulk
> transfer device to see if it has input data during left over time?  I
> don't remember any such limitation, but it's been a while since I read
> thru the spec.

No, the spec. doesn't rule it out AFAIK, but I've never seen a host
scheduler that spontaneously polls devices more than once per frame.

-- Dave Tweed

P.S. I'll see you this afternoon.

2005\09\28@173634 by olin piclist

face picon face
Brent Brown wrote:
> To cut a long story short I got hold of the latest Windows driver from
> http://tech.prolific.com.tw (NOT from Bafo!). Driver is v2.0.2.1 and the
file is
> named wd_pl2303h-hx-x_v20019v2021.zip. It seems to have successfully
> fixed all my problems! It's an InstallShield .exe file too which seems to
> remove previous drivers first and is easier to use than trying to tell
Windows
> where to get a driver file from.

That worked for me on the Windows 2000 system.  The USB adapter now works
with a EasyProg without any adapter in between and without modification to
the EasyProg.  The speed is the same as before.  64.5 seconds with the USB
adapter, 55.5 seconds for direct connection to a real COM port.

Wouter van Ooijen wrote:
{Quote hidden}

I had a driver with version 2.0.0.18 installed which I got off the disk that
came with the adapter you sent me.  That's the one that didn't work without
RTS/CTS loopback.  I now have version 2.0.2.1 which is two years newer and
seems to work correctly.  The time stamp of the driver installer after
unpacking the ZIP file is 3 August 2005.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\09\28@200357 by olin piclist

face picon face
I just installed the new driver from the Prolific web site on my Windows XP
Home system and that works properly now too.  I can talk to an EasyProg
directly using the USB to serial converter.

So this proves (as most of us thought anyway) that RTS/CTS handshaking is
not required by the hardware nor a bug in Hyperterm, just a badly written
and very badly tested driver.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\09\28@232215 by Chen Xiao Fan

face
flavicon
face
That is the problem with USB -->lots of the driver is not properly
written. I believe Microchip's USB drivers are also not very
well written. I switch to serial connection for the Promate III.
ICD2 seems to work fine with USB but people have met problems as
well. PICkit 1/2 are working fine since they are HID devices and
use the default Windows HID class drivers.

Anyway drivers are generally difficult to deal with on any OSes,
including Windows and Linux. They are also one of the major
culprits why systems become unstable.

Regards,
Xiaofan

{Original Message removed}

2005\09\29@091244 by Aza D. Oberman

flavicon
face
<Olin Lathrop
> I just installed the new driver from the Prolific web site on my Windows
XP
> Home system and that works properly now too.  I can talk to an EasyProg
> directly using the USB to serial converter.
>
> So this proves (as most of us thought anyway) that RTS/CTS handshaking is
> not required by the hardware nor a bug in Hyperterm, just a badly written
> and very badly tested driver.

Ergo a prudent design should strap the control lines to allow for crummy
drivers or limited UARTs.

Aza D. Oberman, happily beating a dead horse...

2005\09\29@094326 by Wouter van Ooijen

face picon face
> Ergo a prudent design should strap the control lines to allow
> for crummy drivers or limited UARTs.

And it should compensate for using a cross cable instead of a straight
one, it should provide both DB9 and DB25 connectors (both male and
female, + the RJ connectors that were used by Digital), it should
tolerate non-inverted signals, TTL level signals (both 5V and 3V), and
of course all other current and future user errors and design follies.
But it might require a certain phase of the moon to do so, and waving of
a certain dead sea creature.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\09\29@113605 by Aza D. Oberman

flavicon
face
> > Ergo a prudent design should strap the control lines to allow
> > for crummy drivers or limited UARTs.

<Wouter van Ooijen describes a prudent RS-232 design>
> And it should compensate for using a cross cable instead of a straight
> one, it should provide both DB9 and DB25 connectors (both male and
> female, + the RJ connectors that were used by Digital), it should
> tolerate non-inverted signals, TTL level signals (both 5V and 3V), and
> of course all other current and future user errors and design follies.
> But it might require a certain phase of the moon to do so, and waving of
> a certain dead sea creature.

Suit yourself.

Aza D. Oberman

More... (looser matching)
- Last day of these posts
- In 2005 , 2006 only
- Today
- New search...