gh-raspberrypi/pico-sdk
Watch
1
0
Fork
You've already forked pico-sdk
 0
Code Issues 262 Pull requests 63 Releases Activity

feat(cherryusb): add cherryusb library #2212

Open
sakumisu wants to merge 3 commits from CherryUSB/master into develop
pull from: CherryUSB/master
merge into: gh-raspberrypi:develop
Conversation 15 Commits 3 Files changed 16 +1184
sakumisu commented 2025-01-25 05:22:33 -06:00 (Migrated from github.com)

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

1

2

Support usb device and host with cherryusb. Also host hub supports. ![1](https://github.com/user-attachments/assets/ed3d54d5-c17b-4963-ba73-dc7937280f1e) ![2](https://github.com/user-attachments/assets/ef152029-7c51-4b63-b9c6-288d05eb4472)
lurch commented 2025-01-27 05:28:11 -06:00 (Migrated from github.com)

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?)

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 commented 2025-01-27 05:55:20 -06:00 (Migrated from github.com)

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.

> 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 commented 2025-01-27 05:56:33 -06:00 (Migrated from github.com)

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

Could you list or point out which usb code? I can help to match with cherryusb.
lurch commented 2025-01-27 06:34:39 -06:00 (Migrated from github.com)

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).

> 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 commented 2025-02-06 07:05:40 -06:00 (Migrated from github.com)

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

image

> > 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 ![image](https://github.com/user-attachments/assets/60f9ddb0-5139-4c93-94d0-64b35811ce44)
lurch (Migrated from github.com) reviewed 2025-02-11 06:17:31 -06:00
src/rp2_common/pico_stdio_usb/stdio_usb.c
lurch (Migrated from github.com) commented 2025-02-11 06:17:31 -06:00

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

Please stick to existing code-formatting conventions, rather than moving braces to a new line.
lurch commented 2025-02-11 06:23:10 -06:00 (Migrated from github.com)

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.
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 commented 2025-02-11 06:33:04 -06:00 (Migrated from github.com)

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.

> > 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 commented 2025-02-11 06:35:47 -06:00 (Migrated from github.com)

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!)

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 commented 2025-02-11 06:44:35 -06:00 (Migrated from github.com)

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.

