PC USB interfaces

[Dajgoro]

Hi.

For a project that I am working on I need a PC USB interface that is able to receive a set of bytes, and instantly read a response byte. I want to have a system where I can read some registers in a device. I already have a FT245RL module, but the problem is that it waits 2ms minimim to flush the fifo registers, so if my PC program were to issue a read command to the device it would have to wait at least 2ms for a reply, which in my case is very impractical. The FT245RL also has a bit bang mode, with a adjustable baud rate, which would fit my needs, if it only worked. Every time I try the set baud rate command nothing happens, the baud rate is always 9600 no matter what I do. Also the datasheet and application notes are a bit unclear how can I get strobe signals when new data arrives, or data is read. The wr and rd pins are marked as input, and yet it says that there is a strobe signal?
Is there a way to fix this issue, and are there other inexpensive USB interfaces like the FT245 that can run at high speed, and have a fast response time.

[motocoder]

I don't think you are going to do much better than 1ms each way, 2ms round trip, with USB. It's designed for reasonable streaming speed, not for ultra low latency on short transmissions.

Personally, I like the FT232H, which although not perfect, has some flexibility in how you use it (look into the MPSSE). I also like that FTDI has a DLL that interfaces with their driver, so that I can write user-mode code to do everything I would need to do with the chip without having to write a driver.

That said, you won't do better than the limits I mention above, even with the FT232H.

[motocoder]

By the way, maybe you could provide some more details about what exactly the project is and what you are trying to do. It might be possible to move some of the smarts out of the PC so that you don't have this requirement. However, without more details, no one can really comment on that.

[free_electron]

you can't go faster than the inter-packet timing of usb. for the RL ( which is a low speed device , max 12 MHz) this is 1 millisecond.
even if you send the flush command you cannot go faste rthan 2 packet since both the data and command leave in individual packets.

