NRFConnect printk() an uart not conflicting?

RE: NRFConnect printk() an uart not conflicting?

Håkon Alseth — Tue, 25 Apr 2023 09:03:23 GMT

Hi,

[quote user="Johan.h"]

FYI, lesson 8 ex. 2 (Mutex) does not build out of the box as

CONFIG_TEST_RANDOM_GENERATOR=y

is missing from .prj file. (once added all is OK)

[/quote]

Thanks for letting us know. We actually fixed this issue yesterday, with this commit:

https://github.com/NordicDeveloperAcademy/ncs-fund/commit/665f30e56b00798205bbbd218af4259b62c0102a

[quote user="Johan.h"]

Understood, it is clear that changing UART prams like baud rate in the app will change printk() as well.

If I disable interrupts for uart, will prink(0 stop working?

[/quote]

The console uses poll_out, which does not use any interrupts, so you should be able to disable the UART interrupts.

I tested this quick by disabling uart interrupts (NRF_UARTE0->INTEN = 0) in hello_world, and it still prints the expected text.

Kind regards,

Håkon

RE: NRFConnect printk() an uart not conflicting?

Johan.h — Tue, 25 Apr 2023 07:41:13 GMT

Understood, it is clear that changing UART prams like baud rate in the app will change printk() as well.

If I disable interrupts for uart, will prink(0 stop working?

Anyway I will play a bit with this to get deeper understating from a viewpoint of an old-school embedded programmer.

FYI, lesson 8 ex. 2 (Mutex) does not build out of the box as

CONFIG_TEST_RANDOM_GENERATOR=y

is missing from .prj file. (once added all is OK)

Johanan

RE: NRFConnect printk() an uart not conflicting?

Håkon Alseth — Mon, 24 Apr 2023 14:45:40 GMT

Hello Johanan,

I'm usually used to handling questions that are related to something not working, which makes me glad to hear that everything is working as you want it.

[quote user=""]Can you explain what is going on under the hood? how does this work without conflicts?[/quote]

I'll try my best.

printk() can be routed to either "console" or "log". Let us assume that you're using the console (hint: setting CONFIG_LOG_PRINTK routes printk() through the logging module instead).

CONFIG_PRINTK kconfig reference lists this:

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.3.0/kconfig/index.html#CONFIG_PRINTK

The first sentence is:

Send printk() to console

To route printk() to the uart, as you have at this time, you need to set the backend of the console to the corresponding uart device in device-tree.

Most (if not all) define this in the board dts file:

https://github.com/nrfconnect/sdk-zephyr/blob/v3.2.99-ncs2/boards/arm/nrf52840dk_nrf52840/nrf52840dk_nrf52840.dts#L16

Both "uart" driver and the "console" subsys use the exact same peripheral here.

Here's the generic uart_console.c file, which will be equal for all devices that conforms to the zephyr "uart" API, by including zephyr/drivers/uart.h:

https://github.com/nrfconnect/sdk-zephyr/blob/v3.2.99-ncs2/drivers/console/uart_console.c

The exact same thing is done in the sample that you're using:

https://github.com/NordicDeveloperAcademy/ncs-fund/blob/main/v2.x.x/lesson5/fund_less5_exer1_solution/src/main.c#L17

So, both your application and the console goes to the uart API, which again goes to the underlying nrf driver:

https://github.com/nrfconnect/sdk-zephyr/blob/v3.2.99-ncs2/drivers/serial/uart_nrfx_uarte.c#L1760-L1792

example, uart.h::uart_tx() goes to uart_nrfx_uarte.c::uarte_nrfx_tx().

How does this work without any conflict? In this particular use-case, the API is blocking, so first come, first serve.

Kind regards,

Håkon