<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="https://community.arm.com/utility/feedstylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>USB HID IN and OUT report when noting to send/receive</title><link>https://community.arm.com/developer/tools-software/tools/f/keil-forum/37985/usb-hid-in-and-out-report-when-noting-to-send-receive</link><description> 
Hello, 

 
I am useing a AT91SAM7 microcontroller with Keil Realview compiler
and USB HID. My code is based on the 
example code of the Atmel SAM7-EK Board. 

 
Does anybody know what to do, when the uController has no data to
send and get&amp;#39;s a request</description><dc:language>en-US</dc:language><generator>Telligent Community 10</generator><item><title>RE: USB HID IN and OUT report when noting to send/receive</title><link>https://community.arm.com/thread/138890?ContentTypeID=1</link><pubDate>Mon, 08 Sep 2008 05:48:18 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:60cee4f7-5464-40d4-9e4a-f20d9af9ae97</guid><dc:creator>Tsuneo Chinzei</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;&amp;quot;I managed to get it working by disableing the interrupt
&lt;b&gt;Out&lt;/b&gt; Pipes endpoint handler in the uC.&amp;quot;&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
I think it&amp;#39;s IN pipe.&lt;br /&gt;
You are still mixing up IN and OUT :-)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;i&gt;&amp;quot;useing REPORTSIZE as the reportsize corresponding to the ReportID
which is smaller size than the largest Report ID (max is
Capabilities.OutputReportByteLength)&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;I get a message - the referenced User Buffer is not allowed
...&lt;br /&gt;
Can&amp;#39;t write to device&amp;quot;&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
For HID device I/O, use always Capabilities.OutputReportByteLength
for nNumberOfBytesToWrite parameter of WriteFile. The
OutputReportByteLength holds the greatest length of the output
report.&lt;br /&gt;
Also the buffer handed to WriteFile should have this size.&lt;br /&gt;
But you don&amp;#39;t need to fill the buffer with padding bytes. Just fill
it with the size determined by the report ID.&lt;/p&gt;

&lt;p&gt;
It&amp;#39;s Windows HID feature.&lt;br /&gt;
I don&amp;#39;t know the reason why MS have designed the API like this.&lt;/p&gt;

&lt;p&gt;
They may consider to write multiple reports at a time using an OUT
buffer on the device driver, though it is not implemented so far.&lt;/p&gt;

&lt;p&gt;
Tsuneo&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: USB HID IN and OUT report when noting to send/receive</title><link>https://community.arm.com/thread/138884?ContentTypeID=1</link><pubDate>Mon, 08 Sep 2008 05:20:12 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:2edb4e1b-7030-4c61-a7c7-107da1ef8668</guid><dc:creator>Oliver Debus</dc:creator><description>&lt;p&gt;&lt;p&gt;
Hello again,&lt;/p&gt;

&lt;p&gt;
I think I have found the solution myself. Windows always reads the
complete buffer with length Capabilities.???ReportByteLength like
Capabilities.InputReportByteLength. The lenth returned by the write
function has nothing to do with the number of bytes acutally
transferred over USB. It is always the maximum size of that report
type ...&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: USB HID IN and OUT report when noting to send/receive</title><link>https://community.arm.com/thread/135497?ContentTypeID=1</link><pubDate>Mon, 08 Sep 2008 02:07:41 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:d86333f7-a34b-4196-ad40-4d22014457f9</guid><dc:creator>Oliver Debus</dc:creator><description>&lt;p&gt;&lt;p&gt;
Hello,&lt;/p&gt;

&lt;p&gt;
Thank you for your answers so far. I managed to get it working by
disableing the interrupt Out Pipes endpoint handler in the uC.&lt;/p&gt;

&lt;p&gt;
Now I have another problem. I have defined several Report IDs.
When I send data on the interrupt Out pipe - and only want to send
the amount of bytes - how to do it.&lt;/p&gt;

&lt;p&gt;
I tried:&lt;/p&gt;

&lt;pre&gt;
                if (WriteHandle != INVALID_HANDLE_VALUE)
                        {
                        Result = WriteFile
                        (WriteHandle,
                        OutputReport,
                        REPORTSIZE, //Capabilities.OutputReportByteLength,
                        &amp;amp;BytesWritten,
                        NULL);
                }