This is the nature of USB ! cannot be changed.
if you switch the device in bitbang mode and use the MPSSE engine (don't know it the RL has that) you can construct your own packet containing both the data and the command. in this case it can execute within a single frame. but yo are still stuck to the 1mS packet interval for low speed.

Now, the above is the BUS operation. the FTDI adds on top of that a delay  to avoid it stalling the bus. by DEFAULT this is 16 milliseconds. ( at least for the R series, i don't know for the others. read the manual. (AN232B-04 is a good reference) you can reprogram that down to 1mS with a command.

it is important to stress that, for speed , data should NEVER be sent as individual bytes. every operation costs you a 1mS frame delay. the usb smallest USB packet size is 64 bytes. use them. create a local buffer of 64 bytes, and pass the buffer.  instead of sending 1 byte every 1mS you can now send 64 bytes every 1mS
By DEFAULT the ftdi assumes packets of 4096 bytes... so it waits until it times out and then executes... this information is stored in the inf file for the driver. you can edit this.

you can auto flush the buffer if you connect the DTR to DSR ( data terminal ready to data set ready) pins. and enable hardware handshaking. but that only works in serial mode.

Things change when you go to the 480MHz operation ( the H versions like the 232H) here the packet delay is 1.2 microseconds and you can go much faster.

[motocoder]

Things change when you go to the 480MHz operation ( the H versions like the 232H) here the packet delay is 1.2 microseconds and you can go much faster.

Totally disagree. I am quite familiar with this part, and you're not going to beat 1ms (on Windows anyway).

[Dajgoro]

So you are saying that I can't send a packet in less than 1ms.
But what is that baud setting for the bitbang mode? Why is it in the datahseed and application notes in the first place?

Anyway, what I am trying to achieve is to have something like a GPIO for my pc. It doesne't have to be super fast but a 1ms delay is too slow. A propose made PCI module would probably solve the problem, but what if you have a laptop?

What about usb 3.0?

[motocoder]

So you are saying that I can't send a packet in less than 1ms.
But what is that baud setting for the bitbang mode? Why is it in the datahseed and application notes in the first place?

Anyway, what I am trying to achieve is to have something like a GPIO for my pc. It doesne't have to be super fast but a 1ms delay is too slow. A propose made PCI module would probably solve the problem, but what if you have a laptop?

What about usb 3.0?

Window is just not a real time OS. The timeslice in Windows is 1ms, which means even if there were zero overhead in the driver and the USB protocol, it's very likely your program might not be able to react within 1ms because some other program has control of the processor for at least that long And in reality, it's even worse than that, because to talk to USB, the data goes into memory in user mode, and then gets transferred to a buffer managed by the driver in kernel mode, and then is streamed out over USB, including any protocol overhead there.

If you just need to control GPIO with microsecond timing, you can use the MPSSE mode of the FT232H to do that, but if you need to read GPIO and then conditionally take some action before writing some other GPIO, your better off attaching a micro-controller to be an intermediary for the PC. You could pick up an Arduino for $20 and use that. It's plenty powerful for this kind of thing.

[Dajgoro]

Yes I know that I can't get true real time performance, but 1ms is just too slow.
FT232H looks interesting, such a module is 27$ on ebay, might get one to poke with.

You could pick up an Arduino for $20 and use that. It's plenty powerful for this kind of thing.

That is exactly what I am trying to avoid here.

[Skimask]

No matter what you get, if its got a USB cable on it, you're going to get variable latency courtesy of Windows.  Case closed.  You'll never get microsecond accuracy, or even 10's of microseconds of accuracy over a USB connection without doing some serious low level programming.
If you had a parallel port on the laptop, you could use a Linux real time kernal like LinuxCNC uses to drive stepper motors.  Thinking that would be more hassle than its worth though.

[rob77]

USB is imply not designed for low latency IO. forget the USB and use a dedicated micro for the low latency IO.
or make a PCI express (card express for laptops) GPIO board with some FPGA chip (not sure about the availability of open PCIe cores because you have to pay to pci sig - and it's freaking expensive ). but even with your PCIe card you will need a realtime(like) OS. another option would be to run your code in kernel space - probably inside interrupt handlers  (generally it's a bad idea and should be avoided).

[Dajgoro]

So, a crusty old C64 has better I/O latency than a modern day PC. Looks like I'll have to be a bit creative about my project...

[rob77]

So, a crusty old C64 has better I/O latency than a modern day PC. Looks like I'll have to be a bit creative about my project...

the crusty C64 has a better or comparable IO latency as USB, not a modern day PC. a modern day PC with a dedicated PCI(e) IO card and realtime/low-latency kernel can do much better.

[Dajgoro]

the crusty C64 has a better or comparable IO latency as USB, not a modern day PC.

I was referring on a pc with no specialized cards.

A while ago I found something on the web about PCI-e cards:
http://www.fpga4fun.com/PCI-Express.html

But that is an entire other scale.
I might try it some day.

[Jeroen3]

The only way to achieve these latency's with Windows is in kernel mode with a driver for the on-board parallel or serial port*. And even then they are not guaranteed since Windows is famous for severe latency issues. Ask the sound guys.
This is one of the problems you find when searching for cnc millers.

*not on laptops, these respond different due to energy savings.

[free_electron]

Whay is everyone blabbering about latency and windows ? You can perfectly do massive bulk transfers with almost no latency. A Storage class or stream mode over usb can do this perfectly fine. Just not VCP !
Windows has nothing to do with usb latency. Yes there is the overhead in the operating system ,but the HARDWaRE of usb has its own latency. For low speed and high speed (1.5 and 12) this is 1 millisecond. This is in the usb hardware ! For a full speed device (480) this is 1.2 microsecond.

You can perfectly send data very fast but you need to use the drivers properly. Create packet in a buffer, pass the buffer to the transport.
If you need to write two bytes followed by one read, and you do this by callin the transmit twice and the receive once you have 4 packets. Two transmit, 1 request to read, 1 return.

Usb is a freight train with an endless chain of wagons. You need to wait for an empty wagon. These co me at 1 millisecond intervals. Each wagon holds 64 bytes. If you only throw in 1 byte. Too bad.

If someone else uses the same bus wagons will be occupied.

You need to check where the root hub is in your machine. A computer with 4 usb ports does not have four co trollers ! It has one co troller with a root hub and 4 ports. You are sharing !

The same crap goes for simp,e usb hubs. Many do not have interspeeders and reframers ! Stick one 12 mbit device like a mouse on there and the packet rate drops to 1 millisecond.

Go read the datasheets of the cypress hub co trollers. You will find the expensive ones refram low and full speed over a full speed link. The cheapo's don't.

Usb is a best effort bus. Not a guaranteed link.

I use the 2232h to stream data to an fpga and it goes very fast. I use MPSSE mode and create my own packets. I bypass the libraries from FTDi and talk directly to the D2xx driver. The libraries have tremendous overhead and are full of bugs.

[motocoder]

Whay is everyone blabbering about latency and windows ? You can perfectly do massive bulk transfers with almost no latency. A Storage class or stream mode over usb can do this perfectly fine. Just not VCP !

Yes, USB can stream sequential packets with inter-packet delay with less than 1ms latency. So what? Did you even bother to read the thread before sounding off?

The OP wants to send a request from his USER MODE PROGRAM through some vendor-provided, pre-existing driver which will turn this into a request over USB to some device, which will then read the current state of some GPIO pins and send a response over USB, which will then be processed by the driver and turned into a response to the user-mode program, whose thread will eventually be woken up by the OS to receive and process the response. Then the process will repeat as the user mode program calculated the correct state of the GPIO an sends another request to set that.

If you can do all that in 1ms, than by all means please share this magic coding trick, as I would like to use it to go back in time and make some stock investments.

If your suggestion was that this person, asking a basic question like this, should write his own kernel-mode driver to control hardware whose interface (at this level) is completely undocumented, then, well, I think the absurdity of that suggestion is self-evident.