> 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 (Migrated from github.com) reviewed 2025-02-11 06:47:34 -06:00
src/rp2_common/pico_stdio_cherryusb/include/pico/stdio_usb.h
@ -0,0 +1,153 @@
/*
lurch (Migrated from github.com) commented 2025-02-11 06:47:33 -06:00

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

The `tools/extract_configs.py` script will get upset if the same `PICO_CONFIG:` entry appears in multiple different files.
kilograham commented 2025-06-24 16:39:54 -05:00 (Migrated from github.com)

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

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 commented 2025-06-24 21:02:05 -05:00 (Migrated from github.com)

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.

> 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 commented 2025-08-17 13:04:57 -05:00 (Migrated from github.com)

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.

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 commented 2025-08-18 02:33:32 -05:00 (Migrated from github.com)

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.

> 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.
This pull request has changes conflicting with the target branch.
  • src/rp2_common/pico_crt0/rp2040/memmap_blocked_ram.ld
  • src/rp2_common/pico_crt0/rp2040/memmap_copy_to_ram.ld
  • src/rp2_common/pico_crt0/rp2040/memmap_default.ld
  • src/rp2_common/pico_crt0/rp2040/memmap_no_flash.ld
  • src/rp2_common/pico_crt0/rp2350/memmap_copy_to_ram.ld
  • src/rp2_common/pico_crt0/rp2350/memmap_default.ld
  • src/rp2_common/pico_crt0/rp2350/memmap_no_flash.ld
View command line instructions

Manual merge helper

Use this merge commit message when completing the merge manually.

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u origin 'CherryUSB/master:CherryUSB/master'
git switch 'CherryUSB/master'

Merge

Merge the changes and update on Forgejo.

Warning: The "Autodetect manual merge" setting is not enabled for this repository, you will have to mark this pull request as manually merged afterwards.

git switch 'develop'
git merge --no-ff 'CherryUSB/master'
git switch 'CherryUSB/master'
git rebase 'develop'
git switch 'develop'
git merge --ff-only 'CherryUSB/master'
git switch 'CherryUSB/master'
git rebase 'develop'
git switch 'develop'
git merge --no-ff 'CherryUSB/master'
git switch 'develop'
git merge --squash 'CherryUSB/master'
git switch 'develop'
git merge --ff-only 'CherryUSB/master'
git switch 'develop'
git merge 'CherryUSB/master'
git push origin 'develop'
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels   
bazel

   
bluetooth

   
board settings

   
boot_stage2

   
bug
Something isn't working

  
build

   
c++

   
can't reproduce
Can not reproduce the bug

  
clang

   
clib-interface

   
cmsis

   
code cleanliness

   
code size

   
compiler version issues

   
cyw43_driver

   
debug

   
discussion

   
documentation
Improvements or additions to documentation

  
duplicate
This issue or pull request already exists

  
dynamic_clock

   
elf2uf2

   
enhancement
New feature or request

  
errata

   
filesystem

   
flash layout

   
floating point

   
FreeRTOS

   
hardware_adc

   
hardware_claim

   
hardware_clocks

   
hardware_dma

   
hardware_exception

   
hardware_flash

   
hardware_gpio

   
hardware_i2c

   
hardware_irq

   
hardware_pio

   
hardware_pwm

   
hardware_rcp

   
hardware_rtc

   
hardware_spi

   
hardware_sync

   
hardware_uart

   
hardware_vreg

   
hardware_watchdog

   
hardware_xosc

   
help wanted
Extra attention is needed

  
host

   
IAR

   
installation

   
invalid
This doesn't seem right

  
linker scripts

   
lto

   
lwip

   
mbedtls

   
missing API

   
needs reporter detail

   
networking

   
newlib

   
newlib-multicore

   
non-c

   
non-cmake

   
non-gcc

   
openocd

   
orphan PR

   
OS integration

   
pico_async_context

   
pico_base

   
pico_binary_info

   
pico_flash

   
picolibc

   
pico_lwip

   
pico_malloc

   
pico_multicore

   
pico_printf

   
pico_runtime

   
pico_stdio

   
pico_stdio_usb

   
pico_sync

   
pico_time

   
pico_util

   
pioasm

   
port
issues or discussions of porting code/libraries to rp2040

  
question
Further information is requested

  
review

   
review2

   
rtos interop
Consideration for FreeRTOS co-existence

  
runtime init

   
static library

   
svd

   
test

   
tinyusb

   
vscode

   
wifi integration

   
wontfix
This will not be worked on

No labels
bazel
bluetooth
board settings
boot_stage2
bug
build
c++
can't reproduce
clang
clib-interface
cmsis
code cleanliness
code size
compiler version issues
cyw43_driver
debug
discussion
documentation
duplicate
dynamic_clock
elf2uf2
enhancement
errata
filesystem
flash layout
floating point
FreeRTOS
hardware_adc
hardware_claim
hardware_clocks
hardware_dma
hardware_exception
hardware_flash
hardware_gpio
hardware_i2c
hardware_irq
hardware_pio
hardware_pwm
hardware_rcp
hardware_rtc
hardware_spi
hardware_sync
hardware_uart
hardware_vreg
hardware_watchdog
hardware_xosc
help wanted
host
IAR
installation
invalid
linker scripts
lto
lwip
mbedtls
missing API
needs reporter detail
networking
newlib
newlib-multicore
non-c
non-cmake
non-gcc
openocd
orphan PR
OS integration
pico_async_context
pico_base
pico_binary_info
pico_flash
picolibc
pico_lwip
pico_malloc
pico_multicore
pico_printf
pico_runtime
pico_stdio
pico_stdio_usb
pico_sync
pico_time
pico_util
pioasm
port
question
review
review2
rtos interop
runtime init
static library
svd
test
tinyusb
vscode
wifi integration
wontfix
Milestone
Clear milestone
No items
No milestone
2.4.0
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
gh-raspberrypi/pico-sdk!2212
No description provided.