Page 1 of 1

Cant manage to receive Report > 8 byte

Posted: Thu May 31, 2007 12:53 am
by rowaweb
Hi,

im using ur code for usb implementation and i got a report descriptor like this:

Code: Select all

(...)
    0x09, 0x00,                    //   USAGE (Undefined)
    0xb1, 0x02,                    //   FEATURE (Data,Var,Abs)
    0x85, 0x04,                    //   REPORT_ID (4)
    0x95, 0x40,                    //   REPORT_COUNT (64)
    0x09, 0x00,                    //   USAGE (Undefined)
    0xb1, 0x02,                    //   FEATURE (Data,Var,Abs)


This means, i get 1 byte report-id and another 63 for data usage.

Code: Select all


static uchar   textBuffPtr=0;
static uchar   textBuffer[63]= { ... }

uchar   usbFunctionSetup(uchar data[8])
...
       } else if (rq->bRequest == USBRQ_HID_SET_REPORT) {
         if (rq->wValue.bytes[0] == 4) {
            // set 63 byte custom
                        state = STATE_WRITE_KEYBUFFER;   // prepared to receive data
         textBuffPtr = 0;
                        usbWriteLen = rq->wLength.word; // length of Report
                        return 0xff;
}
...


My write function looks like this:

Code: Select all

uchar usbFunctionWrite(uchar *data, uchar len)
{

  uchar i;
 
  if (state == STATE_WRITE_KEYBUFFER) {
   if (usbWriteLen == 1+63)     // first chunk to receive
   {
      data++;
      len--;
   }
   
   // to be safe (###)
   if (len > usbWriteLen) len = usbWriteLen;
   
   for(i=0; i<len; i++) {
      textBuffPtr++;
      textBuffer[textBuffPtr] = data[i];
      usbWriteLen--;
   }
   
   
   // return 0 if more data expected
   if (usbWriteLen) return 0;

   state = STATE_IDLE;
   textBuffPtr = 0;
   
   return 1;   
  }


Any suggestions? Im using a windows tool set SET_REPORT and it works out, but it only sets the first 7 byte of data and i cant see why.

Thanks in advance...

Posted: Thu May 31, 2007 9:55 am
by Grendel
Well..

Device Class Definition for Human Interface Devices (HID) V1.11 wrote:5.6 Reports

Using USB terminology, a device may send or receive a transaction every USB frame (1 millisecond). A transaction may be made up of multiple packets (token, data, handshake) but is limited in size to 8 bytes for low-speed devices and 64 bytes for high-speed devices. A transfer is one or more transactions creating a set of data that is meaningful to the device—for example, Input, Output, and Feature reports. In this document, a transfer is synonymous with a report.

Most devices generate reports, or transfers, by returning a structure in which each data field is sequentially represented. However, some devices may have multiple report structures on a single endpoint, each representing only a few data fields. For example, a keyboard with an integrated pointing device could independently report “key press” data and “pointing” data over the same endpoint. Report ID items are used to indicate which data fields are represented in each report structure. A Report ID item tag assigns a 1-byte identification prefix to each report transfer. If no Report ID item tags are present in the Report descriptor, it can be assumed that only one Input, Output, and Feature report structure exists and together they represent all of the device’s data.

If a device has multiple report structures, all data transfers start with a 1-byte identifier prefix that indicates which report structure applies to the transfer. This allows the class driver to distinguish incoming pointer data from keyboard data by examining the transfer prefix.


AVR-USB implements a low speed device.

Posted: Thu May 31, 2007 7:24 pm
by christian
Maybe I should append:

usbFunctionWrite() is called multiple times with chunks of up to 8 bytes until all 64 bytes are transferred.

Posted: Thu May 31, 2007 7:45 pm
by Guest
christian wrote:Maybe I should append:

usbFunctionWrite() is called multiple times with chunks of up to 8 bytes until all 64 bytes are transferred.


That does depend on the return value, right? I return 0 if i want to receive more bytes.... my usbFunctionWrite() should exactly behave like this, but obviously it doenst :(

I got no UART tool and no debug-tools on chip, so its hard to know whats going on there... Does the code itself look good?

Thanks

Posted: Thu May 31, 2007 10:47 pm
by christian
I can't see an obvious bug at the first glance. But when you can't find the bug where you are searching, you are probably searching in the wrong place.

Can you arrange for SOME kind of debugging output? If not by UART, then maybe at least a port pin which you can toggle when usbFunctionWrite is called and or something like that.

Posted: Fri Jun 01, 2007 5:03 pm
by rowaweb
christian wrote:Can you arrange for SOME kind of debugging output? If not by UART, then maybe at least a port pin which you can toggle when usbFunctionWrite is called and or something like that.


My thanks to a LED i could connect. usbFunctionWrite() is entered excactly 8 times (64 bytes report length). i had a pointer error :roll:

thanks for your support. Works out perfect.