Recent Posts

1

USB / Re: babble, pipe errors, lufa project

« Last post by Jan Axelson on March 26, 2020, 09:02:01 pm »

Yay! Thanks for reporting back.

2

USB / Re: babble, pipe errors, lufa project

« Last post by ulao on March 26, 2020, 07:50:55 pm »

Stroke of luck, had a type in my report size array. thx for the help, learned what I needed.

3

USB / Re: babble, pipe errors, lufa project

« Last post by ulao on March 26, 2020, 07:41:05 pm »

You are truly better then google.

All of my question are clear no, thx for that. Still not getting anywhere. but I think I know the issue just not sharp enough to fix it. Could be a lufa question from here out not sure. So it seems as though I'm possibly not handling reports right.

Code: [Select]

void EVENT_USB_Device_ControlRequest(void)
{
uint8_t  ReportID   = (USB_ControlRequest.wValue & 0xFF);
/* Handle HID Class specific requests */
switch (USB_ControlRequest.bRequest)
{
case HID_REQ_GetReport:
if ( ReportID == 1 && USB_ControlRequest.bmRequestType == (REQDIR_DEVICETOHOST | REQTYPE_CLASS | REQREC_INTERFACE))
{
Endpoint_ClearSETUP();

/* Write the report data to the control endpoin
*/
Endpoint_Write_Control_Stream_LE(reportBuffer, sizeof(reportBuffer));
Endpoint_ClearIN();

}
break;

case HID_REQ_SetReport:

if (  USB_ControlRequest.bmRequestType == (REQDIR_HOSTTODEVICE | REQTYPE_CLASS | REQREC_INTERFACE))
{
Endpoint_ClearSETUP();
// With our report available, we read data from the control stream.
Endpoint_Read_Control_Stream_LE(&reportBuffer, sizeof(reportBuffer));
// We then send an IN packet on this endpoint.
Endpoint_ClearOUT();
}

}
}

I added that report ID stuff still with no luck, just a lot of babble errors.  Any last suggestions?

4

USB / Re: babble, pipe errors, lufa project

« Last post by Jan Axelson on March 26, 2020, 05:13:49 pm »

A HID interface can have at most one IN and one OUT interrupt endpoint.

The endpoints can have any number > 0 and don't have to use the same number.

5

USB / Re: babble, pipe errors, lufa project

« Last post by ulao on March 26, 2020, 02:27:06 pm »

all to well familiar with windows and its caching habits.

Thx for helping, I'm not too surprised v-usb was sub standard.

I did a bit of work since and still facing this babble error. Incidentally setting to 16d gave me the same error.
 
yeah I use a report ID of 1 for my gamepad payload. the FFB has lots of reports ids.

Another thing that is sort of confusing is the endpoints. I though there was a default.  Then you could add more.

default
end in 81h 01
end out 01h 01

meaning 3, or will the reports typical show all end point listed and there is no such thing as a default.

I see some do this

default
end in 81h 01
end out 01h 02  <-- not sure why 2? Would you not need a 01 before making a 2?



My current descriptor is like so.

Configuration Descriptor 1 Bus Powered, 200 mA
Offset Field Size Value Description
0 bLength 1 09h 
1 bDescriptorType 1 02h Configuration
2 wTotalLength 2 0029h 
4 bNumInterfaces 1 01h 
5 bConfigurationValue 1 01h 
6 iConfiguration 1 00h 
7 bmAttributes 1 80h Bus Powered
 4..0: Reserved  ...00000   
 5: Remote Wakeup  ..0.....  No
 6: Self Powered  .0......  No, Bus Powered
 7: Reserved (set to one)
(bus-powered for 1.0)  1.......   
8 bMaxPower 1 64h 200 mA

Interface Descriptor 0/0 HID, 2 Endpoints
Offset Field Size Value Description
0 bLength 1 09h 
1 bDescriptorType 1 04h Interface
2 bInterfaceNumber 1 00h 
3 bAlternateSetting 1 00h 
4 bNumEndpoints 1 02h 
5 bInterfaceClass 1 03h HID
6 bInterfaceSubClass 1 00h 
7 bInterfaceProtocol 1 00h 
8 iInterface 1 00h 

HID Descriptor
Offset Field Size Value Description
0 bLength 1 09h 
1 bDescriptorType 1 21h HID
2 bcdHID 2 0111h 1.11
4 bCountryCode 1 00h 
5 bNumDescriptors 1 01h 
6 bDescriptorType 1 22h Report
7 wDescriptorLength 2 04ECh 1260 bytes

