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.