enhancement to yield during USB_GetSetupPacket

[fabriceo]

Hello, this is an enhancement request to avoid endpoint0 blocking a whole core when calling USB_GetSetupPacket() function declared in file XUD_EpFunctions.c. Idea is to insert a call to a weak function just before the blocking "testct" instruction seen inside XUD_GetSetupBuffer.

Suggestion is to add a weak and empty function called for example XUD_UserYieldChanend(unsigned chan) in file XUD_user.c, and to call this function before "testct" instruction. Example of code:

XUD_Result_t XUD_GetSetupBuffer(XUD_ep e, unsigned char buffer[], unsigned *datalength)
{
    . . .
    XUD_UserYieldChanend(ep->client_chanend);

    /* Wait for XUD response */
    asm volatile("testct %0, res[%1]" : "=r"(isReset) : "r"(ep->client_chanend));

    if(isReset)
    {
        return XUD_RES_RST;
    }
   . . .
}

Doing so , the user will be able to publish a XUD_UserYieldChanend(...) function in its application to capture spare time and potentially manage non critical activities by using CPU allocated to Endpoint0 core, like user interface with led or button or even lcd-i2c.

An alternative would be to slightly rewrite XUA_Endpoint0() in lib_XUA to avoid a blocking behavior, but making the change in lib_XUD open the door to other device class application and not only audio application based on XUA.

example of code for XUD_user.c

void  XUD_UserYieldChanend( unsigned ch ) __attribute__ ((weak));
void  XUD_UserYieldChanend( unsigned ch ) {
    return;
}

Many thanks for your attention fabriceo

[xross]

Unfortunately this would break the USB spec - a device cannot NAK a SETUP. The device therefore must always be ready to accept control data - this proposal would make that possible to make that not the case.

The real solution is to add local setup buffering to lib_xud. I think this works fits along side work for #74