Whoop, after 2-3 weeks of works, I finally wrap up this PR. This is more difficult than my initial thought. Your repo is going uber low (bit banging) into USB, I learn quite a lot more from your code despite working with USB for quite some time. I could only imagine amount of time and effort you spend on oscilloscope to get this working. Really brilliant work !!

This PR implement #14 and add an register interface for pio-usb port (host/device) similar to native usb controller on rp2040 e.g event interrupt status, ep complete/error/stalled and irq handler. This allow pio-usb "low-level controller part" can be used with tinyusb.

Following is the notable changes:

• Move host and device specific code to pio_usb_host/device.c . This is mostly for maintaining purpose, I think it would be easier to separate code from separated mode. The cons is: this requires common function/variable declaration need to be placed in the an header. Let me know if you prefer to keep it all in one file, I will merge it back.

• Add new internal header pio_usb_ll.h for controller register interface (along with other internal common function of host & device)
• add some extra field for endpoint_t so that I could work as standalone without usb_devices variable. Also allow it to transfer more than max packet size for transfer like control, msc bulk in the future.
• Support for endpoint flow control with NAK if there is no "active" transfer to prevent overrun error. Also support endpoint stalled sent/received
• add PIO_USB_USE_TINYUSB to off-out internal usb host/device stack.
• All the existing API of pio_usb still and should work as it is and require no changes from running examples.

This is no way perfect and not optimized, but I did quite a bit of testing with both host and device. Let me know what you think and would change, I hope we could merge this soon.

Note: For testing with TinyUSB

• check out https://github.com/hathach/tinyusb/tree/pio-host and its submodule lib/Pico-PIO-USB
• compile example host/hid_to_cdc, which is configured to use native usb as cdc device, and pio usb as host to get hid input.
• any input event e.g mouse move, button will be printed to cdc on the native usb.

@tannewt @ladyada

Describe the feature you want to implement here:

First of all, thank you for this brilliant project. I have never worked with an software (bit-banging) controller that works as great as yours. I am sure lots of others will find this project helpful as well since it literally add free usb ports to pico mcu.

I am trying to add support for pico-usb as software controller to TinyUSB project, so that user can let's say have native usb for device, and pico-usb for host concurrently (or vice versa) while running in a single TinyUSB stack. It is a bit hacky at the moment but runs well in host mode as proof of concept, and is able to enumerate and get report my hid device. If you are interested in testing it out: cdc_msc_hid. I do have to temporarily remove some static of pico_usb.c so that tinyusb could extern and update the internal struct

https://github.com/hathach/Pico-PIO-USB/blob/92268187f3b0490a43d139ed2cb598b06258011f/pio_usb.c#L66-L69

After working on the port, I realize that both TinyUSB and pico-usb have host/device stack which handles anything above transaction-level e.g enumeration, class driver etc... This makes porting and maintaining a bit difficult and could potentially waste ram/rom for having same thing twice. I have spent more time to go through pio_usb.c and quite positive that we could separate controller (sub-transaction) and protocol stack. Though I am not sure if you are willing to do so.

TLDR, are you interested in separating controller to has its own API ? Which can be used by either TinyUSB (optional config) or your own driver (default config). You already did a great job with most of the abstraction, we only need to move them to a new file with a clear API with some hardware register style and/or callback e.g pio_usb_endpoint_irqhandle() when an transfer is complete etc... We could work out on the detail later. If you agree I will try my best to make an (draft) PR then you could review and shape the API to your liking or if you already have in your mind, that would be great to start with. The cons would be a bit of overhead is introduced, but I doubt that it is noticeable. Let me know what you think.

@tannewt @ladyada

Hi hi, I am trying to get pico-pio-usb working with arduino platform, basically with

• https://github.com/earlephilhower/arduino-pico
• https://github.com/adafruit/Adafruit_TinyUSB_Arduino

It is actually quite easy to make this repo compatible with Arduino IDE. We only need to

• add library.properties
• rename example to examples (plugrals)
• also included generated usb_rx/tx.pio.h since we probably don't have access to cmake pico_generate_pio_header
• Finally registry to arduino indexer https://github.com/arduino/library-registry

