Fixed length uart frame detect on Zephyr

[P_WE]

Hello. 

I've got problem with detect uart frame received from another device. This device send me frames which has  fixed lenght (20B) and it always starts with 2B header ("**").

I used UART implementation with one static buffer. 

static int uart0_init(void)
{
	int err;

	if (!device_is_ready(uart_central)) 
	{
		LOG_ERR("UART0 device not ready");
		return -ENODEV;
	}

	err = uart_callback_set(uart_central, uart0_cb, NULL);
	if (err) 
	{
		return err;
	}

	return uart_rx_enable(uart_central, uart_central_rx_buff, sizeof(uart_central_rx_buff), SYS_FOREVER_US);
}

static void uart0_cb(const struct device *dev, struct uart_event *evt, void *user_data)
{
	ARG_UNUSED(dev);

	switch (evt->type) {
	case UART_TX_DONE:
		break;

	case UART_RX_RDY:
		break;

	case UART_RX_DISABLED:
		uart_rx_enable(uart_central, uart_central_rx_buff, sizeof(uart_central_rx_buff), UART_RX_TIMEOUT);
		break;

	case UART_RX_BUF_REQUEST:
		break;

	case UART_RX_BUF_RELEASED:
		break;

	case UART_TX_ABORTED:
		break;

	default:
		break;
	}
}

I tried to use UART_RX_RDY event type to detect frame header but it doesn't work well when UART_RX_BUF_REQUEST event occur and the buffer is fill from beggining and there are extra UART_RX_RDY events. I can make bigger buffer than frame which I'll receive from second device and clear buffer offset after receive frame but this solution won't be good if I receive some trash data or frame will have incorrect length. It could be hours between correct frames and I'm afraid that there could be some incorrect data. How to recognize corrrect frame in this situation. There would be no problem if there was an event after one byte receive. 

My device is build on nRF52840.

Regards,

P_WE

[Einar Thorsrud]

Hi,

It is not entierly clear to me what you receive and what you expect to receive? Can you show some examples and explain in more detail?

Generally though, if you are looking for a specific pattern, I would consider keeping a buffer where you store incoming data and search for the full "packet" there, so that it does not matter if you first receive a part of it, and subsequently the last part.

[P_WE]

I used this code: https://github.com/too1/ncs-uart-async-count-rx which is linked in another subject. It's OK, beacause I get data lenght and data in buffer but unfortunetelly it doesn't work well with 11520 baud. It's often lose one byte. I read data in seperate thread.

void thread_serial_central(void)
{
	uart0_init();
	LOG_INF("UART0 started");
	struct uart_msg_queue_item incoming_message;

	while(1)
	{
		// This function will not return until a new message is ready
		k_msgq_get(&uart_rx_msgq, &incoming_message, K_FOREVER);
		
		static uint8_t string_buffer[UART_BUF_SIZE + 1];
		memcpy(string_buffer, incoming_message.bytes, incoming_message.length);
		string_buffer[incoming_message.length] = 0;
		
		LOG_INF("RX %i: %s\n", incoming_message.length, string_buffer);
	}
}

Regards,

P_WE

[Einar Thorsrud]

Hi,

Do you mean 115200 baud? Is it so that you don't see this issue with lower baud rates?

[P_WE]

My mistake, of course it is 115200. I didn't notice issue when baudrate is slower. The problem is that last byte is in the buffer, but it is not read by:

k_msgq_get(&uart_rx_msgq, &incoming_message, K_FOREVER);

 

It is read when next frame has come.

Frame has 20B length, buffer is 16B long.

Situation is explained on screens.

UART0 is read in separate thread. There is also BLE scanner active in one time.

Regads,

P_WE

[Einar Thorsrud]

I see. The unofficial sample you have based this on is not optimal, in the sense that it does not use double buffering.  You should use double buffering, and it also makes sense to use large buffers (to avoid having too swap buffers too often). The last posts in this thread describe this.

[P_WE]

Very usefull thread. I've got solution of my problem. Thanks.