feat(cherryusb): add cherryusb library

[sakumisu]

Support usb device and host with cherryusb. Also host hub supports.

[lurch]

Stupid question 1: Why does this modify the linker files in src/rp2_common/pico_crt0/rp2040/ but not those in src/rp2_common/pico_crt0/rp2350/ ?

Stupid question 2: Can this be used as a complete replacement for TinyUSB? (or would that require a much larger refactoring of the SDK's existing USB code?)

[sakumisu]

Stupid question 1: Why does this modify the linker files in src/rp2_common/pico_crt0/rp2040/ but not those in src/rp2_common/pico_crt0/rp2350/ ?

Stupid question 2: Can this be used as a complete replacement for TinyUSB? (or would that require a much larger refactoring of the SDK's existing USB code?)

1, my mistake, fixed
2, Our transfer api only has write & read and no need loop, it is easy to refactor.

[sakumisu]

Could you list or point out which usb code? I can help to match with cherryusb.

[lurch]

Could you list or point out which usb code? I can help to match with cherryusb.

I did a git grep -i tinyusb and it looks like apart from the src/rp2_common/tinyusb/ directory, tinyusb is only used in src/rp2_common/pico_stdio_usb/ (so perhaps not as much refactoring as I previously thought).

[sakumisu]

Could you list or point out which usb code? I can help to match with cherryusb.

I did a git grep -i tinyusb and it looks like apart from the src/rp2_common/tinyusb/ directory, tinyusb is only used in src/rp2_common/pico_stdio_usb/ (so perhaps not as much refactoring as I previously thought).

done

[lurch]

Please stick to existing code-formatting conventions, rather than moving braces to a new line.

[lurch]

More stupid questions from me:

• Why is this PR now deleting so many existing files?
• It looks like you've unconditionally edited pico_stdio_usb to support (only) cherryusb and removed support for tinyusb? However I think we'd prefer if the user could choose to either use the tinyusb stack OR the cherryusb stack. However I'm not sure how difficult that'd be, so it might something that @kilograham would need to provide guidance with.

[sakumisu]

Could you list or point out which usb code? I can help to match with cherryusb.

I did a git grep -i tinyusb and it looks like apart from the src/rp2_common/tinyusb/ directory, tinyusb is only used in src/rp2_common/pico_stdio_usb/ (so perhaps not as much refactoring as I previously thought).

Sorry, you told me refactor stdio_usb before, so i misunderstood to only support one.

[lurch]

Ahhh, apologies for the confusion!

EDIT (to clarify): The Raspberry Pi Pico SDK places a big emphasis on backwards-compatibility, and obviously unconditionally replacing tinyusb with cherryusb would break backwards-compatibility of the SDK for existing projects. So to stay backwards-compatible with all existing projects, pico_stdio_usb should continue to use tinyusb by default, but it might be nice if the user could optionally switch to use cherryusb for pico_stdio_usb, if they wanted to use the cherryusb stack instead of the tinyusb stack for new projects. (I'm assuming it wouldn't make sense to use both the tinyusb stack and the cherryusb stack in the same project!)

[sakumisu]

Ahhh, apologies for the confusion!

EDIT (to clarify): The Raspberry Pi Pico SDK places a big emphasis on backwards-compatibility, and obviously unconditionally replacing tinyusb with cherryusb would break backwards-compatibility of the SDK for existing projects. So to stay backwards-compatible with all existing projects, pico_stdio_usb should continue to use tinyusb by default, but it might be nice if the user could optionally switch to use cherryusb for pico_stdio_usb, if they wanted to use the cherryusb stack instead of the tinyusb stack for new projects. (I'm assuming it wouldn't make sense to use both the tinyusb stack and the cherryusb stack in the same project!)

Yes, i agree, i have changed.

[lurch]

The tools/extract_configs.py script will get upset if the same PICO_CONFIG: entry appears in multiple different files.

[kilograham]

Note, i had a little play with this:

On RP2350 memcpy/memset is not safe for unaligned or non word size copies involving USB memory.

I did this

Index: port/rp2040/usb_dc_rp2040.c
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/port/rp2040/usb_dc_rp2040.c b/port/rp2040/usb_dc_rp2040.c
--- a/port/rp2040/usb_dc_rp2040.c	(revision 43e6b5b1b1f6af62497e740db8faee4499724627)
+++ b/port/rp2040/usb_dc_rp2040.c	(revision 326386ebf93014375c4f74f4b2c8f11ce54fcdea)
@@ -82,6 +82,19 @@
     *ep->endpoint_control = reg;
 }
 
+// Provide own byte by byte memcpy as not all copies are aligned
+static void slow_memcpy(void *dst, const void *src, size_t n) {
+    uint8_t *dst_byte = (uint8_t*)dst;
+    const uint8_t *src_byte = (const uint8_t*)src;
+    while (n--) {
+        *dst_byte++ = *src_byte++;
+    }
+}
+
+static inline void unaligned_memcpy(void *dest, const void *src, size_t n) {
+    if (n&3) slow_memcpy(dest, src, n);
+    else memcpy(dest, src, n);
+}
 /**
  * @brief Starts a transfer on a given endpoint.
  *
@@ -101,7 +114,7 @@
     if (USB_EP_DIR_IS_IN(ep->ep_addr)) {
         /*!< Need to copy the data from the user buffer to the usb memory */
         if (buf != NULL) {
-            memcpy((void *)ep->data_buffer, (void *)buf, len);
+            unaligned_memcpy((void *)ep->data_buffer, (void *)buf, len);
         }
         /*!< Mark as full */
         val |= USB_BUF_CTRL_FULL;
@@ -401,7 +414,7 @@
 
     } else if (ep->ep_addr == 0x00) {
         /*!< EP0 Out */
-        memcpy(g_rp2040_udc.out_ep[0].xfer_buf, g_rp2040_udc.out_ep[0].data_buffer, read_count);
+        unaligned_memcpy(g_rp2040_udc.out_ep[0].xfer_buf, g_rp2040_udc.out_ep[0].data_buffer, read_count);
         if (read_count == 0) {
             /*!< Normal status stage // Setup  in...in  out  */
             /**

Which got the one example running, however I don't know which memcpy might be misaligned (I was assuming none for now) or non word sizes

[sakumisu]

Note, i had a little play with this:

On RP2350 memcpy/memset is not safe for unaligned or non word size copies involving USB memory.

I did this

Index: port/rp2040/usb_dc_rp2040.c
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/port/rp2040/usb_dc_rp2040.c b/port/rp2040/usb_dc_rp2040.c
--- a/port/rp2040/usb_dc_rp2040.c	(revision 43e6b5b1b1f6af62497e740db8faee4499724627)
+++ b/port/rp2040/usb_dc_rp2040.c	(revision 326386ebf93014375c4f74f4b2c8f11ce54fcdea)
@@ -82,6 +82,19 @@
     *ep->endpoint_control = reg;
 }
 
+// Provide own byte by byte memcpy as not all copies are aligned
+static void slow_memcpy(void *dst, const void *src, size_t n) {
+    uint8_t *dst_byte = (uint8_t*)dst;
+    const uint8_t *src_byte = (const uint8_t*)src;
+    while (n--) {
+        *dst_byte++ = *src_byte++;
+    }
+}
+
+static inline void unaligned_memcpy(void *dest, const void *src, size_t n) {
+    if (n&3) slow_memcpy(dest, src, n);
+    else memcpy(dest, src, n);
+}
 /**
  * @brief Starts a transfer on a given endpoint.
  *
@@ -101,7 +114,7 @@
     if (USB_EP_DIR_IS_IN(ep->ep_addr)) {
         /*!< Need to copy the data from the user buffer to the usb memory */
         if (buf != NULL) {
-            memcpy((void *)ep->data_buffer, (void *)buf, len);
+            unaligned_memcpy((void *)ep->data_buffer, (void *)buf, len);
         }
         /*!< Mark as full */
         val |= USB_BUF_CTRL_FULL;
@@ -401,7 +414,7 @@
 
     } else if (ep->ep_addr == 0x00) {
         /*!< EP0 Out */
-        memcpy(g_rp2040_udc.out_ep[0].xfer_buf, g_rp2040_udc.out_ep[0].data_buffer, read_count);
+        unaligned_memcpy(g_rp2040_udc.out_ep[0].xfer_buf, g_rp2040_udc.out_ep[0].data_buffer, read_count);
         if (read_count == 0) {
             /*!< Normal status stage // Setup  in...in  out  */
             /**

Which got the one example running, however I don't know which memcpy might be misaligned (I was assuming none for now) or non word sizes

Hi, from cherryusb v1.5.0, we use our own memcpy instead, i will update submodule in this pr.

[rumbledethumps]

Just wanted to drop in my two cents since I doubt very many people have tried CherryUSB on Pi Pico. Ultimately, I failed to make it work since I don't have the RAM, but here's what I learned.

I use TinyUSB in host mode and support 5 hubs, 16 HID devices, 8 MSC devices, and XInput as a vendor protocol. Of course, we all know that TinyUSB on the rp2 is still unstable, so that's why I tried CherryUSB.

Modifying the linker script is unnecessary. This appears to be in there to support a kind of module registration by leveraging the linker. Pico SDK has a mechanism for forcing code into flash and giving it a unique name. While I'm not a fan of extending program logic into the linker, using the tools we already have seems better than complicating an already complicated linker script for a single library that should leverage the existing linker script with a macro that can be changed per platform.

The memory usage is crazy large. The math is (5 hubs * (16 hid + 8 msc)) since you need to allocate memory for every potential port usage on every hub. 8-port hubs are very common and some devices, like keyboards, can have hubs built in. Keyboards and mice often report as composite keyboard+mouse so we need 2 HID per port. Even though I only need to support (5 hubs + 16 HID + 8 MSC) = 29 which TinyUSB happily does, I have to allocate for (5 hubs * (16 hid + 8 msc)) = 120.

And finally is the requirement of an OS. There's no poll option. I have a 20k loc project that uses usb, bluetooth, and wifi just fine without an OS. I can add an OS but I don't have to like it.

[sakumisu]

Just wanted to drop in my two cents since I doubt very many people have tried CherryUSB on Pi Pico. Ultimately, I failed to make it work since I don't have the RAM, but here's what I learned.

I use TinyUSB in host mode and support 5 hubs, 16 HID devices, 8 MSC devices, and XInput as a vendor protocol. Of course, we all know that TinyUSB on the rp2 is still unstable, so that's why I tried CherryUSB.

Modifying the linker script is unnecessary. This appears to be in there to support a kind of module registration by leveraging the linker. Pico SDK has a mechanism for forcing code into flash and giving it a unique name. While I'm not a fan of extending program logic into the linker, using the tools we already have seems better than complicating an already complicated linker script for a single library that should leverage the existing linker script with a macro that can be changed per platform.

The memory usage is crazy large. The math is (5 hubs * (16 hid + 8 msc)) since you need to allocate memory for every potential port usage on every hub. 8-port hubs are very common and some devices, like keyboards, can have hubs built in. Keyboards and mice often report as composite keyboard+mouse so we need 2 HID per port. Even though I only need to support (5 hubs + 16 HID + 8 MSC) = 29 which TinyUSB happily does, I have to allocate for (5 hubs * (16 hid + 8 msc)) = 120.

And finally is the requirement of an OS. There's no poll option. I have a 20k loc project that uses usb, bluetooth, and wifi just fine without an OS. I can add an OS but I don't have to like it.

You can change CONFIG_USBHOST_MAX_INTF_ALTSETTINGS to 1 for the less memory. And i don't think rp2 can support too many usb devices because of hardware endpoints limitation, also in cherryusb, we support dynamic endpoint(in urb) to reuse hardware endpoints.
Last, in cherryusb, we record all usb device's descriptors, we can easily read them and select one of them, so they are important, and some usb devices have many identical interfaces but different ep settings, and users need to choose one of them，this named INTF_ALTSETTING, usually for usb audio and video.