Another gotcha that Arduino IDE will recursive compiles all the files/folders under src, but I think we are good with it, just need to pay attention to this in the future PRs. But we could add an ci to verify that it build with arduino just fine.

Let me know what you think, since I have done a decent amount of work with Arduino library, I could help making all of these.

@ladyada

implement #31

• rename example to examples (plurals)
• add generated usb_rx/tx.pio.h header to src
• add library.properties: Please update library description to your liking. You could also add your maintainer email if wanted. Note: version= must be update correctly/consistently when making an release for arduino indexer to update
• include examples/arduino/device_info that print out device descriptor with pio-usb as host. required wip branch of
  • https://github.com/adafruit/Adafruit_TinyUSB_Arduino/tree/rp2040-pio-usb-host
  • 120mh, 240mhz option PR https://github.com/earlephilhower/arduino-pico/pull/628

~~Note: Since this PR also include the changes in #34, I will make this as draft and rebase when #34 is merged~~ rebased.

Describe the bug you encountered:

capture_hid_report

I connected a mouse to the gpio usb host, it works as expected during few seconds, then it just stop working until i restart the pico, then it works during few seconds... It looks like something breaks after few seconds of operation. How can I debug that?

What did you expect to happen instead?

capture_hid_report should work permanently.

What actually happened in your case?

capture_hid_report works only for a few seconds after power on. Then it just stop working.

...

Additional information

connected as: #7

Output:

4e53:5407 EP 0x81:      01 00 fd df 00 00 
4e53:5407 EP 0x81:      01 00 ff ef 00 00 
4e53:5407 EP 0x81:      01 00 00 f0 00 00 
4e53:5407 EP 0x81:      01 00 00 f0 00 00 
4e53:5407 EP 0x81:      01 00 01 e0 ff 00 
4e53:5407 EP 0x81:      01 00 01 f0 ff 00 
4e53:5407 EP 0x81:      01 00 02 f0 ff 00 
4e53:5407 EP 0x81:      01 00 02 e0 ff 00 
4e53:5407 EP 0x81:      01 00 02 e0 ff 00 
4e53:5407 EP 0x81:      01 00 02 d0 ff 00 
4e53:5407 EP 0x81:      01 00 00 d0 ff 00 
4e53:5407 EP 0x81:      01 00 ff 9f ff 00 

And after few seconds, it just stop working.

Describe the bug you encountered: After clone, build and flash, used minicom to see, at leasts "hello!" should appear right? But there is no communication

minicom -D /dev/ttyACM0

Welcome to minicom 2.7.1

OPTIONS: I18n 
Compiled on Aug 13 2017, 15:25:34.
Port /dev/ttyACM0, 11:13:37

Press CTRL-A Z for help on special keys

control in[timeout]
Enumeration failed(-2)
Root 0 disconnected
Disconnect                                                                                                                                                                
Disconnect device 0                                                                                                                                                       
Root 0 connected                                                                                                                                                          
Device 0 Connected                                                                                                                                                        
control in[complete]                                                                                                                                                      
Enumerating 10c4:8108, class:0, address:1                                                                                                                                 
control out[complete]                                                                                                                                                     
control in[timeout]                                                                                                                                                       
Failed to get string descriptor (Manufacture)                                                                                                                             
control in[timeout]                                                                                                                                                       
Failed to get string descriptor (Product)                                                                                                                                 
control in[timeout]                                                                                                                                                       
Enumeration failed(-2)                                                                                                                                                    
Root 0 disconnected                                                                                                                                                       
Disconnect                                                                                                                                                                
Disconnect device 1                                                                                                                                                       
Root 0 connected                                                                                                                                                          
Device 0 Connected                                                                                                                                                        
control in[complete]                                                                                                                                                      
Enumerating 10c4:8108, class:0, address:1
control out[complete]
control in[complete]
control in[timeout]
Failed to get string descriptor (Manufacture)
control in[complete]
control in[timeout]
Failed to get string descriptor (Product)
control in[complete]
control in[timeout]
Enumeration failed(-2)
Root 0 disconnected
Disconnect
Disconnect device 1
Root 0 connected
Device 0 Connected
control in[complete]
Enumerating 10c4:8108, class:0, address:1
control out[complete]
control in[complete]
control in[timeout]
Failed to get string descriptor (Manufacture)
control in[timeout]
Failed to get string descriptor (Product)
control in[timeout]
Enumeration failed(-2)
Root 0 disconnected
Disconnect
Disconnect device 1
Root 0 connected
Device 0 Connected
control in[complete]
Enumerating 10c4:8108, class:0, address:1
control out[complete]
control in[timeout]
Failed to get string descriptor (Manufacture)
control in[timeout]
Failed to get string descriptor (Product)
control in[timeout]
Enumeration failed(-2)
Root 0 disconnected
Disconnect
Disconnect device 1
Root 0 connected
Device 0 Connected

