-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Midihost #1219
Midihost #1219
Conversation
I converted this pull request to draft because the bulk IN endpoint for the RP2040 is not working yet. |
@rppicomidi thank you very much for your PR, sorry for late response. I am bit busy and lagging behind PRs. I will try to test and help with bulk IN later as soon as I could. |
@hathach I am making progress again and have the IN endpoint working with the OUT endpoint disabled. I am about to push a change. Once that is done I will see if both can work together. |
great thanks, I am also looking at bullk-iso endpoint host as well |
I pushed changes that show the Raspberry Pi Pico as MIDI host supporting both IN and OUT endpoints at the same time. It's showing proof of life, but after a short while the system gets in a state where it will neither send nor receive until I unplug and re-plug the MIDI device. I am investigating. |
Commit 5e4364f fixed what appears to me to be a timing issue in the rp2040. I believe now that bulk endpoints are working. I have some cleanup and testing to do and will then take this pull request out of draft. Not sure when that will be. |
This code is not perfect but it is far enough along that I believe it is ready for review. It handles concurrent MIDI send and receive. Whether the API I came up with is good for any host other than the RP2040 should be considered. I have tested it with the following MIDI devices:
|
@rppicomidi many thanks, I have revised hcd for rp2040 recently and also have some ideas on how to implement the bulk endpoints. Basically it is similar to your changes, we add an struct for each bulk ep and process them one by one after the previous one is complete. I will check this out asap I could. sorry for late response, I am still catching up with PRs |
@hathach No need to say you are sorry. Thank you for running this project. I understand you are busy. |
Hi, I'm very interested in testing this out. Can you share how you have your Pico / RP2040 board hooked up? How are you seeing the |
@todbot For my development setup, I am using a picoprobe for code load and for serial port printouts. See Getting started with the Raspberry Pi Pico, Appendix A. The one difference from the Figure 36 in Appendix A is instead of hooking VSYS from the picoprobe to the target Pico board VSYS, I hooked the VBUS pin of the picoprobe Pico board to the VBUS pin of the target Pico board. That is:
I connect the picoprobe to my test PC via a powered hub to make sure I don't screw up and damage my PC. I hook a microUSB male to original USB A female adapter to the target Pico board microUSB connector. There is no current limit on the USB host, so be careful. If you check my github repository in a day or two I will have an example pushed that shows the USB host converted to old school 5-pin DIN MIDI. Testing it now. |
I've done some initial testing on this PR, using @rppicomidi's repo's The Pico MIDI host is running the USB MIDI devices tested were:
All three types of common MIDI messages seem to be received correctly: 1-byte (MIDI clock), 2-byte (channel pressure), and 3-byte (note on/off). All devices work, except the M-Audio Keystation, which causes a The only obvious difference in the USB Descriptors between the Keystation and the rest are that all other devices in their Device Descriptor have I'd be happy to investigate this panic more if there's obvious things I can try or data I can collect. |
@hathach I pushed some bug fixes. Somehow I broke a lot of the builds for processors I do not have access to. Any idea how I can fix it? Do I need to merge with the latest tinyusb? @todbot I pushed an example project that uses the midihost code called midi2usbhost sends MIDI from the USB host to the Pico's UART1 TX pin and takes UART1 RX pin MIDI data and sends it back to the USB host. There are detailed instructions and pictures. |
@rppicomidi no problem, I will pull and fix that later on. Sorry late response again, I am still busy with other works, and catching up with your PR. Will try to wrap this bulk/midi host support as soon as I could. Please be patient. |
@hathach Thank you for the update. It looks like #1285 is also looking at bulk endpoints for the RP2040. @todbot When does the M-Audio Keystation panic? Has it successfully enumerated and panics on the first attempt at MIDI transfer, or does it panic during enumeration? The former indicates an issue with the bulk endpoints, the latter with the control endpoint. Also, can you confirm the RP2040 is only attempting 8-byte transfers before it panics? Finally, please have a look at the USB descriptor. Is the 8 byte packet size bMaxPacketSize0 from the device descriptor or wMaxPacketSize from the endpoint descriptor (or both)? |
With regard to NAK retries - have you tried setting NAK_POLL to zero? |
@eskimo-software I thought about it but it applies globally and so I didn't do it. What I did is discussed here #1261. If you tried it and it works, that would be very cool to know. |
Well, it shouldn't apply to interrupt transfers, so it applying (otherwise) globally shouldn't matter, should it? In any case, if I can set up a test for this I'll share any results I get. |
More thinking out loud - even though it's declared in the descriptor as a Bulk endpoint, is there any reason the host can't operate the IN endpoint as if it's an Interrupt endpoint? That would result in automatic polling and (presumably) correct NAK handling without any special consideration. |
@hathach The host API in the master branch is different from the API I used to write this pull request. Do you need me to close this pull request and submit a new one written to the current API, or is the API still fluid? |
I'm also interested in this, it would be good to have an update on the host API status from you, @hathach. If the host API changed but is stable again I might also try my hand at changing this PR over if @rppicomidi isn't on it already, although I'm much less familiar with tinyusb or the changes at this point. |
At this point, this pull request is obsolete. Merged pull request #1434 implemented RP2040 bulk endpoints more cleanly. Some of the other changes I made are either already in TinyUSB from other pull requests or have been implemented in TinyUSB in an equally functional way. Pull request #1627 fixed several bugs in this pull request. Finally, I have used the code from #1627 to create this application host driver; the driver also implements BULK IN endpoint polling more cleanly so the application no longer needs to do it in the main loop. For these reasons, I am closing this pull request. |
Describe the PR
This pull request adds MIDI host functionality to tinyusb.
Additional context
This code is a work in progress and should be treated as a draft. I am submitting it as a pull request in hopes it will be helpful.
Working now
There are a lot of known defects
Blocking Issues
@hathach I am struggling with the IN endpoint. The Korg device I use for most of my testing should be sending a NAK for each transfer request when no controls are touched, but the RP2040 is happily reporting completed transfer for each transfer request. The buffers contain all 0s. I don't have a bus analyzer so I don't know whether the Korg test device or my code is at fault there. Also not clear is what to do with the NAK_POLL register at offset 0x6c; I would think that a bulk IN endpoint that shares hardware with bulk OUT should not automatically retry on NAK, nor should it time out. It should set the NAK flag in the SIE status register, but I don't observe that. Do you know of a support path from the Raspberry Pi foundation where I can get direct answers to questions about the USB on the RP2040?