I’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:
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.