Serial port failure

[Nick Craig-Wood]

Rob <Amateur.N7TZG at gmail.com> wrote:
>  Craig,
> 
>  In the embedded firmware, the each box re-transmits after it finishes
>  reading the packet.  This is a very rudimentary system, and uses no
>  flow control.  The topology is that each embedded box has a master and
>  a slave port.  The master is used to receive data from the upstream
>  box, and send acks or naks back to the upstream box.  The slave is
>  connected to the master of the next downstream box.
> 
>  Does that clear up the picture a little bit?

Sure!

I suggest you run with the rest of my post and see what happens...
I've seen dozens of broken serial port drivers over the years!

...

My advice is to try a different serial port hardware.  I've found ones
based on the PL2303 chip to be very reliable both under windows and
linux.

Eg this one :-

 http://www.scan.co.uk/Products/ProductInfo.asp?WebProductID=98192

Or one of these (which were based on PL2303 last time I bought one)

 http://www.comtrol.com/products/catalog.asp?group=usbserialhubs

I don't think anything you can do from python/user-space should be
able to lock up the kernel mode serial driver.  If it does lock up it
is a driver bug.

Here you'll find a little program I wrote which, with the help of a
loopback connector, you can check your serial port out

 http://www.craig-wood.com/nick/pub/cambert.exe

Run the program from a cmd prompt and it will tell you how to use it.

I've broken a lot of serial port drivers with that program ;-)

-- 
Nick Craig-Wood <nick at craig-wood.com> -- http://www.craig-wood.com/nick