keithI’ve gotten away thus far without any flow control. I just started noticing that my software was locking up occasionally when reading a disk. It was locking up in the “read” portion of the code because it wasn’t receiving enough data. When I rewrote the read routine (which is much cleaner now, btw), I implemented a small receive timeout, because I really should be getting all the data within 150ms(timeout currently set at 300ms). With my new read routines, I noticed times right around 125ms which is almost exactly the time it should be taking —- meaning that there isn’t any inherent dead time with my new routine. This is good.
In any event, I don’t know how or where exactly this “lost data” problem has cropped up, but I’m almost positive it’s related to the lack of flow control on my serial interface. Some people have really stressed that I must have flow control, but I haven’t seen any dropped data, until now. So I haven’t really worried about it. It’s really worked flawlessly in the past, but I’m now getting a short read every now and again.
I think flow control is easy enough to implement. I have a spare pin, although I’m starting to get short. The Parallax USB2SER ties the DTR pin of the FTDI FT232BM usb-to-serial chip to Parallax’s RES pin. What this means is that if FTDI’s VirtualComPort(VCP) drivers support hardware DTR flow control, then the drivers should drop DTR if the PC/USB chip is getting overrun.
Inside my sendusb() routine, I’ll have a small check that looks like:
waitforDTR:
if RC.5 = 1 then waitforDTR
And this will be checked before each byte is transmitted. The reaction time should be instant, if DTR is not high, then my code will wait for it to come high. I’m pretty sure that the FT232BM warns at 32-bytes, so I actually have plenty of time.
I don’t pretend to understand USB. The USB reads have to be scheduled by the OS, and I guess if the OS gets too busy, it doesn’t have time to service the USB port, and the data falls on the floor. While I haven’t seen this before, perhaps I’m running too many background apps etc to properly service the USB requests.
Did I say this was going to be easy???!?
I ended up lifting the damn solder pads off the connections as a result of unsoldering a couple header pins. As a result, my debug header, for at least a couple pins now does not work at all because the solderpad connected the various traces together. so I ended up soldering some wires ala my resistor (from the dip pads) to my USB2SER device.
PAIN-IN-THE-ASS
BUT anyways, I’ve added flow control, and I think its working. I think I had my logic wrong up there, as I’m using a JNB in my actual code.
I haven’t quite tested high speed tests yet…. but we’ll see. stay tuned
Retarded point #2.
RXTX doesn’t appear to support DTR/DSR based handshaking.
I tested it under some dumb terminal software, and I set my microcontroller to pound the USB interface with data. Logic analyzer saw the DTR lead drop once the buffers got saturated.
Same test with my java code opening the serial port, and not a damn thing happens. The API mentions RTS and CTS, but no DTR/DSR for flow control.
I checked Microsoft under C++, and they support it. They call it DTR Control Handshaking.
Ahhh well. RTS is not tied to anything on my USB2SER device, but being LQFP, I doubt I can get access to the damn lead. (only DTR, TX, RX, GND is brought out to female headers)
I was thinking XON/XOFF, but then I have to look at simultaneous xmit and receive. yuck.
hrrrrrmmmmmmmmm.
I’m seriously considering moving towards FTDI’s D2XX interface to replace using virtual com port drivers and RXTX. While the virtual com port drivers are very good and work fine in a number of applications, RXTX adds yet another layer of code between my application and the serial port. While I’m not versed enough to fully understand how RXTX fits into the picture, I get the impression that the code “gets-in-the-way” between the native interface of the USB2SER. As a result, I don’t have access to the full range of features supported under the device.
The D2xx are “direct drivers” and are well supported at FTDI on a variety of OS’s. In Windows, it shows up as a .DLL.
The only problem I see is that there isn’t a native Java interface to access the functions. However, there is a freeware java interface to the direct USB driver. My understanding, so far, is that it allows full access to the .DLL’s functions.
I noticed that things just didn’t work quite right with RXTX, read timeouts never worked right, reading a specified number of bytes always came back with less (or never came back at all), etc. There were several issues. I’m not blaming RXTX because it takes two (or three) to tango.
I think by accessing the native functions (even through a java wrapper) will be more direct, more reliable.
The wrapper itself has only been tested with Windows, but the author thinks Linux should be ok too. So I might be sacrificing compatibility, but I’d rather end up with a better finished product on one or two platforms than a shaky one on more.
see https://bleyer.org/jd2xx/ for the wrapper and https://www.ftdichip.com/Drivers/D2XX.htm for the direct drivers.
[…] I said in an earlier comment, jd2xx is a java wrapper for interfacing to the direct USB drivers for my USB-serial converter. […]