&lt;/pre&gt;

&lt;p&gt;
useing REPORTSIZE as the reportsize corresponding to the ReportID
which is smaller size than the largest Report ID (max is
Capabilities.OutputReportByteLength)&lt;/p&gt;

&lt;p&gt;
I get a message - the referenced User Buffer is not allowed
...&lt;br /&gt;
Can&amp;#39;t write to device&lt;/p&gt;

&lt;p&gt;
What have I done wrong?&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: USB HID IN and OUT report when noting to send/receive</title><link>https://community.arm.com/thread/124893?ContentTypeID=1</link><pubDate>Sat, 06 Sep 2008 02:48:13 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:964e316c-3337-47a5-a2ee-7dd20ff5e877</guid><dc:creator>ImPer Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
Thanks. Yes, I have seen a number of Win application locking up
after removing USB devices. This may be the reason why.&lt;/p&gt;

&lt;p&gt;
My standard code for serial communication is using overlapped
transfers, but I haven&amp;#39;t written any USB code yet, and wanted to know
my available options.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: USB HID IN and OUT report when noting to send/receive</title><link>https://community.arm.com/thread/114213?ContentTypeID=1</link><pubDate>Fri, 05 Sep 2008 23:31:30 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:b6c6c30b-831f-4c04-9d01-0471bb643e3a</guid><dc:creator>Tsuneo Chinzei</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;&amp;quot;but another way to let an application to continue while
waiting for data is to split it into multiple threads.&amp;quot;&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
In principle, you are right.&lt;br /&gt;
In these reasons, however, the combination of sub-thread and
synchronous call is not used.&lt;/p&gt;

&lt;p&gt;
a) Thread termination&lt;br /&gt;
While the thread is blocked by the synchronous ReadFile, these calls
are not canceled by CancelIo(). Then there is no way to terminate
this thread at the end of the application. It means, the application
doesn&amp;#39;t finish unless any input comes from the device.&lt;/p&gt;

&lt;p&gt;
CancelIo Function&lt;br /&gt;
&lt;a href="http://msdn.microsoft.com/en-us/library/aa363791.aspx"&gt;msdn.microsoft.com/.../aa363791.aspx&lt;/a&gt;&lt;br /&gt;

&lt;i&gt;&amp;quot;Cancels all pending input and output (I/O) operations that are
issued by the calling thread for the specified file. &lt;b&gt;The function
does not cancel I/O operations that other threads issue for a file
handle.&lt;/b&gt;&amp;quot;&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
b) Error handling&lt;br /&gt;
Synchronous ReadFile/WriteFile often get stuck on surprised removal
of USB device.&lt;/p&gt;

&lt;p&gt;
Then, OVERLAPPED call is applied in the sub-thread, too. And
WaitFor- function is used to make the thread sleep.&lt;/p&gt;

&lt;p&gt;
Tsuneo&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: USB HID IN and OUT report when noting to send/receive</title><link>https://community.arm.com/thread/101035?ContentTypeID=1</link><pubDate>Thu, 04 Sep 2008 09:43:04 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:f3bfc70d-d4ce-4c3e-8469-eaa0a38187ad</guid><dc:creator>ImPer Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
&amp;quot;You have to apply asynchronous (OVERLAPPED) ReadFile(), because
synchronous ReadFile() blocks the thread, until the device returns
input report.&amp;quot;&lt;/p&gt;

&lt;p&gt;
Is this really a requirement? OVERLAPPED is an efficient way to
avoid the blocking, but another way to let an application to continue
while waiting for data is to split it into multiple threads. Then it
doesn&amp;#39;t matter if one thread hangs waiting for data - the rest of the
application can do whatever tasks that needs to be done, and when
data arrives, the communication thread can read it and update
relevant data structures.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: USB HID IN and OUT report when noting to send/receive</title><link>https://community.arm.com/thread/76635?ContentTypeID=1</link><pubDate>Thu, 04 Sep 2008 09:01:58 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:d15933f5-3d8a-46f6-aff2-58f0ed69785a</guid><dc:creator>Tsuneo Chinzei</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;&amp;quot;When the PC has noting to send I do not get an SAM7-uC USB
interrupt for the Interrupt &lt;b&gt;In&lt;/b&gt; Endpoint. However for the HID
Interrupt &lt;b&gt;Out&lt;/b&gt; Endpoint I get interrupts all the time.&amp;quot;&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
Isn&amp;#39;t IN and OUT reversed?&lt;br /&gt;
USB is host centric. Then, IN and OUT is named after the host
side.&lt;/p&gt;

