reg: zephyr 1.6 => samples\usb\console


Mahendravarman Rajarao (RBEI/EAA3) <Mahendravarman.Rajarao@...>
 

Hi

Please help on the following

In the latest zephyr 1.6 release , under samples\usb\console folder, the example is given to show the console output coming to USB UART.

dev = device_get_binding(CONFIG_CDC_ACM_PORT_NAME); is missing in this console example
Device binding is not needed for console display ?


What the difference between the samples\usb\cdc_acm and samples\usb\console codes ?

Best regards
Mahendravarman


Joseph, Jithu
 

Please find the answers below :

Device binding is not needed for console display ?
No - application code need not do that. It is enough that the apps define CONFIG_UART_CONSOLE_ON_DEV_NAME if they want to override the default console device


Console output devices are opened from uart_console_init() ( drivers/console/uart_console.c ) as

uart_console_dev = device_get_binding(CONFIG_UART_CONSOLE_ON_DEV_NAME);


If CONFIG_USB_UART console is defined, CONFIG_UART_CONSOLE_ON_DEV_NAME defaults to "CDC_ACM" via (arch/x86/soc/intel_quark/quark_se/Kconfig.defconfig.series)


What the difference between the samples\usb\cdc_acm and samples\usb\console codes ?

The first one implements an echo type console on usb UART, wherein whatever character you type in minicom comes to the zephyr device and is echoed back to minicom. (While the debug prints still get routed to the actual physical uart). So in the sample app code you would see this logic.



In the second case, the config options cause the effect that all the debug prints come out via minicom on the host via the USB UART . The logic is mostly in the console driver (to plumb all the printks to USB UART) and the sample is meant to show config options as called out in README.



Hope that helps.

Thanks
Jithu

From: Mahendravarman Rajarao (RBEI/EAA3) [mailto:Mahendravarman.Rajarao(a)in.bosch.com]
Sent: Monday, December 5, 2016 5:18 AM
To: devel(a)lists.zephyrproject.org
Subject: [devel] reg: zephyr 1.6 => samples\usb\console

Hi

Please help on the following

In the latest zephyr 1.6 release , under samples\usb\console folder, the example is given to show the console output coming to USB UART.

dev = device_get_binding(CONFIG_CDC_ACM_PORT_NAME); is missing in this console example
Device binding is not needed for console display ?


What the difference between the samples\usb\cdc_acm and samples\usb\console codes ?

Best regards
Mahendravarman


Joseph, Jithu
 

Noticed a typo in my earlier reply, corrected inline

Thanks
Jithu

From: Joseph, Jithu [mailto:jithu.joseph(a)intel.com]
Sent: Monday, December 5, 2016 10:49 AM
To: Mahendravarman Rajarao (RBEI/EAA3) <Mahendravarman.Rajarao(a)in.bosch.com>; devel(a)lists.zephyrproject.org
Subject: [devel] Re: reg: zephyr 1.6 => samples\usb\console

Please find the answers below :

Device binding is not needed for console display ?
No - application code need not do that. It is enough that the apps define CONFIG_UART_CONSOLE_ON_DEV_NAME if they want to override the default console device


Console output devices are opened from uart_console_init() ( drivers/console/uart_console.c ) as

uart_console_dev = device_get_binding(CONFIG_UART_CONSOLE_ON_DEV_NAME);


If CONFIG_USB_UART console
[Joseph, Jithu] ] if CONFIG_USB_UART_CONSOLE
is defined, CONFIG_UART_CONSOLE_ON_DEV_NAME defaults to "CDC_ACM" via (arch/x86/soc/intel_quark/quark_se/Kconfig.defconfig.series)


What the difference between the samples\usb\cdc_acm and samples\usb\console codes ?

The first one implements an echo type console on usb UART, wherein whatever character you type in minicom comes to the zephyr device and is echoed back to minicom. (While the debug prints still get routed to the actual physical uart). So in the sample app code you would see this logic.



