Is it a USB HID standard to return the number of bytes received when bytes are sent?

I have a hid-data example, from V-USB working fine, using a ATTiny85. When using the included command line testing tool, written is C, called hidtool, I can send and then receive the sent data from this command line test. But being a command line program it's pretty basic and does not really have any error checking. It just sends the data to the HID and then exits. A subsequent call with a "read" parameter displays what was written to the terminal.

However, I am using a Java library for communication with this HID http://code.google.com/p/javahidapi/. I have used this same method, successfully before on a project I created in Arduino using a Teensy 2.0 and it's version of a "RawHID" for data transfer.

Anyway I believe I have figured out my issue. When the java library's write() function sends data to the HID it expects to receive in return the number of bytes written. If it doesn't it throws and exception after a timeout. I can wrap it and when it times out go on my merry way, but the timeout is a bit long. I'm not sure if I should tweak the example code or the V-USB library to return a number of bytes written after receiving data from the host? I guess a second question is, is this a standard procedure or something that should be in the V-USB library already? I have posted this question over in their forum but figured I would ask here as well.

I am leaning toward the fact that the V-USB library has a setting to enable CRC checking (see below). In any event it requires the use of an external 18mhz crystal for the clock. My plan is to order some of those crystals next week and see how I make out. I'm assuming that the CRC check maybe providing the ACK back to the host driver that all is OK and it would prevent the exception from being thrown.

#define USB_CFG_CHECK_CRC 0
/* Define this to 1 if you want that the driver checks integrity of incoming
* data packets (CRC checks). CRC checks cost quite a bit of code size and are
* currently only available for 18 MHz crystal clock. You must choose
* USB_CFG_CLOCK_KHZ = 18000 if you enable this option.
*/

If you used Teensy, or any other microcontroller with proper USB support in hardware, you'd get CRC checking and other nice USB features that V-USB can't ever implement, all done in hardware.

Of course, the chips are more expensive if you ever want to mass produce a product. But then, if you're looking to mass produce, don't forget to factor in the cost of V-USB software licensing, where suddenly the low cost of that ATTINY chip isn't quite as cheap anymore.... especially if you think you might ever make more than 10000 pieces!

Some random pieces of the puzzle:

HID only gets one 64 byte packet per frame (1ms) in each direction. If your PC-side code sends less than 64 bytes then somewhere in the PC is code that pads the buffer up to 64 bytes.

On the embedded side all 64 are received. You have to know how many of those bytes were really sent, how many are padded. Using one of your 64 bytes for a length byte might be useful.

For data flowing from the embedded to the PC HID deals with "reports." You get to set the report size. If you set it to 128 bytes then the code knows it only gets 64 bytes per frame so it will schedule you two frames (back to back) and send the data (so it will take 2ms). You have to edit the report size in the embedded source. Official HID reports have a deterministic format that helps know the size of each part being reported.

USB already does error detection and correction with a CRC16 if I remember right.

Are you are using HID for generic data transport or for real HID stuff?

Paul,
I wish I could use the Teensy as I already have it working without this issue. My problem is the price point. I was hoping to make the whole thing for under $10. So far my design, testing and development seem to be headed in that direction. Not factoring in hand assembly, I'm calculating maybe $8-9 in parts (for 100 lots). If I ever get to SM stuff and factory builds of larger quantities I assume the price would be the same even with the assembly. The V-USB license for under 10,000 would be $.05 each if I did do 10,000. In my wildest dreams I can't imagine doing 10,000 but it is a mass market idea I have, so who knows, wish me luck! A lot of what I have said is speculation for sure. I have absolutely no experience in getting something like this made. So at this point I'm not ready to quit my day job!

The Teensy 2.0 that I prototyped on, has way more features than I need the end product to have. I just need the basics, a device that looks like USB HID to PC, Mac, Linux, that receives 64 byte data packets, runs some code, and controls two analog outputs. There is a fair amount of code so the ATTiny85 with 8K is so far my choice. I'm very open to an alternative USB hardware style solution if you have one in mind, I'm just trying to keep the price down where it can retail for under $40, wholesale for maybe $20, and be manufactured for $10.

BTW I did purchase 20 - Teensy 2.0 for a prior project that worked out great, and used one of those for prototyping this idea.

Dewey,
Thanks for the info. The V-USB example code that I am working from uses a Report Size of 128. Since I originally wrote the code for the Teensy I only need 64 anyway. At this point I am assuming that I need this CRC checking on the hardware firmware side. The V-USB guys indicate that that is only available if I use an 18mhz external crystal, because there are tons of timing issues in the assembler code they wrote and they only implemented it with this one configuration. That is way beyond my electronic and software level of knowledge (I never graduated to Assembler) so hopefully that will do it.