Added Long USB RecvControl call for >64 bytes

[NicoHood]

This PR replaces the 2nd commit of #4105

It makes more sense to integrate this (wrapper) function into the core instead of my project, since I use it 3 times and other people might need it too.

It doesnt break anything, just a new function was added

cc @facchinm

[facchinm]

Ok, this doesn't add any overhead if not used, so I'm for merging. Thanks!

[cmaglie]

Is this API available for SAM/SAMD/others?
Is not better if we patch USB_SendControl? how much is the overhead?

[facchinm]

The overhead is BIG if we leave only the long implementation. SAM and SAMD should already handle the long case (if my memory isn't failing).

[cmaglie]

SAM and SAMD should already handle the long case (if my memory isn't failing).

My point is that if a library use USB_SendControlLong, it will fail to compile on SAM/SAMD.

The overhead is BIG if leaving only the long implementation

USB_SendControl uses int for len parameter, so we should just use int that is 16-bit math on AVR.

[facchinm]

Sorry, I meant that using the USB_RecvControlLong to handle a 3 bytes transfer has a big overhead.
But you are right, we should also add a "stub" SAM/SAMD implementation

[NicoHood]

You are totally right. However the whole USB Core needs an improvement, so this shouldnt matter for now (my opinion). If you really want to fix this, add a proper USB Core like LUFA with also sam compatible functions.

This PR was "just" an addition I needed for the HID Project (Raw HID especially). Its only avr compatible anyways, so for me its fine. I guess this might be the only project using the usb-core anyways. So thanks for merging! :)

[cmaglie]

Adding an API means that people starts to rely on it, we should document it and maintain (for other cores as well).

I guess this might be the only project using the usb-core anyways.

This don't justify adding a project-specific-API to the core, if you're the only one using it why you feel the need to add it to the core then?

So at this point I'm all for removing USB_RecvControlLong and fix USB_RecvControl, that is the Right Thing To Do™, since the current USB_RecvControl is buggy.

I'll try to crack a fix for this in a moment.