In the second case, the config options cause the effect that all the debug prints come out via minicom on the host via the USB UART . The logic is mostly in the console driver (to plumb all the printks to USB UART) and the sample is meant to show config options as called out in README.



Hope that helps.

Thanks
Jithu

From: Mahendravarman Rajarao (RBEI/EAA3) [mailto:Mahendravarman.Rajarao(a)in.bosch.com]
Sent: Monday, December 5, 2016 5:18 AM
To: devel(a)lists.zephyrproject.org<mailto:devel(a)lists.zephyrproject.org>
Subject: [devel] reg: zephyr 1.6 => samples\usb\console

Hi

Please help on the following

In the latest zephyr 1.6 release , under samples\usb\console folder, the example is given to show the console output coming to USB UART.

dev = device_get_binding(CONFIG_CDC_ACM_PORT_NAME); is missing in this console example
Device binding is not needed for console display ?


What the difference between the samples\usb\cdc_acm and samples\usb\console codes ?

Best regards
Mahendravarman


Chuck Jordan <Chuck.Jordan@...>
 

Actually, it would be more ideal if on any given UART port, you could designate whether or not it should run a console, or be left to be open by the Application for some other purpose. If you had 2 UARTS, you might want a console on each.
OR you might want one to be running a modem and the other as a console.

Consoles should also APPEAR above a TELNET service if wifi/enet, if wanted.

Or a console on USB - yes.

I suppose even a web page can have a console inside - if someone implements that - and it could be more secure with ssl.

Consoles might also be wanted over JTAG - if JTAG has UART.

-Chuck


From: Joseph, Jithu [mailto:jithu.joseph(a)intel.com]
Sent: Monday, December 05, 2016 12:49 PM
To: Mahendravarman Rajarao (RBEI/EAA3) <Mahendravarman.Rajarao(a)in.bosch.com>; devel(a)lists.zephyrproject.org
Subject: [devel] Re: reg: zephyr 1.6 => samples\usb\console

Please find the answers below :

Device binding is not needed for console display ?
No - application code need not do that. It is enough that the apps define CONFIG_UART_CONSOLE_ON_DEV_NAME if they want to override the default console device


Console output devices are opened from uart_console_init() ( drivers/console/uart_console.c ) as

uart_console_dev = device_get_binding(CONFIG_UART_CONSOLE_ON_DEV_NAME);


If CONFIG_USB_UART console is defined, CONFIG_UART_CONSOLE_ON_DEV_NAME defaults to "CDC_ACM" via (arch/x86/soc/intel_quark/quark_se/Kconfig.defconfig.series)


What the difference between the samples\usb\cdc_acm and samples\usb\console codes ?

The first one implements an echo type console on usb UART, wherein whatever character you type in minicom comes to the zephyr device and is echoed back to minicom. (While the debug prints still get routed to the actual physical uart). So in the sample app code you would see this logic.



In the second case, the config options cause the effect that all the debug prints come out via minicom on the host via the USB UART . The logic is mostly in the console driver (to plumb all the printks to USB UART) and the sample is meant to show config options as called out in README.



Hope that helps.

Thanks
Jithu

From: Mahendravarman Rajarao (RBEI/EAA3) [mailto:Mahendravarman.Rajarao(a)in.bosch.com]
Sent: Monday, December 5, 2016 5:18 AM
To: devel(a)lists.zephyrproject.org<mailto:devel(a)lists.zephyrproject.org>
Subject: [devel] reg: zephyr 1.6 => samples\usb\console

Hi

Please help on the following

In the latest zephyr 1.6 release , under samples\usb\console folder, the example is given to show the console output coming to USB UART.

dev = device_get_binding(CONFIG_CDC_ACM_PORT_NAME); is missing in this console example
Device binding is not needed for console display ?


What the difference between the samples\usb\cdc_acm and samples\usb\console codes ?

Best regards
Mahendravarman


Chuck Jordan <Chuck.Jordan@...>
 

Well actually, I guess there are two concepts:

* "console" which could be printk's from even kernel code - going to one-and-only-one place