&lt;p&gt;
For vendor specific HID implementation,&lt;br /&gt;
the HID host sends interrupt OUT transaction to the device just when
the host app sends out report using WriteFile.&lt;/p&gt;

&lt;p&gt;
For interrupt IN transaction, HID PC device driver issues IN
transaction periodically by itself.&lt;br /&gt;
- The device driver issues IN transaction just after the device is
enumerated, even when the host app is not running.&lt;br /&gt;
- The input reports from the device are stored to the IN buffer on
the device driver. This buffer is a cyclic one. ( see
HidD_GetNumInputBuffers() )&lt;br /&gt;
- HID host app reads out input reports from this buffer. ie. the host
app doesn&amp;#39;t access to the device directly.&lt;/p&gt;

&lt;p&gt;
For USB, device cannot send any data until the host requests it by
IN transaction. Then, the PC device driver issues IN transaction
periodically, regardless of the status on the device. This kind of IN
transaction is called as &amp;quot;polling-IN&amp;quot; transaction.&lt;/p&gt;

&lt;p&gt;
To handle this IN transaction, you have two options.&lt;/p&gt;

&lt;p&gt;
a) Respond to it just when any change occurs on the device&lt;br /&gt;
b) Always send some data, even if it is the same as the last one.&lt;/p&gt;

&lt;p&gt;
b) is often applied in many USB examples, because the host app is
simpler than a). However, you have to extract change from the data
stream.&lt;/p&gt;

&lt;p&gt;
For a) strategy,&lt;br /&gt;
On the firmware:&lt;br /&gt;
Load data to the interrupt IN EP when the data is generated on your
firmware. Usually, data loading is done in a timer ISR or one of main
loop tasks, in which new data is generated. Not in the endpoint ISR.
You may ignore the hardware interrupt from the interrupt IN EP, or
may use the interrupt just to know the EP is empty.&lt;/p&gt;

&lt;p&gt;
On the host app:&lt;br /&gt;
You have to apply asynchronous (OVERLAPPED) ReadFile(), because
synchronous ReadFile() blocks the thread, until the device returns
input report.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;i&gt;&amp;quot;if I reply a few times with some data and then stop to reply and
then read the data from the host input buffer of the PC using the
visual C++ V6 HID USB api it reports some error.&amp;quot;&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
Just ignore the error.&lt;br /&gt;
I suppose your host app handles it properly using OVERLAPPED. And
WaitForSingleObject() returns timeout error, when no input
report.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;i&gt;&amp;quot;I believe I must answer the requests of the host by sending NACKs
- but the question is how to do it?&amp;quot;&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
Just leave the EP alone.&lt;br /&gt;
When you don&amp;#39;t load any data to the interrupt IN EP, the EP is empty,
and the EP returns NAK to the next IN transaction from the host.&lt;/p&gt;

&lt;p&gt;
The hardware interrupt from the IN EP means that the data on the
EP has been sent to the host, and the EP is empty now. It&amp;#39;s same as
UART TX. It NEVER means the arrival of host request to which your
firmware has to respond immediately.&lt;/p&gt;

&lt;p&gt;
Tsuneo&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: USB HID IN and OUT report when noting to send/receive</title><link>https://community.arm.com/thread/52357?ContentTypeID=1</link><pubDate>Thu, 04 Sep 2008 06:29:46 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:9a6df087-734d-4819-ad5b-d636c0c8fc97</guid><dc:creator>Oliver Debus</dc:creator><description>&lt;p&gt;&lt;p&gt;
Hello again,&lt;/p&gt;

&lt;p&gt;
I believe I must answer the requests of the host by sending NACKs
- but the question is how to do it?&lt;br /&gt;
I can&amp;#39;t find anything in the AT91SAM7S datasheet. Shouldn&amp;#39;t I change
a flag in the UDP_CSRx Endpoint Control and Status Register?&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>