USB ROM API: generic HID example bug?

[lpcware]

Content originally posted in LPCWare by mch0 on Mon Sep 01 01:11:27 MST 2014
Hi,

I'm working on a HID interface using the ROM API (LPC4370).
I am using the LPCOpen generic HID example as a starting point and the code is working so far.
However, since I'll have to add more functionality I must also understand at least some implications of the ROM API. For example, where and when to allocate memory for what purpose.

During that process I found out that during the various init()-calls the parameter blocks are also used to keep track of the "top of memory" and the remaining size for usage by the ROM stack.

I would have liked to read about that in some documentation but I did not find it mentioned yet in the docs I have read or got so far.

However, my current problem now is one of understanding the example code, actually I think it's buggy.
The bug does NOT trigger and will not in the example, but I'd really like to see if my understanding of the memory allocation strategy is correct or not.

Details:

The code snippet is from the LPCOpen 2.12 example usb_rom_hid_generic, file hid_generic.c, function
usb_hid_init(...):

        ret = USBD_API->hid->init(hUsb, &hid_param);
/* allocate USB accessable memory space for report data */
loopback_report =  (uint8_t *) hid_param.mem_base;
hid_param.mem_base += 4;
hid_param.mem_size += 4;
/* update memory variables */
*mem_base = hid_param.mem_base;
*mem_size = hid_param.mem_size;
return ret;

As I understand it the first line (API init call) takes the current memory base and available size as given in the hid_param-structure and updates both the base and the size entries. So after the call we know how many bytes are still available and where that area starts.

Now this example uses a 1 byte report and somewhere the buffer for it must be allocated.

For that the example also uses the ROM API stack area and updates the structure entries manually.

If so, I do understand the first calculation (hid_param.mem_base += 4;) to some extent, since maybe the programmer wanted to keep a word alignment. In my opinipn +1 would have been sufficient.
But I do not understand the second calculation hid_param.mem_size += 4; since that shows an increases the remaining space! Shouldn't it decrease by the allocated amount, i.e. 4?
Also the function reports the new memory data back to the caller, so that the size information is also corrupted in the more general usb_param-structure.

As said, with the example it does not matter, but for understanding what happens it's important for me.
After all I'll use much longer reports and maybe more of them.

Best regards,

Mike