-
Notifications
You must be signed in to change notification settings - Fork 6.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
samples: shell_module: add shell support over CDC ACM #32586
samples: shell_module: add shell support over CDC ACM #32586
Conversation
994ff54
to
236f787
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This has been often requested by users
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"console" and "shell" are distinct functions. The role of this sample is to demonstrate a console on CDC-ACM.
Demonstration of a shell on CDC-ACM should be done as a sibling samples/subsys/usb/shell
, or even better added as an option in samples/subsys/shell/shell_module
so the shell that's being demonstrated is actually useful.
Understand, but do not fully agree, console sample is really simple, to have that again only with 2..3 different lines makes no sense in my opinion. Also, IMO |
I care far more about console than I do about shell, so I would prefer to keep the USB console example showing how to get a USB console. That sample is what I go to for basic USB console verification, and that it generates repeated text (as I'd get from log messages on a console) is exactly what I want for its behavior. When I do want a shell, I want a shell that actually does something useful, which is |
Add shell support over CDC ACM. Signed-off-by: Johann Fischer <[email protected]>
236f787
to
1d43686
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
|
||
dev = device_get_binding(CONFIG_UART_SHELL_ON_DEV_NAME); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could you use const struct device *dev = DEVICE_DT_GET(DT_CHOSEN(zephyr_shell_uart));
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That could be misleading. https://docs.zephyrproject.org/latest/reference/devicetree/api.html specifies that zephyr,shell-uart
is used only to supply the default value for CONFIG_UART_SHELL_ON_DEV_NAME
. The user can override the actual device through Kconfig.
It could be switched for the sample on an argument that the sample's prj.conf doesn't do that override, but that could confuse a user who finds the Kconfig then doesn't understand why the device selection code copied from the sample doesn't work.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
More relevantly: is it even possible to reference a CDC-ACM UART from devicetree? I think the answer is "no".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
More relevantly: is it even possible to reference a CDC-ACM UART from devicetree? I think the answer is "no".
It is not possible, but something to discuss, I have use case for that.
Add shell support over CDC ACM