nRF5340 UART Interrupt mode send example

[SergeySK]

Hi all!
I'm currently working on the UART on the nRF5340 board. The SDK describes three options:
-polling API,
-interrupt-driven API,
-asynchronous API.
With Polling and Asynchronous - everything is clear and they do not suit me for various reasons.
Interrupt-driven doesn't have any APIs for starting (sending the first byte).
Searched everything.
Please share a link to an example.

[Sigurd Hellesvik]

Hi,

So that we are on the same page: Can you send me the link to the documentation you refer to?

The SDK describes three options:

Regards,
Sigurd Hellesvik

[SergeySK]

Hello Sigurd!

I have already searched through mountains in search of information. Start here
UART — Zephyr Project Documentation (nordicsemi.com)

I used the "peripheral_uart" example from SDK 2.0.0 to start with, but it uses an asynchronous uart.
I couldn't find an example with an interrupt driven API.

[Sigurd Hellesvik]

Hi Sergii,

Sorry for the late answer!

But I hopefully have information that can help you: the Zephyr UART echo sample uses interrupt driven UART for receiving messages, so you could learn how to do this from that sample.

Is this what you were looking for?

Regards,
Sigurd Hellesvik

[SergeySK]

Hey Sigurd!
In general, no problem - I myself like to work at night :)
Unfortunately, there is example given by you, the conclusion is made using blocking calls

/*
	* Print a null-terminated string character by character to the UART interface
	*/
	void print_uart(char *buf)
	{
	int msg_len = strlen(buf);
	for (int i = 0; i < msg_len; i++) {
	uart_poll_out(uart_dev, buf[i]);
	}
	}

I need the same thing, but with the interrupt.

[ovrebekk]

Hi Sergii

Sigurd is currently unavailable, and I will help you with this case in the mean time. 

Any particular reason why the async driver would not be suitable? If you are handling a lot of communication this should be more efficient. 

The hci_uart sample in Zephyr uses the interrupt driver both in TX and RX, and you can have a look at that to see how you can handle the TX part in the interrupt. In particular have a look at this section in main.c.

Best regards
Torbjørn

[SergeySK]

Thanks for the tip, Torbjorn.
I guessed that for the first byte it is proposed to use blocking output, and all subsequent ones through the ring buffer is a classic. 
And UART interrupts load the processor with noise much less, for example, when waiting for the start byte (STX), the rest are simply ignored.
Best regads!

[ovrebekk]

Hi

The async driver also utilizes the DMA feature of the UARTE peripheral to avoid generating interrupts on every single byte. You need to provide buffers for the UART driver to use, and the larger you make the buffers the more rare the interrupts will be. 

Best regards
Torbjørn

[SergeySK]

Hi
It is impossible to use DMA for reception in the real world, since in it (the real world) you can both lose a byte due to interference, and get +1 0xFF byte due to an interference pulse (start bit 0).
And in wearable devices, it is quite easy to be near a thyristor regulator, a neon lamp or a contactless charger, and indeed there is a lot of interference in the real world.
Best regads
Sergey.

[ovrebekk]

Hi Sergey

DMA is just a different way to transfer data to and from a peripheral to RAM, and unless you transfer the data to RAM you won't be able to do anything with it.

Most of the peripherals in the nRF5340 uses DMA, including the radio, crypto modules, ADC and serial interfaces, so if the simple act of using DMA would cause a lot of data corruption it would be apparent immediately. 

In fact it is a bit imprecise of me to say that the async driver utilizes DMA, since all the UART drivers have to use the DMA feature to transfer data. The difference is that the async driver allows you to scale the RX buffers as you like (up to a maximum of 2^16 bytes) rather than process a single byte at a time, which means it utilizes the DMA feature in a more efficient way. 

In some of our older devices like the nRF52832 there was a UART peripheral without DMA controller, but this peripheral was deprecated and removed in newer devices. 

Best regards
Torbjørn

[SergeySK]

Hi Torbjørn

Of course, transferring between internal devices via DMA is preferable, but specifically with UART this can cause problems.

Let me explain with an example: if you need to receive a packet of 8 bytes, and set DMA to 8 bytes, then the impulse noise, "lowering" the RxD line for the time of the start bit, will ruin everything, and the false byte will be received first, then the 7th will be received byte of the packet, and the 8th byte will be lost.

And when using STX / ETX, the length of the packets can vary greatly due to the replacement of codes, and programming the DMA length will be a problem.

p.s. EazyDMA is a great idea!

Best regards, Sergey.