Expanding In/Out Reports on Keil USB HID example code

Good day Tsuneo and all

quite interesting to find this thread right on top ... :D

Here is the situation:
I already changed HID reports successfully on ARM7/2366. (to 60)
This was almost straight forward and works fine. So I am not new to all the stuff
(But of course still light year's away from other 'T' - user's expertise)

Now I wanted to do the same with the latest USB HID sample provided for MCB1700
(so this included a switch to CORTEX)

I did all the stuff above, and in principal, it works too, but only for the Report Sizes 1,2,3 and 4. (and yes, I enlarged EP0Buf to 64 (resp MAX_PACKET_SIZE0)

whenever I got to reports > 4, it stops working

is there somewhere a known maximum or bug ?

MANY MANY thanks in advance for any illumination
ULI

Good day Tsuneo and all

quite interesting to find this thread right on top ... :D

Here is the situation:
I already changed HID reports successfully on ARM7/2366. (to 60)
This was almost straight forward and works fine. So I am not new to all the stuff
(But of course still light year's away from other 'T' - user's expertise)

Now I wanted to do the same with the latest USB HID sample provided for MCB1700
(so this included a switch to CORTEX)

I did all the stuff above, and in principal, it works too, but only for the Report Sizes 1,2,3 and 4. (and yes, I enlarged EP0Buf to 64 (resp MAX_PACKET_SIZE0)

whenever I got to reports > 4, it stops working

is there somewhere a known maximum or bug ?

MANY MANY thanks in advance for any illumination
ULI

Hi ULI,

> I did all the stuff above, and in principal, it works too, but only for the Report Sizes 1,2,3 and 4. (and yes, I enlarged EP0Buf to 64 (resp MAX_PACKET_SIZE0)

Sound like the limit of 4 bytes comes from wMaxPacketSize of the interrupt IN endpoint, doesn't it?

C:\Keil\ARM\Boards\Keil\MCB1700\USBHID\usbdesc.c

const U8 USB_ConfigDescriptor[] = {
  ...
  ...
/* Endpoint, HID Interrupt In */
  USB_ENDPOINT_DESC_SIZE,            /* bLength */
  USB_ENDPOINT_DESCRIPTOR_TYPE,      /* bDescriptorType */
  USB_ENDPOINT_IN(1),                /* bEndpointAddress */
  USB_ENDPOINT_TYPE_INTERRUPT,       /* bmAttributes */
  WBVAL(0x0004),                     /* wMaxPacketSize */   <--------- 0x0040 ie. 64 bytes
  0x20,          /* 32ms */          /* bInterval */

Tsuneo

grrrrr............................
I was close to losing consciousness upon reading this..

THANK YOU TSUNEO ONCE MORE !!!!!!!!!!!!!
I had marked all the spots of modification then with the ARM 7 stuff,
oviously all except one ...

in general, what is your opinion regarding these samples in quality?
from my viewpoint, they could a lot better regarding modularization and
ease of use...
eg my current (solved) problem: it would have been a lot easier to have just
U8 InReport[REPORT_SIZE]
and only one single point for definition and modification

or, eg if looking at the string descriptors ...

how to handle a "reallife" serial number properly ?
this sample won't work if it is stored in an EEProm

what do you think of my idea to solve this ?
keep all strings in ordinary const char and, upon startup (before USBInit !!)
go through them and expand them to wide strings in the given string descriptor structure. Upon extraction, I can easily fill in my real serial number from elsewhere. does this sound OK ?

again: a big thanx

ULI

PS to Garrett: apologies for stumbling in

> in general, what is your opinion regarding these samples in quality?

Not so bad, but not so good.
I recommend the programmers of KEIL stack to read as many stack code from others.
Most of USB MCU manufacturers release their own USB stack.
Also, examine the interfaces of commercial USB stacks.
These materials will give many suggestion on the organization of the stack.

> keep all strings in ordinary const char and, upon startup (before USBInit !!)
go through them and expand them to wide strings in the given string descriptor structure. Upon extraction, I can easily fill in my real serial number from elsewhere. does this sound OK ?

It's OK.
One step advance, this string expansion process is directly integrated in Get_Descriptor( string ) handler, so that the string expansion goes on demand. And then, you can save RAM space for the expanded strings.

If this stack would have an extra hook for SETUP handler, we could modify the behavior of the stack without changing the stack code at all. This kind of hook is seen on other stacks, like Microchip, ST micro, EZUSB, etc.

Tsuneo

thank you once more!

Strings on demand sounds smart.

My problem is that a REAL understanding from bottom to top is still not existent, despite your posts and Axelson's books.
Nowadays, all the sales guys say: get this library, get this component, stick it together, add some glue code and then lets sell it. No spare time to go into detail, no way to become a real expert, especially if in the meantime (last time I was at USB in detail was March or so) so many other topics were hot and needed immediate attention.

regarding the KEIL code, I think its limitations show up once you want to transform it into "real code". from my point of view, it should be easy to separate the sources and have the option to treat them in a "library style" (eg separate folders, maybe even in compiled form)
this is not possible here as they have mixed up everything. (eg the core includes demo.h, and all resides in one folder) First thing for me to do after I got it to basically communicate will be "cleaning up and separating" (and hoping it will not be broken afterwards)

btw, for these tests I always use the HID Exerciser. (cool tool)

<<<Sometimes>>> (not sure about the circumstances and not regularly) upon arrival of one of my (Keil driven) devices, the detection (readout of strings) fails and the exerciser only lists VID+PID in hex. Any idea what this might be? This seems never to happen with other devices.

Another point I always have to add:

why not post your paypal account here ? ;)) Your comments are so helpful ...and probably take so much of your time...keeping you from "real" work. Or maybe write a book ;)

What I would find very interesting is a list of all your USB children ;)))
-> thinking of all the devices you were responsible for.
I bet, there are some Tsuneo driven parts in my house :D
-> probably not possible due to nda limitations ;((

Vielen Dank!
Uli