VISA Read function slower for USB VCP than "real" serial port

[JÞB]

---

@Edjsch wrote:

Jeff,

Initially I thought too that there might be a bug in VISA, but now I think not. I think the bug (really poor coding) is in the SiLabs driver because other drivers work as expected, with over 1000 times shorter delays (time stamps) around the reads (at least that's what the Portmon logs show).

Ed

---

AHHHH but Silabser seems fine when called from hyperterminal- so....Dink with the VISA settings and see if it can be made to work when called through VISA.

[Edjsch]

Jeff,

No, Silabser is NOT fine when called from HyperTerminal. I told you that the Portmon logs still show several millisecond time stamps around the reads, while the other drivers show in the microseconds, over 1000 times faster. The reason HyperTerminal keeps up with 250 RPS is that it is doing 80 bytes per read.

Ed

[JÞB]

Ahhh. 

Has Stephanie House (SiLabs) [MCU.Support@silabs.com] provided any of her <not so>"Super Secret" utilities?

[Edjsch]

Jeff,

No, it was Peter E, NI Applications Engineer who had me try Portmon early in this post. Initially Beth from SiLabs was handling my SR, but it has been passed off to Stephen To. He is working on it now.

Ed

[JÞB]

keep us posted- good lick

[Edjsch · Accepted solution]

Hi All,

Silicon Labs finally got back to me Monday, and I waited until now because I was testing. Here's what they told me:

"On Feb 17, 2010, we released v5.4.29 with the following fix as indicated in our release notes: "Fixed a bug which causes GET_COMM_STATUS to take longer than expected". I believe this should address the ~5ms IOCTL_SERIAL_GET_COMMSTATUS shown in the PortMon log you provided."

Here is a link to the drivers and information: http://www.silabs.com/products/mcu/Pages/USBtoUARTBridgeVCPDrivers.aspx

I went right to the latest version, V6.5 (seems that they have an update every other month or so!). It did solve the problem of the slow reads, but there were a few dozen strings with errors in the 2500 reads in a 10 second test at 115 KB. At 38.4 KB there were no errors. There were no errors with the Prolific converter at 115 KB. The time stamps in the Portmon logs were in the range of 10 to 90 microseconds, compared to 1 to 2 microseconds with the Prolific driver. SiLabs is now looking into this.

(As a note, the new driver now uses the same installer for Windows 7 as for earlier Windows versions. The old installer had 2 separate installers which the user had to pick. I also noted that on my XP PC, when I connected my USB VCP device, it ran the installer, updating the driver, but I really have to reboot the PC for it to work, as Windows indicated. Previously, I guess when the versions were in the 5's, a reboot when upgrading was not necessary even when Windows said "you may need to reboot.")

So it did turn out to be a driver problem after all. The first SiLabs apps engineer should have told me this months ago. She obviously didn't know. If she had contacted the driver developers they surely would have told her. I asked the second apps engineer how he found out about this driver fix, but he hasn't gotten back to me on this yet. Anyway, thanks all for your inputs and patients with me trying to resolve this problem. As usual when debugging and trouble-shooting, I went down many avenues to no avail, other than ruling them out!

Ed

[Alisha_P]

Hi Ed,

Great to hear! I hope SiLabs will be able to fully resolve the additional issues.

Happy coding!

[JÞB]

Outstanding. It does not sound 100% fixed yet. But, Si is still working with you. thank you for keeping us informed and, for all your hard work

[Edjsch]

Jeff,

And thank you for your help and suggestions. I was totally thrown off the track because when I started using LabVIEW about 5 years ago I had purchased the NI USB-Serial converter, and it as well as all the other converter / "bridges" I tried were all quite a bit slower than a real serial port. I though it was just the nature of the beast, that since they all use the USB bulk transfer mode, which was not designed for real-time data flow, it was what it was. That's just how they functioned. I did not retry the NI converter when Alisha said her tests replicated the performance of a real serial port. We though it might have something to do either with my block diagram or the PC. When that did not make a difference for me I decided to retest some converters we had lying around. (The one with the Prolific driver was here by chance.) I was quite shocked, really pleasantly surprised, to see that 2 of them worked about as well as a real serial port, as Alisha said. Over the years the driver design obviously improved quite a bit.

Since the bulk transfer mode is for data going mostly one-way with guaranteed data integrity but not guaranteed latency, it's not that surprising that a full-duplex serial port has an edge. But with high speed USB having higher frame rates than the 1 millisecond of full-speed devices, there is hope there, too, of fully emulating COM port performance.

Thanks again,

Ed