What did you expect to happen instead?

I expected the connection to succeed and to see "hello!" at least.

What actually happened in your case?

No communication.

Additional information

git clone https://github.com/sekigon-gonnoc/Pico-PIO-USB.git
cd Pico-PIO-USB/example
mkdir build
cd bulild
cmake ..
make

Then copied: Pico-PIO-USB/example/build/capture_hid_report/capture_hid_report.uf2 to Pico board and Disconnect/Reconnect.

I created a CMakeLists.txt for this library so projects can easily include it. Also makes it easier for projects if this library makes more changes.

Edited example cmake files to use library rather than manually add the sources.

Removed unused include that needed an extra library to compile.

Fixed a small compile warning when comparing signed to unsigned.

I'm looking to implement a USB mux for a keyboard and mouse. I know these exist in IC form with chips such as the FSUSB42UMX but I thought it would be neat if I could intercept a certain key combo on the keyboard to toggle the mux. I immediately though of the PIO on the RP2040 knowing it would be fast enough for USB FS. I was really happy to see that this library already existed.

With the current implementation would it be possible to create 2 device ports and a host port? Or could I create two device ports and use the native USB as the host? I know you have examples for multiple host ports but I need multiple devices. It looks like it should be possible, I just wanted to check before I get too deep into this.

Thanks for the help!

Describe the bug you encountered: I realize this is not supported yet officially, but I am attempting to implement a USB MSC Host with the Pico-PIO-USB. If log level is 1, enumeration fails getting the USB descriptor of the flash drive with a printout

[1:0] Control FAILED

If I set the log level to 3, enumeration succeeds. The flash drive mounts and I am able to read the block size and block count. ...

What did you expect to happen instead? I expected the host to at least be able to read the USB device descriptor even if USB MSC Host is not yet supported. ...

What actually happened in your case? Descriptor read fails every time.

...

Additional information

I am using a Raspberry Pi Pico board and a USB A breakout board that I modified to insert 27 ohm SMT resistors in series with the D+ and D- pins. I have routed D+ to Pico board pin 1 and D- to Pico board pin 2 as per default. I am using a Picoprobe for debug and for UART output; UART0 is the debug UART; I am using Pico board pins 21 and 22 for the UART: i.e., in my CMakeLists.txt

PICO_DEFAULT_UART_TX_PIN=16
PICO_DEFAULT_UART_RX_PIN=17

Power is supplied by my PC via the Pico Board microUSB connector. The USB device mode on the microUSB connector is not yet initialized. I have tested this hardware system with a USB Keyboard connected to the USB A + sample code and with 3 different MIDI devices connected to the USB A + my own USB MIDI host code. All work correctly.

I have a DreamSourceLab logic analyzer, so I can dig deeper. Any hints as to where I should look? Are there PulseView traces that you would recommend I examine?

When I try to run cmake .. I get this:

