Hi Tom, > [ USB time transfer ] > > It seems to me that if the read path and the write path are different it breaks down. > > ... But turning that into precise time requires some kind of calibration of the actual code path delays. In other words, it sounds to me like your method is valid for frequency transfer but not time transfer.
Yes, but I think the same could be said of other I/O mechanisms. Even a nominally symmetric physical layer, such as Ethernet, becomes a little asymmetric once the general-purpose CPU, software, drivers, interrupts are added in to the Tx and Rx paths. Same for PCIe, although those paths are nearly all hardware. I'm sure USB is somewhat worse than PCIe. Let me dig up the old code and try a one-way calibration against a PCIe GPIO signal. The PCIe write should get out to the wire in 500 ns or so, and the Teensy (or a TIC) can measure that against the USB event that comes along later. Should allow a reasonable estimate of the fixed delay (better than measuring the round-trip total USB transaction time at the CPU and dividing by 2). The fixed delay will be system-specific, though, requiring a calibration for each unique hardware platform, unless the USB round-trip time is small enough to be ignored by the application. Certainly PCI, or better, a CPU GPIO pin, is vastly preferable to USB; but USB is very convenient and available. If USB can be coaxed into good performance, so much the better. Cheers, Peter _______________________________________________ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.