I've traced the problem that I'm having with ADTPro (which I'm using to
try to snarf a disk image of P-Lisp, so this is not *completely* off
topic) to a problem with the USB/RS232 adapter that I'm using. If
anyone out there has one of these that they are using with OS/X and
would be willing to help out by doing a quick experiment, please do this:
1. Loop back your adapter by connecting pin 2 to pin 3 (on the serial
side, not the USB side).
2. Plug it in. Fire up a terminal. Find the device. On my machine it
appears as /dev/cu.PL2303-001113FD and /dev/tty.PL2303-001113FD but it
will almost certainly be different on your machine. (You can tell which
one it is because the device file will disappear when you unplug the
adapter.)
3. Type: "cat /dev/cu.PL2303-001113FD" (or whatever it is on your
machine -- you want the CU file, not the TTY file).
4. Fire up a second terminal window and run this little Python script:
s=open('/dev/cu.PL2303-001113FD','w') # Replace with your file name
def foo(flag):
for c in '11 22 33 44 55 66 77 88 99 AA BB CC DD EE FF\n':
s.write(c)
if flag: s.flush()
Now call foo a couple of times. You should see output in the other
terminal window. (If you don't you probably haven't looped back your
serial connector properly.)
Try calling FOO with FLAG set to 0 and then 1. (Try it a few times.)
If the output is the same in both cases please contact me. I get
corrupted output when flag is 1, which seems to be the reason that
ADTPro is not working.
Thanks!
rg
Cancel this request. I figured it out. There is a bug in the IOGear
driver. But I found a new driver that works. Disk images should be up
shortly unless Murphy decides to nail me yet again.
rg
In article <·······························@news.gha.chartermi.net>,
Ron Garret <·········@flownet.com> wrote:
> I've traced the problem that I'm having with ADTPro (which I'm using to
> try to snarf a disk image of P-Lisp, so this is not *completely* off
> topic) to a problem with the USB/RS232 adapter that I'm using. If
> anyone out there has one of these that they are using with OS/X and
> would be willing to help out by doing a quick experiment, please do this:
>
> 1. Loop back your adapter by connecting pin 2 to pin 3 (on the serial
> side, not the USB side).
>
> 2. Plug it in. Fire up a terminal. Find the device. On my machine it
> appears as /dev/cu.PL2303-001113FD and /dev/tty.PL2303-001113FD but it
> will almost certainly be different on your machine. (You can tell which
> one it is because the device file will disappear when you unplug the
> adapter.)
>
> 3. Type: "cat /dev/cu.PL2303-001113FD" (or whatever it is on your
> machine -- you want the CU file, not the TTY file).
>
> 4. Fire up a second terminal window and run this little Python script:
>
>
> s=open('/dev/cu.PL2303-001113FD','w') # Replace with your file name
> def foo(flag):
> for c in '11 22 33 44 55 66 77 88 99 AA BB CC DD EE FF\n':
> s.write(c)
> if flag: s.flush()
>
>
> Now call foo a couple of times. You should see output in the other
> terminal window. (If you don't you probably haven't looped back your
> serial connector properly.)
>
> Try calling FOO with FLAG set to 0 and then 1. (Try it a few times.)
> If the output is the same in both cases please contact me. I get
> corrupted output when flag is 1, which seems to be the reason that
> ADTPro is not working.
>
> Thanks!
> rg
Hey Ron,
what driver did you end up using? The one from Prolific, or something
else?
(I'm currently tearing my hair out over this adapter, and I don't have
hair to spare)
Neil
On Jun 15, 12:49 pm, Ron Garret <·········@flownet.com> wrote:
> Cancel this request. I figured it out. There is a bug in the IOGear
> driver. But I found a new driver that works. Disk images should be up
> shortly unless Murphy decides to nail me yet again.
>
> rg
>
> In article <·······························@news.gha.chartermi.net>,
> Ron Garret <·········@flownet.com> wrote:
>
> > I've traced the problem that I'm having with ADTPro (which I'm using to
> > try to snarf a disk image of P-Lisp, so this is not *completely* off
> > topic) to a problem with the USB/RS232 adapter that I'm using. If
> > anyone out there has one of these that they are using with OS/X and
> > would be willing to help out by doing a quick experiment, please do this:
>
> > 1. Loop back your adapter by connecting pin 2 to pin 3 (on the serial
> > side, not the USB side).
>
> > 2. Plug it in. Fire up a terminal. Find the device. On my machine it
> > appears as /dev/cu.PL2303-001113FD and /dev/tty.PL2303-001113FD but it
> > will almost certainly be different on your machine. (You can tell which
> > one it is because the device file will disappear when you unplug the
> > adapter.)
>
> > 3. Type: "cat /dev/cu.PL2303-001113FD" (or whatever it is on your
> > machine -- you want the CU file, not the TTY file).
>
> > 4. Fire up a second terminal window and run this little Python script:
>
> > s=open('/dev/cu.PL2303-001113FD','w') # Replace with your file name
> > def foo(flag):
> > for c in '11 22 33 44 55 66 77 88 99 AA BB CC DD EE FF\n':
> > s.write(c)
> > if flag: s.flush()
>
> > Now call foo a couple of times. You should see output in the other
> > terminal window. (If you don't you probably haven't looped back your
> > serial connector properly.)
>
> > Try calling FOO with FLAG set to 0 and then 1. (Try it a few times.)
> > If the output is the same in both cases please contact me. I get
> > corrupted output when flag is 1, which seems to be the reason that
> > ADTPro is not working.
>
> > Thanks!
> > rg
>
>
In article
<····································@8g2000hse.googlegroups.com>,
Neil Baylis <···········@gmail.com> wrote:
> Hey Ron,
>
> what driver did you end up using? The one from Prolific, or something
> else?
Yep, the Prolific driver works. But it does NOT work with the IOGear
adapter.
It breaks down like this: the IOGear driver "works" with the IOGear
adapter and the two no-name adapters that I bought. But it's buggy with
all three adapters. If you send characters to it in just the right way
then you get random data corruption.
The Prolofic driver works flawlessly with the no-name adapters, and not
at all with the IOGear adapter.
So the most expensive adapter, and the only one that is specifically
advertised as working with Macs, is the only one that in fact does NOT
work with Macs. And the way in which it does not work is nasty and
pernicious.
I have sent an email to IOGear support informing them of the problem. I
have gotten no response. I am not surprised.
rg
Hmmm,
I'm having a problem that I suspect might be related to the adapter.
(Mine's one of the no-name ones, sold by Best Buy). I'm using the
Prolific driver on a G4 powermac with leopard. My application is an
RS485 party line at 115K Baud, so I get bursts of about 10 to 30 bytes
coming in when remote nodes respond to a poll.
Sometimes it looks as though a remote node fails to respond to a poll.
At the moment I can't tell whether this is a failed transmission, or a
failed response.
As a way to eliminate the USB/Serial adapter or driver as a source of
the trouble, I compiled the same code on an old linux box, which has a
real serial port. I only got this working this morning, but early
tests look promising. Not a single missing response so far.
If this is caused by the problem you were seeing, then there's at
least one other adapter (in addition to the IOGear) that fails with
the Prolific driver. Or I may be encountering a separate problem that
affects input. Either way, I'm about ready to chuck these USB/Serial
adapters.
Neil Baylis
In article
<····································@l64g2000hse.googlegroups.com>,
Neil Baylis <···········@gmail.com> wrote:
> Hmmm,
>
> I'm having a problem that I suspect might be related to the adapter.
> (Mine's one of the no-name ones, sold by Best Buy). I'm using the
> Prolific driver on a G4 powermac with leopard. My application is an
> RS485 party line at 115K Baud, so I get bursts of about 10 to 30 bytes
> coming in when remote nodes respond to a poll.
>
> Sometimes it looks as though a remote node fails to respond to a poll.
> At the moment I can't tell whether this is a failed transmission, or a
> failed response.
>
> As a way to eliminate the USB/Serial adapter or driver as a source of
> the trouble, I compiled the same code on an old linux box, which has a
> real serial port. I only got this working this morning, but early
> tests look promising. Not a single missing response so far.
>
> If this is caused by the problem you were seeing, then there's at
> least one other adapter (in addition to the IOGear) that fails with
> the Prolific driver. Or I may be encountering a separate problem that
> affects input. Either way, I'm about ready to chuck these USB/Serial
> adapters.
>
>
>
>
> Neil Baylis
The particular problem I encountered turns out to be very easy to
reproduce. Loop the adapter back on itself (i.e. connect pin 2 to pin
3) so it will read its own output. Then send it a bunch of characters
and call flush() after each character with no time delay. You will lose
about 5-10% of the data. If you don't see data loss this way then
you're not having the problem I had.
rg
>
> The particular problem I encountered turns out to be very easy to
> reproduce. Loop the adapter back on itself (i.e. connect pin 2 to pin
> 3) so it will read its own output. Then send it a bunch of characters
> and call flush() after each character with no time delay. You will lose
> about 5-10% of the data. If you don't see data loss this way then
> you're not having the problem I had.
>
> rg
Ron, it seems that like me, you thought that the flush should block
until everything in the buffer has been sent. In fact it discards
anything that had been put in the buffer, but not yet sent on the
wire. In the case of a USB-Serial adapter, 'sending-on-the-wire' means
just copying to some USB buffer, which is normally very quick.
Sometimes though, when you get to the flush, nothing has been copied
and the flush throws it all away. If flush is called immediately after
writing some data, there's a race which is usually won by the copy.
When it's won by the flush, you get dropped bytes.
Bottom line: I removed the flush from my code, and now it works
perfectly. I think this is not a bug, but just how flushing output
works for serial ports. Your post cast suspicion on the flush, which
led me to fix the problem, so thanks.