The only reason I can think of for getting a zero byte packet is the device sent a zero byte packet. The host is not going to invent one otherwise. This is where a hardware bus analyser would be really handy, you could see your device sending the zero length packet.
I wouldn't put it past your device to be inserting the zero length packet. As your transfer is exactly one max packet size long, it is unclear that one packet is a complete transfer, not just the first part of a longer transfer. Inserting a zero length packet (at the device end) is one way to clear up this ambiguity.
You could try setting the max packet size to a larger value, but still send only 18 bytes. That way it is obvious that each packet is a complete transfer.
On May 27, 2010, at 11:05 PM, Brian Willoughby wrote:
> The Max Packet Size of my endpoint is 18. My read buffer is 9 UInt16 words, or 18 bytes. My firmware never sends more than 18 bytes (or less, at this point).
>
>
> On May 27, 2010, at 22:53, Fernando Urbina wrote:
>> What is the maxPacketSize of your endpoint and what is the size of your read buffer?
>>
>> - Fernando
>>
>> On May 27, 2010, at 11:13 PM, Brian Willoughby wrote:
>>> On May 27, 2010, at 16:00, Barry Twycross wrote:
>>>> On May 27, 2010, at 3:36 PM, Brian Willoughby wrote:
>>>>> I am just bringing my newly-designed USB device online for the first time. Prior to now, it's only be Control endpoint transactions for Descriptors. Now, I've added an 18-byte Interrupt Input endpoint with a Polling Interval of 10 ms. In my code, I call ReadPipeAsync once to prime my one buffer, and in the callback I recycle this buffer to keep the data flowing. Everything seems to be working fine with no loss of data except that I get 0-byte packets every other time.
>>>>>
>>>>> My question is this: What piece of code is responsible for throttling the Interrupt Input endpoint to one packet per 10 ms? Is that even a desired goal? Would the rate vary according to USB load?
>>>>
>>>> The hardware, in combination with the host controller driver, does what you're calling "throttling". The host controller driver arranged for the host controller to execute a schedule for the periodic endpoints (Interrupt and Isoc) then the host controller does its thing on its own.
>>>>
>>>> You should be aware that the specified period is a maximum period between attempts to access the device, while a request is outstanding on the interrupt pipe. The actual period of access can, and most likely will, be shorter than that specified. The USB spec allows the host to poll the device every frame (for full/low speed devices) or every micro-frame (for high speed devices). 10ms endpoints are likely to be polled at 8ms instead, or even 4ms or 1ms under certain circumstances. The device has to cope with this.
>>>>
>>>>> My device firmware does not currently throttle the Interrupt IN endpoint. I basically keep the 18-byte data up-to-date at all times, with the most recent values, and then send the whole packet whenever the USB transceiver call my code. I don't want to get too deep into my firmware description, since that's obviously off-topic for Apple USB.
>>>
>>> Anyway, the one remaining question for me is why am I getting 0-byte packets now? What I see is a regular alternation between 18 bytes and 0 bytes, even though my firmware code always sends 18 bytes.
>>>
>>> In other words, under what conditions would OSX return a 0-byte packet to the ReadPipeAsync() callback? Is this 100% controlled by the USB device? If so, I suspect that the USB transceiver hardware may be sending a NAK because it's busy, and thus my firmware isn't what's creating the 0-byte packet but rather the USB hardware. Otherwise, the reason I ask is that if OSX is deciding to return a 0-byte packet because of how fast I'm calling the API, then I probably need to know this. If, instead, it's not OSX, then I can probably just ignore it, especially since I plan to take your advice and purposely send NAK when the data is unchanged.
>>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Usb mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
--
Barry Twycross
email@hidden
---
USB, it's not a Dyslexic BUS. (Thanks to TC.)
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Usb mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
