PUSBCallbacks - is it necessary to require static functions? (PluggableUSB in 1.6.6)

[Teiwaz83]

The PUSBCallbacks struct (in PluggableUSB.h) is defined like so:

typedef struct __attribute__((packed))
{
  bool (*setup)(USBSetup& setup, u8 i);
  int (*getInterface)(u8* interfaceNum);
  int (*getDescriptor)(int8_t t);
  int8_t numEndpoints;
  int8_t numInterfaces;
  uint8_t *endpointType;
} PUSBCallbacks;

This requires the methods setup, getInterface, and getDescriptor to all be static. I haven't dug very far past this (the whole point of PluggableUSB is to keep me as far form the inner horrors of USB as possible!) - but is this necessary? Requiring these methods to be static really complicates setting up classes which can manage their own interfaces and endpoints. If you want each instance of a class to have its own interface/endpoint to make Windows see it as a separate device, you need to be using unique information when building the interface descriptor, which generally you want to be doing in getInterface. GetInterface having to be static prevents you from easily correlating a created interface with a specific instance of your class.

[matthijskooijman]

IIUC you're saying that these callbacks should be method pointers instead of function pointers? The downside of that is that you will need to create a full object whenever you want to plug an USB backend, even if you would just have one instance anyway.

An alternative could be to let these callback functions accept a void *userdata parameter, that you then store as a new member inside the PUSBCallbacks. The function called can then cast the userdata pointer to the right object type and call the method you need. This is a common way to solve this problem (and the userdata can also be used for other things, like an integer if that's all you need to distinguish instances, or a pointer to a struct with some parameters).

Instead of passing the userdata, you could also pass a pointer to the PUSBCallbacks struct, which might be useful in some cases.

Adding such a userdata parameter to the callbacks will break the API, but I guess the pluggable USB API is new enough to still allow some changes.

@facchinm, @NicoHood, IIRC you were working on this pluggable USB stuff, right? Care to have a look?

[Teiwaz83]

I was thinking that they should just be method pointers instead of function pointers as you said first, since it's fairly trivial to redirect to a function if it calls a method, but your userdata pointer parameter seems like a better option and would be potentially useful for other things (like passing interface, endpoint, and report IDs directly).

[NicoHood]

I tried this here, but I cant get it working
NicoHood/HID@a96577c

Maybe the c++ syntax is wrong or it is just not possible with the current structure.

I've opened a similar issue. I suggest to redo the pluggable usb api a bit to create normal USBDevices which can be inherited. This produces less code duplication and its easier to duplicate a device, such as HID devices for multiple gamepads.
#3840 (comment)

I was already working on an update suggestion but a compile bug made life very hard:
arduino/arduino-builder#19

I really wish to simplify this some more since we have enough time to. It seems the compiler needs more testing till a new release.

[facchinm]

Functions are not static anymore with the latest version of the PluggableUSB APIs.
The wiki has been updated accordingly 😉