[Coco] Drivewire over PI was: The BIGGEST PROBLEM with (So-Called) NEW CoCo Hardware...

Aaron Wolfe aawolfe at gmail.com
Tue Mar 7 12:32:44 EST 2017


On Tue, Mar 7, 2017 at 12:24 PM, Aaron Wolfe <aawolfe at gmail.com> wrote:
>
> On Tue, Mar 7, 2017 at 12:06 PM, Brett Gordon <beretta42 at gmail.com> wrote:
> >
> > I and another person have had similar problems Tim.  I investigated, and
> > found very high latency is the problem.  The PI's software USB coupled
with
> > a cheap-o USB->RS232 do-hicky make for horrible latency.  So latent the
DW
> > server times out.  Every thing got peachy after I upped my drivewire
> > server's timeout.   I don't know how to do this in Aaron's java based
> > server though :(  I used William's 'lwwire' server to make it work.
>
> The timeout is fixed in the specification, and I believe implemented to
some degree on the Coco side of things as well.
> I don't recall if there is a setting to ignore it in the server I wrote,
but even then I'd still be a bit worried about things going the other way
and timing out on the coco too.
>

Looks like you can specify:

<ReadByteWait>200</ReadByteWait>

In any instance section of the config.xml to change the timeout for serial
reads in that instance.. 200ms is the default if not specified.  Can't
promise that is implemented correctly and consistently but worth a shot if
it might help someone.

Also, here are the instructions I wrote for FTDI adatper performance, its
essentially the same issue as timing out when extremely bad:

While working on DW4, I found that my FTDI adapter performed about 20%
slower than my Prolific adapter and a 16550 "real" serial port. There is a
simple change that can be made in the FTDI driver's settings to bring it's
performance in line with the other hardware.

Simply change the "receive buffer latency timer" to 4ms (from the default
16ms). In Windows, this is done in the properties of the adapter,
accessible from device manager.


More information about the Coco mailing list