1
\$\begingroup\$

I have been able to implement Zac Rogers USB MIDI adaptation of the Cube MX USB device middleware: https://github.com/zacrogers/blue_usb_midi

I can send USB midi messages on both F103 and F411. It seems to me that the transferring functions are non-blocking as they run in 14 clock ticks. But the problem is that when I send bursts of USB data, the transfer are corruped and the host receives only a few. To avoid this, I need to wait 100us (7200 ticks on f103 and 9600 ticks on f411).

I'd rather have a non blocking implemented in a callback function. But I have to admit that the codebase is too complex for me and I can't figure it out. I checked USBD_Get_USB_Status and waited until USBD_BUSY is going down, but it seems to do nothing else then returning the HAL status.

If anybody would have any pointers, that would be amazing.

So to sum up, after running midi_note_send from this file: https://github.com/zacrogers/blue_usb_midi/blob/main/Core/Src/usbd_midi_if.c

How can I get notified that the USB transfer is complete and that the peripheral is ready for a new transfer.

Thanks!

\$\endgroup\$

1 Answer 1

1
\$\begingroup\$

So, I haven't been able to get the libraries to let me know that the USB transmit was done, but I noticed that somewhere around 150us between each message is enough to let the host receive all the messages. A few tests sending and receiving 1000 MIDI messages confirm that it is functional and the average time between messages was effectively 150us.

It's probably safer to increase to 200us.

In my final application, both UART DIN MIDI and USB midi will be sending the same messages in sync, so UART MIDI will define the max data rate anyway.

The UART tx complete callback will be perfect for this.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.