* "cli" - command line interface, which might support ascii commands, command-line-edit, history - such as the "readline" API.
It would be "cli" that could appear in many instantiations.

-Chuck

From: Chuck Jordan
Sent: Friday, December 09, 2016 2:41 PM
To: 'Joseph, Jithu' <jithu.joseph(a)intel.com>; Mahendravarman Rajarao (RBEI/EAA3) <Mahendravarman.Rajarao(a)in.bosch.com>; devel(a)lists.zephyrproject.org
Subject: RE: reg: zephyr 1.6 => samples\usb\console

Actually, it would be more ideal if on any given UART port, you could designate whether or not it should run a console, or be left to be open by the Application for some other purpose. If you had 2 UARTS, you might want a console on each.
OR you might want one to be running a modem and the other as a console.

Consoles should also APPEAR above a TELNET service if wifi/enet, if wanted.

Or a console on USB - yes.

I suppose even a web page can have a console inside - if someone implements that - and it could be more secure with ssl.

Consoles might also be wanted over JTAG - if JTAG has UART.

-Chuck


From: Joseph, Jithu [mailto:jithu.joseph(a)intel.com]
Sent: Monday, December 05, 2016 12:49 PM
To: Mahendravarman Rajarao (RBEI/EAA3) <Mahendravarman.Rajarao(a)in.bosch.com<mailto:Mahendravarman.Rajarao(a)in.bosch.com>>; devel(a)lists.zephyrproject.org<mailto:devel(a)lists.zephyrproject.org>
Subject: [devel] Re: reg: zephyr 1.6 => samples\usb\console

Please find the answers below :

Device binding is not needed for console display ?
No - application code need not do that. It is enough that the apps define CONFIG_UART_CONSOLE_ON_DEV_NAME if they want to override the default console device


Console output devices are opened from uart_console_init() ( drivers/console/uart_console.c ) as

uart_console_dev = device_get_binding(CONFIG_UART_CONSOLE_ON_DEV_NAME);


If CONFIG_USB_UART console is defined, CONFIG_UART_CONSOLE_ON_DEV_NAME defaults to "CDC_ACM" via (arch/x86/soc/intel_quark/quark_se/Kconfig.defconfig.series)


What the difference between the samples\usb\cdc_acm and samples\usb\console codes ?

The first one implements an echo type console on usb UART, wherein whatever character you type in minicom comes to the zephyr device and is echoed back to minicom. (While the debug prints still get routed to the actual physical uart). So in the sample app code you would see this logic.



In the second case, the config options cause the effect that all the debug prints come out via minicom on the host via the USB UART . The logic is mostly in the console driver (to plumb all the printks to USB UART) and the sample is meant to show config options as called out in README.



Hope that helps.

Thanks
Jithu

From: Mahendravarman Rajarao (RBEI/EAA3) [mailto:Mahendravarman.Rajarao(a)in.bosch.com]
Sent: Monday, December 5, 2016 5:18 AM
To: devel(a)lists.zephyrproject.org<mailto:devel(a)lists.zephyrproject.org>
Subject: [devel] reg: zephyr 1.6 => samples\usb\console

Hi

Please help on the following

In the latest zephyr 1.6 release , under samples\usb\console folder, the example is given to show the console output coming to USB UART.

dev = device_get_binding(CONFIG_CDC_ACM_PORT_NAME); is missing in this console example
Device binding is not needed for console display ?


What the difference between the samples\usb\cdc_acm and samples\usb\console codes ?

Best regards
Mahendravarman


Boie, Andrew P
 

We do support the use case of selecting which UART to use for console, for instance on Nios II we used to have the JTAG UART as the default console instead of the 16550. But the way this is configured is pretty unintuitive.
Don't think we support sending console to multiple UARTS yet.

Andrew

From: Chuck Jordan [mailto:Chuck.Jordan(a)synopsys.com]
Sent: Friday, December 9, 2016 12:41 PM
To: Joseph, Jithu <jithu.joseph(a)intel.com>; Mahendravarman Rajarao (RBEI/EAA3) <Mahendravarman.Rajarao(a)in.bosch.com>; devel(a)lists.zephyrproject.org
Subject: [devel] Re: reg: zephyr 1.6 => samples\usb\console

