On Jan 5, 2017, at 11:22 PM, Scott Deandrea wrote:
> Correct, for a submitted request on the default control pipe is the maximum
> amount of data requested. The ioLength for a completed request of
> non-isochronous pipes will be equal to the amount of data payload transferred
> on the bus. I
Yes, you can think of the lower bits the frame number and the upper bits the
number of overflows.
There isn’t any reason to interpret it as anything other than a 64-bit integer
nor to specify the division.
—scott
> On Jan 5, 2017, at 10:35 PM, Guy Harris wrote:
>
> On Jan 5, 2017, at 10:11 P
Correct, for a submitted request on the default control pipe is the maximum
amount of data requested. The ioLength for a completed request of
non-isochronous pipes will be equal to the amount of data payload transferred
on the bus. I’m not following what/how you would check that. The link-lay
On Jan 5, 2017, at 10:11 PM, Scott Deandrea wrote:
> An interrupt is generated when the frame number rolls over and we use this to
> increment the upper bits so the frame number can grow beyond 11 bits. This
> allows software consuming the frame number not to worry about the frame wrap
> when
On Jan 5, 2017, at 9:59 PM, Scott Deandrea wrote:
> The ioLength for a submitted request will the the amount of data requested in
> the data stage.
So, for a submitted request on the Default Control Pipe, the ioLength won't be
8 for the setup data, it'll be the maximum amount of data requested
An interrupt is generated when the frame number rolls over and we use this to
increment the upper bits so the frame number can grow beyond 11 bits. This
allows software consuming the frame number not to worry about the frame wrap
when scheduling isochronous I/O.
Yes, time *at* which…
—scott
The ioLength for a submitted request will the the amount of data requested in
the data stage. The ioLength for a completed request will be the actual amount
of data transferred in the data stage. It’s quite similar to any other data
pipe.
Just to note, it may be acceptable for a device to sen
On Jan 5, 2017, at 8:42 PM, Scott Deandrea wrote:
> The frameNumber is a USB spec defined value that correlates with the
> start-of-frame packets frame number as defined in section 8.4.3
> Start-of-Frame Packets.
So only 11 of the 64 bits are used?
> The ioTimestamp is in the same Mach Absolu
On Dec 9, 2016, at 1:37 PM, Scott Deandrea wrote:
> The link-layer header format is as follows:
> struct
> {
>// Control information
>uint16_t bcdVersion;// version of this structure
>uint8_t headerLength; // length of this structure
>uint8_t requestType; // t
Yes, that's the behavior I have implemented in Wireshark and our internal
tools.
--scott
> On Jan 5, 2017, at 8:52 PM, Guy Harris wrote:
>
>> On Jan 5, 2017, at 8:48 PM, Scott Deandrea wrote:
>>
>> The mach absolute time base is different between ARM and x86/x64 though
>> developers won’t
The frameNumber is a USB spec defined value that correlates with the
start-of-frame packets frame number as defined in section 8.4.3 Start-of-Frame
Packets.
The ioTimestamp is in the same Mach Absolute Time.
Yes, the way you have described the padding is correct.
—scott
> On Jan 5, 2017, at
On Jan 5, 2017, at 8:48 PM, Scott Deandrea wrote:
> The mach absolute time base is different between ARM and x86/x64 though
> developers won’t have access to packet capture on iOS devices (internally the
> packet capture is used on iOS devices). The developers that would be using
> this softw
The mach absolute time base is different between ARM and x86/x64 though
developers won’t have access to packet capture on iOS devices (internally the
packet capture is used on iOS devices). The developers that would be using
this software capture are familiar with the Mach Absolute Time format
On Dec 13, 2016, at 8:38 AM, Scott Deandrea wrote:
> The timestamps are in Mach Absolute Time Units
> (https://developer.apple.com/library/content/qa/qa1398/_index.html).
That says
This unit is CPU dependent, so you can't just multiply it by a constant
to get a real world value. Rathe
Hi Guy,
Any update on allocating a DLT value? Perhaps #define DLT_MACOS_USB 266?
—scott
> On Dec 13, 2016, at 8:38 AM, Scott Deandrea wrote:
>
> Yes, if there are fewer tiers of hubs, the unused nibbles will be zero.
>
> Correct, the padding is only added if frameLength isn’t a multiple of 4
15 matches
Mail list logo
