Is it a good idea to use a usb-serial adapter for PPS? Yes, it is.

Per Hedeland per at hedeland.org
Tue Aug 20 13:22:35 UTC 2019


On 2019-08-20 13:50, Hans Petter Selasky wrote:
> On 2019-08-20 13:38, Per Hedeland wrote:
>>
>> I'm sorry, I'm afraid I still don't really understand... The question,
>> at least in my mind, was whether polling was done in a "strictly
>> periodic" fashion, at most once per 125 us for USB 2.0 - or whether
>> the host controller would poll "as fast as it could", which could
>> result in a *much* higher polling rate.
> 
> That depends on the endpoint type. INTERRUPT endpoints poll regularly, one time, every 125 us for example, when a job is queued. BULK endpoints poll all the time, depending a bit on the HC in use.

OK, Ian reported earlier that the FTDI usb-serial adapter he used was
using BULK transfers, so far so good...

> Anyways, the computer is not notified of the completion before the HC is generating an interrupt. This usually happens at some fixed point in time. I.E. multiple completions can be joined into one HC interrupt. It is the completion interrupt which 
> notifies the software about the PPS event.

...but this sounds like we might be back to square one... Is there a
fixed interval between those fixed points in time, and what would the
length of that interval be? And, what is the source for the generation
of the intervals?

On 2019-08-20 13:53, Hans Petter Selasky wrote:
 > On 2019-08-20 13:38, Per Hedeland wrote:
>>
>> This sounds like a method to determine a fixed latency - or am I
>> misunderstanding?
>
> The HC sends out a timestamp, called SOF, to all USB devices every 1ms or 125us. This SOF mark is usually the beginning of the polling schedule. All USB endpoints are polled by the HC. The USB device can predict the time of the SOF and also
> completion on the HC and so I believe adjust the timestamp, so that it would appear to be received instantaneously.

Hm, but this doesn't sound like something an off-the-shelf usb-serial
adapter could or would do, I think?

--Per


More information about the freebsd-arm mailing list