Actually, it would be more ideal if on any given UART port, you could designate whether or not it should run a console, or be left to be open by the Application for some other purpose. If you had 2 UARTS, you might want a console on each.
OR you might want one to be running a modem and the other as a console.

Consoles should also APPEAR above a TELNET service if wifi/enet, if wanted.

Or a console on USB - yes.

I suppose even a web page can have a console inside - if someone implements that - and it could be more secure with ssl.

Consoles might also be wanted over JTAG - if JTAG has UART.

-Chuck


From: Joseph, Jithu [mailto:jithu.joseph(a)intel.com]
Sent: Monday, December 05, 2016 12:49 PM
To: Mahendravarman Rajarao (RBEI/EAA3) <Mahendravarman.Rajarao(a)in.bosch.com<mailto:Mahendravarman.Rajarao(a)in.bosch.com>>; devel(a)lists.zephyrproject.org<mailto:devel(a)lists.zephyrproject.org>
Subject: [devel] Re: reg: zephyr 1.6 => samples\usb\console

Please find the answers below :

Device binding is not needed for console display ?
No - application code need not do that. It is enough that the apps define CONFIG_UART_CONSOLE_ON_DEV_NAME if they want to override the default console device


Console output devices are opened from uart_console_init() ( drivers/console/uart_console.c ) as

uart_console_dev = device_get_binding(CONFIG_UART_CONSOLE_ON_DEV_NAME);


If CONFIG_USB_UART console is defined, CONFIG_UART_CONSOLE_ON_DEV_NAME defaults to "CDC_ACM" via (arch/x86/soc/intel_quark/quark_se/Kconfig.defconfig.series)


What the difference between the samples\usb\cdc_acm and samples\usb\console codes ?

The first one implements an echo type console on usb UART, wherein whatever character you type in minicom comes to the zephyr device and is echoed back to minicom. (While the debug prints still get routed to the actual physical uart). So in the sample app code you would see this logic.



In the second case, the config options cause the effect that all the debug prints come out via minicom on the host via the USB UART . The logic is mostly in the console driver (to plumb all the printks to USB UART) and the sample is meant to show config options as called out in README.



Hope that helps.

Thanks
Jithu

From: Mahendravarman Rajarao (RBEI/EAA3) [mailto:Mahendravarman.Rajarao(a)in.bosch.com]
Sent: Monday, December 5, 2016 5:18 AM
To: devel(a)lists.zephyrproject.org<mailto:devel(a)lists.zephyrproject.org>
Subject: [devel] reg: zephyr 1.6 => samples\usb\console

Hi

Please help on the following

In the latest zephyr 1.6 release , under samples\usb\console folder, the example is given to show the console output coming to USB UART.

dev = device_get_binding(CONFIG_CDC_ACM_PORT_NAME); is missing in this console example
Device binding is not needed for console display ?


What the difference between the samples\usb\cdc_acm and samples\usb\console codes ?

Best regards
Mahendravarman


Chuck Jordan <Chuck.Jordan@...>
 

So I think I misunderstood since "console" is a name can have various meanings.
But I think Zephyr's use of console is the one-and-only-one place your printk's go ... True?

The notion of a CLI or SHELL is the thing that might need to have multiple instantiations - and if you have a collection of UARTs out there, I suppose it is up to the application whether it wants to spawn a task for n UART ports and support n shells, etc.
Not all UART ports would necessarily be used in that way. They might be opened for use with modem or point-to-point connection to another computer, or to talk to a little chip that provides UART connectivity, etc.

-Chuck

From: Boie, Andrew P [mailto:andrew.p.boie(a)intel.com]
Sent: Friday, December 09, 2016 3:45 PM
To: Chuck Jordan <Chuck.Jordan(a)synopsys.com>; Joseph, Jithu <jithu.joseph(a)intel.com>; Mahendravarman Rajarao (RBEI/EAA3) <Mahendravarman.Rajarao(a)in.bosch.com>; devel(a)lists.zephyrproject.org
Subject: RE: reg: zephyr 1.6 => samples\usb\console