Endpoint Descriptor 01 1 Out, Interrupt, 10 ms
Offset Field Size Value Description
0 bLength 1 07h 
1 bDescriptorType 1 05h Endpoint
2 bEndpointAddress 1 01h 1 Out
3 bmAttributes 1 03h Interrupt
 1..0: Transfer Type  ......11  Interrupt
 7..2: Reserved  000000..   
4 wMaxPacketSize 2 0008h 8 bytes
6 bInterval 1 0Ah 10 ms

Endpoint Descriptor 81 1 In, Interrupt, 1 ms
Offset Field Size Value Description
0 bLength 1 07h 
1 bDescriptorType 1 05h Endpoint
2 bEndpointAddress 1 81h 1 In
3 bmAttributes 1 03h Interrupt
 1..0: Transfer Type  ......11  Interrupt
 7..2: Reserved  000000..   
4 wMaxPacketSize 2 0010h 16 bytes
6 bInterval 1 01h 1 ms

6

USB / Re: babble, pipe errors, lufa project

« Last post by Jan Axelson on March 26, 2020, 02:04:49 pm »

Yes, every HID must have a HID descriptor.

The right side specifies the report descriptor correctly.

If the HID uses a report ID other than zero, all reports sent to or from interrupt endpoints are preceded by the report ID.

Increase the endpoint size to 16d and try it.

With Windows, attach the device and remove it via Device Manager before changing the firmware and reattaching.

7

USB / babble, pipe errors, lufa project

« Last post by ulao on March 26, 2020, 12:54:17 pm »

Jan, I hope all is well. The lufa forums are down and was hoping you had a few cents to offer here.

I'm converting a joystick project from v-usb to lufa. Few things do not make scene to me.

Things that do not make sense to me.
1) in my screen shot [left item ](v-usb) has no hid descriptor, should it have? - Not my issue but I never had to have one.
2) the report and report size bytes are in the HID descriptor not the interface descriptor with LUFA (right side of image)?

my issues
If I set my report size to 14 (like it should be) I get babble errors in usb. I read that means too much data sent. If I try to send only 8 I get pipe errors. Maybe I will if my data size does not match the descriptor.



This is my lufa descriptor.

Code: [Select]

const USB_Descriptor_Device_t PROGMEM DeviceDescriptor =
{
.Header                 = {.Size = sizeof(USB_Descriptor_Device_t), .Type = DTYPE_Device},

.USBSpecification       = VERSION_BCD(02.00),
.Class                  = USB_CSCP_NoDeviceClass,
.SubClass               = USB_CSCP_NoDeviceSubclass,
.Protocol               = USB_CSCP_NoDeviceProtocol,

.Endpoint0Size          = FIXED_CONTROL_ENDPOINT_SIZE,

.VendorID               = 0x16D0,
.ProductID              = 0x0D0C,
.ReleaseNumber          = VERSION_BCD(01.10),

.ManufacturerStrIndex   = 0x01,
.ProductStrIndex        = 0x02,
.SerialNumStrIndex      = NO_DESCRIPTOR,

.NumberOfConfigurations = FIXED_NUM_CONFIGURATIONS
};

/** Configuration descriptor structure. This descriptor, located in FLASH memory, describes the usage
 *  of the device in one of its supported configurations, including information about any device interfaces
 *  and endpoints. The descriptor is read out by the USB host during the enumeration process when selecting
 *  a configuration so that the host may correctly communicate with the USB device.
 */
const USB_Descriptor_Configuration_t PROGMEM ConfigurationDescriptor =
{
.Config =
{
.Header                 = {.Size = sizeof(USB_Descriptor_Configuration_Header_t), .Type = DTYPE_Configuration},

.TotalConfigurationSize = sizeof(USB_Descriptor_Configuration_t),
.TotalInterfaces        = 1,

.ConfigurationNumber    = 1,
.ConfigurationStrIndex  = NO_DESCRIPTOR,

.ConfigAttributes       = USB_CONFIG_ATTR_RESERVED,

.MaxPowerConsumption    = USB_CONFIG_POWER_MA(200)
},

.HID_Interface =
{
.Header                 = {.Size = sizeof(USB_Descriptor_Interface_t), .Type = DTYPE_Interface},

.InterfaceNumber        = 0x00,
.AlternateSetting       = 0x00,

.TotalEndpoints         = 2,

.Class                  = HID_CSCP_HIDClass,
.SubClass               = HID_CSCP_NonBootSubclass,
.Protocol               = HID_CSCP_NonBootProtocol,

.InterfaceStrIndex      = NO_DESCRIPTOR
},

.HID_JoystickHID =
{
.Header                 = {.Size = sizeof(USB_HID_Descriptor_HID_t), .Type = HID_DTYPE_HID},

.HIDSpec                = VERSION_BCD(01.11),
.CountryCode            = 0x00,
.TotalReportDescriptors = 1,
.HIDReportType          = HID_DTYPE_Report,
.HIDReportLength        = sizeof(JoystickReport)
},

.HID_ReportINEndpoint =
{
.Header                 = {.Size = sizeof(USB_Descriptor_Endpoint_t), .Type = DTYPE_Endpoint},

.EndpointAddress        = JOYSTICK_EPADDR,
.Attributes             = (EP_TYPE_INTERRUPT | ENDPOINT_ATTR_NO_SYNC | ENDPOINT_USAGE_DATA),
.EndpointSize           = JOYSTICK_EPSIZE,
.PollingIntervalMS      = 1
},

.HID_ReportOUTEndpoint =
{
.Header                 = {.Size = sizeof(USB_Descriptor_Endpoint_t), .Type = DTYPE_Endpoint},

.EndpointAddress        = JOYSTICK_EPADDR_OUT,
.Attributes             = (EP_TYPE_INTERRUPT | ENDPOINT_ATTR_NO_SYNC | ENDPOINT_USAGE_DATA),
.EndpointSize           = 8,
.PollingIntervalMS      = 0x0A
}
};

