stm32_fsdev & ISO EP buffer allocation improvements

[HiFiPhile]

Describe the PR
For stm32_fsdev:

• Minor fixes
• Rework FIFO based transfer
• Add an endpoint allocator to overcome ISO ep limitation

For ISO transfer:

• Add dcd_edpt_iso_alloc() / dcd_edpt_iso_activate() for ISO EP buffer allocation
• Handle new allocation method in UAC2.

Additional context
If applicable, add any other context about the PR and/or screenshots here.

[HiFiPhile]

I think it's better to add a flag somewhere to choose new buffer allocation method or continue use old one.
For example in tusb_mcu.h add TUP_DCD_ISO_ALLOCATION, or add it inside audio_device.c like how USE_LINEAR_BUFFER is handled. Some MCU don't have allocation problem so there is no need to touch them.

[HiFiPhile]

@kkitayam Hi, I'm working on ISO EP buffer allocation based on #540, since video class is also ISO, does it benefit from this ?
Is this new dcd_edpt_iso_alloc() / dcd_edpt_iso_activate() suitable for video ?

[kkitayam]

@HiFiPhile

Hi, thanks for your comments.

Maybe yes, the APIs would be suitable for UVC too.
My understanding is that UVC controls ISO EPs in basically the same manner as UAC.

By the way, UVC can also use bulk EPs instead of ISO EPs for non-linear editing. Current UVC implementation has not supported this.
If we try to add support bulk EPs for UVC, we might be need some APIs like as dcd_edpt_iso_alloc() / dcd_edpt_iso_activate() for bulk EPs. It's just a guess. I am not familiar for bulk video data.

[PanRe]

Yes i think this is a good idea! For us it might be a bit more work but the user does not need to be aware of this new allocation feature and we thus will get less issues reported ;)

Great work btw!

[hathach]

Thank you @HiFiPhile , am on travel, will check this out next week.

[HiFiPhile]

@skuep

For the moment I kept your SOF callback but for the stack it's not quite the right place to do it.

Did you test the tud_audio_feedback_interval_isr and found out it has too much jitter ?

If a prioritized SOF callback is needed we need do it in a generalized way for other DCD drivers.

[skuep]

Yeah I am also still on the fence with this callback.
From the looks of it, the generated feedback values in the speaker feedback endpoint had way less jitter for the UAC2 application. However I did not check if this actually makes a difference for the (stability of the) feedback control loop running on the Host. Since I can only test Linux hosts, I left it in there for a better gut feel in terms of compatibility.

I do however think it would be a nice addition, if this would be a more general solution across all DCD drivers. The way I use it is that the callback "emulates" a timer capture on SOF (since the STM32 I used cannot do this in hardware). I fear however, that a more generalized solution would come with more overhead, since It would require a "callback sharing" mechanism, in case multiple USB classes use this callback. Which of course diminishes the purpose of this callback.
EDIT: Maybe it would make sense to integrate a SOF-timestamp function into the device drivers, that the tinyusb stack can then query? Of course it would need to be configurable what Timer to use, etc... Which again depends on the actually device used and it's device driver.

If I get around to it, I can test if it would work without this callback. I think it would be okay for now to remove the callback. If I desperately need it, we can discuss the issue further.

[skuep]

Sorry for the delay in testing your branch. However I have found a serious bug in the code that you based your commits on.
I updated the original branch that you used. See the very last commit here:
master...skuep:tinyusb:0.14.0-sk

I first noticed sporadic corrupted memory on only some of my devices, which was really hard to debug. I narrowed it down to the TU_ASSERT that I added to the code in this commit. It turns out, that you need to set the receive buffer-size with ISOCHRONOUS endpoints for both double buffer count registers in the buffer descriptor table. I only set it for the USB_COUNTn_RX register, because the fields are not even there in the manual for the corresponding USB_COUNTn_TX register. Turns out, they are there after all and need to be set. Else wildly varying (unitialized?) number of received bytes where reported for every other packet, leading the dcd_read_packet_memorycall to write more buffer than it was allowed to.

[HiFiPhile]

@skuep Thanks for your update ! Indeed I have only tested IN EP.

[skuep]

Alrighty!
I have switched my tinyusb submodule reference to your branch. I adjusted the SOF timing measurement code (due to removal of the tu_stm32_sof_cb callback. What can I say, it works very well so far!
The PMA and hardware endpoint allocation works quite nice, verified everything looks good in the xfer_statusmap.

From my side of view, testing was successful! Thanks a lot

[HiFiPhile]

@skuep
That's a great news !

PS: One thing very useful is J-Scope, I used it to visualize FIFO level while adjusting feedback loop.

[skuep]

Tested successfully with the AIOC project
https://github.com/skuep/AIOC

[hathach]

Superb!! Sorry for huge delay, I am in the middle for reviewing this PR. Everything looks great, I am doing mostly clean up to make it more readable. Number of #ifdef in audio driver is starting to look scary now. We should do some refactoring in the future. Overall this PR is awesome and ready to merge, however there is a note in the review, that I think we should change to prevent a read out-of-bound of an array.

[hathach]

everything looks good. Thank you very much for putting your effort to this brilliant PR.

[skuep]

Awesome! Thanks 👍🙂