PICO_SDK_PATH is /home/user/pico-sdk
PICO platform is rp2040.
Build type is Release
PICO target board is pico.
Using board configuration from /home/user/pico-sdk/src/boards/include/boards/pico.h
TinyUSB available at /home/user/pico-sdk/lib/tinyusb/src/portable/raspberrypi/rp2040; enabling build support for USB.
cyw43-driver available at /home/user/pico-sdk/lib/cyw43-driver
lwIP available at /home/user/pico-sdk/lib/lwip
-- Configuring done
CMake Error at host_hid_to_device_cdc/CMakeLists.txt:2 (add_executable):
  Cannot find source file:

    /home/user/pico-sdk/lib/tinyusb/src/portable/raspberrypi/pio_usb/dcd_pio_usb.c

  Tried extensions .c .C .c++ .cc .cpp .cxx .cu .m .M .mm .h .hh .h++ .hm
  .hpp .hxx .in .txx


-- Generating done
CMake Generate step failed.  Build files cannot be regenerated correctly.

Quick workaround is to disable host_hid_to_device_cdc in CMakeLists.txt like this:

add_subdirectory(capture_hid_report)
add_subdirectory(usb_device)
# add_subdirectory(host_hid_to_device_cdc)

But where can an individual obtains missing files to get all examples to work?

Describe the bug you encountered:

The capture_hid_report shows the following data on mouse movements:

4e53:5407 EP 0x81:      01 00 fd df 00 00 
4e53:5407 EP 0x81:      01 00 ff ef 00 00 
4e53:5407 EP 0x81:      01 00 00 f0 00 00 
4e53:5407 EP 0x81:      01 00 00 f0 00 00 
4e53:5407 EP 0x81:      01 00 01 e0 ff 00 
4e53:5407 EP 0x81:      01 00 01 f0 ff 00 
4e53:5407 EP 0x81:      01 00 02 f0 ff 00 
4e53:5407 EP 0x81:      01 00 02 e0 ff 00 
4e53:5407 EP 0x81:      01 00 02 e0 ff 00 
4e53:5407 EP 0x81:      01 00 02 d0 ff 00 
4e53:5407 EP 0x81:      01 00 00 d0 ff 00 
4e53:5407 EP 0x81:      01 00 ff 9f ff 00 
4e53:5407 EP 0x81:      01 00 fd 9f ff 00 
4e53:5407 EP 0x81:      01 00 fb 7f ff 00 
4e53:5407 EP 0x81:      01 00 fb 7f ff 00 
4e53:5407 EP 0x81:      01 00 fa 7f ff 00 
4e53:5407 EP 0x81:      01 00 fc 7f ff 00 
4e53:5407 EP 0x81:      01 00 fc 8f ff 00 
4e53:5407 EP 0x81:      01 00 fe 9f ff 00 
4e53:5407 EP 0x81:      01 00 ff bf ff 00 
4e53:5407 EP 0x81:      01 00 00 d0 ff 00 
4e53:5407 EP 0x81:      01 00 ff df ff 00 
4e53:5407 EP 0x81:      01 00 00 e0 ff 00 
4e53:5407 EP 0x81:      01 00 00 f0 ff 00 
4e53:5407 EP 0x81:      01 00 00 f0 ff 00 

As you can see, changes are only in bytes 2,3,4.

On button events:

4e53:5407 EP 0x81:      01 01 00 00 00 00 
4e53:5407 EP 0x81:      01 00 00 00 00 00 
4e53:5407 EP 0x81:      01 02 00 00 00 00 
4e53:5407 EP 0x81:      01 00 00 00 00 00 
4e53:5407 EP 0x81:      01 02 00 00 00 00 
4e53:5407 EP 0x81:      01 00 00 00 00 00 
4e53:5407 EP 0x81:      01 02 00 00 00 00 
4e53:5407 EP 0x81:      01 00 00 00 00 00 
4e53:5407 EP 0x81:      01 02 00 00 00 00 
4e53:5407 EP 0x81:      01 00 00 00 00 00 
4e53:5407 EP 0x81:      01 08 00 00 00 00 
4e53:5407 EP 0x81:      01 00 00 00 00 00 
4e53:5407 EP 0x81:      01 08 00 00 00 00 
4e53:5407 EP 0x81:      01 00 00 00 00 00 
4e53:5407 EP 0x81:      01 08 00 00 00 00 
4e53:5407 EP 0x81:      01 00 00 00 00 00 

