"How could I determine the latency"?
I use an oscilloscope to determine typical latencies.
I investigate the source code and hardware to get a conservative estimate of the worst-case latency.
If I had to measure the typical transmit and receive latency of some particular setup, I'd start with the simplest measurement: typical round-trip delay.
Perhaps something like this would be relatively easy to set up:
- Software on the Arduino turns on an LED, and then immediately sends a message out the UART
- you have the UART pins connected to the appropriate level-shift IC connected to your USB to EIA-485 converter.
- Software on the PC waits for serial input, and then immediately send a short response message
- Software on the Arduino waits for serial input, and then immediately turn on another LED.
Software on the Arduino waits some random time, turns off all the LEDs, waits some more random time, then starts over with turning on the first LED.
you connect the o'scope up to the 2 LEDs and measure the typical delay between the first LED turning on and the second LED turning on.
- you recompile with different message sizes; make a graph of message size vs. typical delay.
A real-time system must have bounded worst-case latency.
Alas, that doesn't seem possible with Windows -- even if you could get the source code for Windows, a device-driver patch next week might add another 2 milliseconds of worst-case latency.
Some real-time operating systems support USB -- in particular, EMC running on Linux running on RTAI supports USB -- hidcomp, Custom USB input device with emc, etc.
USB has a "isochronous transfers" and "interrupt transfers" that seem like they could be useful for bounding worst-case latency.
Alas, no one seems to trust USB for real-time tasks:
EMC2 Supported Hardware,
Real time USB control?,
USB problems, etc.
So EMC2 still uses parallel ports to get known worst-case latency;
other low-latency communication protocols use a variety of hardware including Ethernet hardware.