here is the h file for the other tidbits

Code: [Select]

typedef struct
{
USB_Descriptor_Configuration_Header_t Config;

// Joystick HID Interface
USB_Descriptor_Interface_t            HID_Interface;
USB_HID_Descriptor_HID_t              HID_JoystickHID;
USB_Descriptor_Endpoint_t             HID_ReportOUTEndpoint;
        USB_Descriptor_Endpoint_t             HID_ReportINEndpoint;
} USB_Descriptor_Configuration_t;

/* Macros: */
/** Endpoint address of the Joystick HID reporting IN/OUT endpoint. */
#define JOYSTICK_EPADDR           (ENDPOINT_DIR_IN | 1)
#define JOYSTICK_EPADDR_OUT   (ENDPOINT_DIR_OUT | 2)

/** Size in bytes of the Joystick HID reporting IN endpoint. */
#define JOYSTICK_EPSIZE           14 //(should be 14) but that gives babble errors.

/** Descriptor header type value, to indicate a HID class HID descriptor. */
#define DTYPE_HID                 0x21

/** Descriptor header type value, to indicate a HID class HID report descriptor. */
#define DTYPE_Report              0x22


My report is 5 pages long because of the Force Feed Back stuff, is it will not even post in this forum. The 14 comes from this
//0 - report id = 1
//1 - buttons 1
//2 - buttons 2
//3 - buttons 3
//4 - X_MAIN_STICK
//5 - Y_MAIN_STICK
//6 - Z_AXIS_1
//7 - X_SECONDARY_STICK
//8 - Y_SECONDARY_STICK
//9 - Z_AXIS_2
//10- SLIDER
//11- DIAL
//12- HAT
//13- FFB

8

USB / Re: Control transfer through Windows HID driver?

« Last post by Jan Axelson on March 26, 2020, 10:29:27 am »

Interesting! I agree with the complaints!

9

USB / Re: Control transfer through Windows HID driver?

« Last post by Renate on March 26, 2020, 08:43:08 am »

Well, all the HidP_ stuff works with "preparsed" report descriptors.

Dealing with all this stuff on Windows leads to insanity.
You can go from the top down instead (just an overview, not actual code):

Code: [Select]

SetupDiGetClassDevs(&GUID_DEVINTERFACE_USB_HOST_CONTROLLER
DeviceIoControl(IOCTL_USB_GET_ROOT_HUB_NAME
CreateFile
DeviceIoControl(IOCTL_USB_GET_NODE_CONNECTION_INFORMATION
DeviceIoControl(IOCTL_USB_GET_DESCRIPTOR_FROM_NODE_CONNECTIONBut even here MS did something annoying that wasn't necessary.
IOCTL_USB_GET_DESCRIPTOR_FROM_NODE_CONNECTION hard-wires the type & request of the setup packet to 0x80 (device in), 0x06.
If they had been looser and allowed 0x81 (interface in), 0x06, 0x2200 we could have gotten report descriptors.
As a matter of fact, on some sloppy devices, I ask for 0x81, 0x06, 0x2200, MS relays that as 0x80 and the device (incorrectly) responds with the report descriptor.
Sheesh.

Not only that, you can't easily correlate a NODE_CONNECTION with a DEVINST.

10

USB / Re: Control transfer through Windows HID driver?

« Last post by Jan Axelson on March 21, 2020, 09:06:23 pm »

IOCTL_HID_GET_REPORT_DESCRIPTOR - don't know why it wasn't implemented but other APIs, HidP_GetCaps etc., can return report descriptor information.

A HID control transfer can be vendor defined as long as it has a report descriptor that at minimum defines the report length.