Rob <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> -- http://www.craig-wood.com/nick -- http://mail.python.org/mailman/listinfo/python-list