... for buttons, changes are in byte 1 only ... for wheel events, changes are in byte 5 only. ... byte 0 never changes, it is always 01

What did you expect to happen instead?

I was expecting: byte0 = Button number byte1, byte2 = 16bit x axis byte3, byte4 = 16bit y axis byte5 = wheel ...

What actually happened in your case?

Am I misinterpreting the data?

Apparently the actual data looks like:

byte0 = always 01 byte1 = Button byte2, byte3[0-3] = 12 bit X axis ? byte3[4-7], byte4 = 12 bit Y axis ? byte5 = wheel

Does it make sense?

Hi,

In the host_hid_to_device_cdc example, you mention in a comment: // TODO control LED on keyboard of host stack

In the above example, I tried playing with the keyboard Caps Lock LED using the tuh_hid_set_report function like so:

static uint8_t leds = KEYBOARD_LED_CAPSLOCK; //  = 2
tuh_hid_set_report(dev_addr, instance, 0, HID_REPORT_TYPE_OUTPUT, &leds, sizeof(leds));

but failed to get any results.

Is it because I am not doing things the right way or is it something that the Pico-PIO-USB library does not yet support?

Thank you.

In conventional implementations, the clock is synchronized only on the first edge of the data line. This PR implements a mechanism to resynchronize on the rising edge of the data line. This may improve #18

The USB specification allows for some clock errors; in the case of USB LS, even if the RP2040 clock is sufficiently accurate, a clock error of 1.5% can cause the RP2040 to go out of sync by around 30 bits (cumulative error exceeds 50%).

• Synchronize clock on rise edge by using consecutive jmp instructions
• Separate edge detector and NRZI decoder into different state machines
• invert both dm/dp pins to merge edge detector and EOP detector

So few MCUs offer USB MIDI HOST support, it would be AMAZING to have RPI2040 support for that. If possible, could you add an example that shows how to implement this? Thanks!!!

control data & status stage always start with DATA1. This pr fixes an issue with an Control OUT transfer (with data) where the PID is incorrectly DATA0. This should fix #55

PS: This issue is kind of critical for me to get host cdc running (need SET LINE CODING). @sekigon-gonnoc if possible, would you mind making a release after reviewed/merged. Thank you in advance.

I was using the PICO as a USB Host for a radio, using the built-in USB connector. I switched to the PIO implementation and the device no longer worked.

Setup of the radio requires Control Transfers with data stages.

Using a Logic Analyzer I compared the output from the PICO when using the built-in connector and PIO. The data stage of the control transfer starts with Data1 on the working built-in USB connector. The data stage of the control transfer starts with Data0 when using PIO.

https://www.keil.com/pack/doc/mw/USB/html/_u_s_b__control__transfers.html states: "The DATA stage is optional. If present, it always starts with a transaction containing a DATA1 packet. Then, the transaction type alternates between DATA0 and DATA1 until all required data have been transferred."

The radio works and the first packet of the data stage is set correctly after I set ep_data_id to 1 instead of 0 here: https://github.com/sekigon-gonnoc/Pico-PIO-USB/blob/main/src/pio_usb_host.c#L515

I have a branch I can use to make a pull request if that looks like a good solution. Edit: I just created a pull request. https://github.com/sekigon-gonnoc/Pico-PIO-USB/pull/56

Thanks.

I noticed that when using a USB Hub with the capture_hid_report example, it would cause a CONTROL_ERROR. I found that by adding a wait of 1000us in the control_in_protocol function, it would allow the USB Hub to initialize without erroring.

//=======================================
//    src/pio_usb_host.c
//=======================================
static int __no_inline_not_in_flash_func(control_in_protocol)(
    usb_device_t *device, uint8_t *tx_data, uint16_t tx_length,
    uint8_t *rx_buffer, uint16_t request_length) {
  int res = 0;

  control_pipe_t *pipe = &device->control_pipe;

  busy_wait_us(1000); // Adding this line fixes the usb hub

I am using USB Female Module and a USB High Speed Hub with 4 Ports