Hi @jfischer-no I'm thankful for this work but I have a big problem with this being "manually opt in by specifying a shield" as per

 Set ``-DSHIELD=cdc_acm_shell`` when you invoke ``west build``. For example:

This is just a non-starter for our customers, they need an easy way of getting zephyr and being able to test things as they do with any other board, not have to jump through hoops trying to get the most basic sample applications working. For our BL654 USB dongle it's basically a given that almost everyone will be using the CDC port either for Bluetooth or as a general UART and this should cater for those majority of users.

This is just a non-starter for our customers, they need an easy way of getting zephyr and being able to test things as they do with any other board, not have to jump through hoops trying to get the most basic sample applications working. For our BL654 USB dongle it's basically a given that almost everyone will be using the CDC port either for Bluetooth or as a general UART and this should cater for those majority of users.

I cannot take this seriously.

1. BL654_USB, https://docs.zephyrproject.org/latest/boards/arm/bl654_usb/doc/bl654_usb.html, looks like an end product, it is not a development board, even if it would (like nrf52840dongle) it is still very limited in terms of capabilities.
2. Zephyr's main tree is not a BSP for BL654_USB, you have to compromise and understand that not everything here is about your board.
3. It is obvious that we cannot enable USB device support by default at boot time. And there will always be a conflict between configuration at board level and configuration in the samples. So we need additional option for the boards like BL645_USB if it should have best possible coverage of the samples. There is no way around something like: west build -b nrf52840dongle_nrf52840 samplel -- -DADDITIONAL_OPTION=y, or a board variant like bl654_usb_usb_on, which is not better.

Taking (1) and (2) into account, what are most basic applications for BL654_USB dongle? Probably none. But useful applications, such as hci_usb or ot-coprocessor, work fine even with minimal board configuration, https://docs.zephyrproject.org/latest/guides/porting/board_porting.html#general-recommendations.
Finally, considering the steps required to get the firmware onto the board, is the additional option (3), like -DSHIELD=cdc_acm_shell, to build the firmware is the least evil of all.

This PR addresses a problem which one way or the other has to be solved, and this seems like a rather elegant solution, getting rid of the need to create overlays for each new program/tailored configs for each board enabling usb at boot.

I myself am working on a port of Wio Terminal board, which doesn't have a native UART, so needs to use CDC ACM to open a console accessible over USB.

This shield is not for a real hardware device but for an emulated UART controller,
analogous to how we have emulated boards.

I remain opposed to the idea of using SHIELD for this.

Dev-review (Dec 16, 2021):

• Clarify in board porting guide about USB being ok to enable if that is being used for serial console for the board
• Feeling from @mbolivar-nordic, @galak, @tejlmand felt that using SHIELD here didn't make sense as this was misusing the concept of a SHIELD. We need to look how we solve this -- Take a look at cmake: introduce snippets for common configuration #40669

Dev-review (Dec 16, 2021):

@galak if I recall correctly, it was also desired at the dev-review that this commit 9294f23 was taken into a dedicated PR, cause the ability to initialize USB device at boot time is a useful feature regardless of the opposition to use shield mechanism for cdc acm uart.

see also this comment: #40669 (comment)

believe the variant approach that has been discussed time back on slack should be continued.

This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time.