PORTS Forum
Ports and Interfaces => USB => Topic started by: dlelievre on November 29, 2012, 02:58:33 pm
-
Hi I have been using Jan's code for a HID device successfully now for a couple of years. However I have always been hampered by the fact that even when the PC does not read from the device it still thinks it is getting reads. I would like to read from some onboard memory and have the memory address increment after each read. However this is impossible a I am always getting a background read command coming through. Is there any way around this problem
Thanks for any help
Dave Lelievre
-
What do mean by "even when the PC does not read from the device it still thinks it is getting reads"?
What is "it" and what makes "it" think it is getting reads?
-
Hi Jan, thanks for getting back to me. I am using your USB HID code on a PIC18F4550. and I am polling around this loop shown below
Now when it goes into the ReportReceive(); routine that calls USBInHandle = HIDTxPacket(HID_EP,(BYTE*)&hid_report_in[0],HID_INPUT_REPORT_BYTES); I provide data in the hid_report_in- array. Well this read routine gets called all the time even if I have not requested a read transfer. I would like data to be read only when requested from my VB6 program. I hope that this is a clearer now
Best Regards
Dave
// Check bus status and service USB interrupts.
USBDeviceTasks(); // Interrupt or polling method. If using polling, must call
// this function periodically. This function will take care
// of processing and responding to SETUP transactions
// (such as during the enumeration process when you first
// plug in). USB hosts require that USB devices should accept
// and process SETUP packets in a timely fashion. Therefore,
// when using polling, this function should be called
// frequently (such as once about every 100 microseconds) at any
// time that a SETUP packet might reasonably be expected to
// be sent by the host to your device. In most cases, the
// USBDeviceTasks() function does not take very long to
// execute (~50 instruction cycles) before it returns.
#endif
// Application-specific tasks.
// Application related code may be added here, or in the ProcessIO() function.
ProcessIO();
}
-
The HID driver on the PC continually requests data from the interrupt IN endpoint. The VB program just reads what the driver has received. So the PIC doesn't know when the VB program is looking for data. An exception would be if you're using a command/response protocol where the PC sends a command and the PIC responds with data.
If the PIC doesn't have a report to send, it shouldn't provide data for the endpoint.
-
OK Thanks Jan, that's what I though but wanted you to confirm. The way you suggest is basically what I am doing but it seems very slow. I send a command to say the next read will be from location x and then perform a read to pick this up. However if I don't put a very big delay between writing the command and reading the data then I pick up incorrect values. Is there any way to speed this up?
Thanks again for you support
Dave
-
Don't arm the endpoint until the PIC receives a command to send data. Otherwise it will send report data on each IN packet, filling the host's buffer with data you don't want.
-
Thanks Jan that's fixed it. Super fast now.
Best Regards
Dave
-
Good! Thanks for posting.
-
Hi Jan, after thinking everything was fine I have discovered it is not. Using this method everything is intermittent, sometimes works and sometimes picks up rubbish. I feel the only way is back to the very slow method with big delays. Any ideas?
Thanks again for your support
Dave
-
Hi Jan, update on Yesterday I do now have it working reliably. Not sure really what was wrong just moved the position of the flag that enables a read after a write from after the USBHandleGetLength to before and fixed the problem. I am using the polling method but is there still any interupt process going on during USB transfers?
Thanks again for your help
Dave
-
The host continues to poll the IN endpoint, and if there is no data to send, the endpoint returns NAK without any firmware intervention.