We do support the use case of selecting which UART to use for console, for instance on Nios II we used to have the JTAG UART as the default console instead of the 16550. But the way this is configured is pretty unintuitive.
Don't think we support sending console to multiple UARTS yet.

Andrew

From: Chuck Jordan [mailto:Chuck.Jordan(a)synopsys.com]
Sent: Friday, December 9, 2016 12:41 PM
To: Joseph, Jithu <jithu.joseph(a)intel.com<mailto:jithu.joseph(a)intel.com>>; Mahendravarman Rajarao (RBEI/EAA3) <Mahendravarman.Rajarao(a)in.bosch.com<mailto:Mahendravarman.Rajarao(a)in.bosch.com>>; devel(a)lists.zephyrproject.org<mailto:devel(a)lists.zephyrproject.org>
Subject: [devel] Re: reg: zephyr 1.6 => samples\usb\console

Actually, it would be more ideal if on any given UART port, you could designate whether or not it should run a console, or be left to be open by the Application for some other purpose. If you had 2 UARTS, you might want a console on each.
OR you might want one to be running a modem and the other as a console.

Consoles should also APPEAR above a TELNET service if wifi/enet, if wanted.

Or a console on USB - yes.

I suppose even a web page can have a console inside - if someone implements that - and it could be more secure with ssl.

Consoles might also be wanted over JTAG - if JTAG has UART.

-Chuck


From: Joseph, Jithu [mailto:jithu.joseph(a)intel.com]
Sent: Monday, December 05, 2016 12:49 PM
To: Mahendravarman Rajarao (RBEI/EAA3) <Mahendravarman.Rajarao(a)in.bosch.com<mailto:Mahendravarman.Rajarao(a)in.bosch.com>>; devel(a)lists.zephyrproject.org<mailto:devel(a)lists.zephyrproject.org>
Subject: [devel] Re: reg: zephyr 1.6 => samples\usb\console

Please find the answers below :

Device binding is not needed for console display ?
No - application code need not do that. It is enough that the apps define CONFIG_UART_CONSOLE_ON_DEV_NAME if they want to override the default console device


Console output devices are opened from uart_console_init() ( drivers/console/uart_console.c ) as

uart_console_dev = device_get_binding(CONFIG_UART_CONSOLE_ON_DEV_NAME);


If CONFIG_USB_UART console is defined, CONFIG_UART_CONSOLE_ON_DEV_NAME defaults to "CDC_ACM" via (arch/x86/soc/intel_quark/quark_se/Kconfig.defconfig.series)


What the difference between the samples\usb\cdc_acm and samples\usb\console codes ?

The first one implements an echo type console on usb UART, wherein whatever character you type in minicom comes to the zephyr device and is echoed back to minicom. (While the debug prints still get routed to the actual physical uart). So in the sample app code you would see this logic.



In the second case, the config options cause the effect that all the debug prints come out via minicom on the host via the USB UART . The logic is mostly in the console driver (to plumb all the printks to USB UART) and the sample is meant to show config options as called out in README.



Hope that helps.

Thanks
Jithu

From: Mahendravarman Rajarao (RBEI/EAA3) [mailto:Mahendravarman.Rajarao(a)in.bosch.com]
Sent: Monday, December 5, 2016 5:18 AM
To: devel(a)lists.zephyrproject.org<mailto:devel(a)lists.zephyrproject.org>
Subject: [devel] reg: zephyr 1.6 => samples\usb\console

Hi

Please help on the following

In the latest zephyr 1.6 release , under samples\usb\console folder, the example is given to show the console output coming to USB UART.

dev = device_get_binding(CONFIG_CDC_ACM_PORT_NAME); is missing in this console example
Device binding is not needed for console display ?


What the difference between the samples\usb\cdc_acm and samples\usb\console codes ?

Best regards
Mahendravarman