Issues in UART in updating Rx_length

Hi,

We are using bl-653,

we wanted to enable UART-1, for bl-653 we wrote overlay & configurations mentioned below:

&uart1 {
compatible = "nordic,nrf-uarte";
current-speed = <115200>;
status = "okay";
tx-pin = <15>;
rx-pin = <24>;
label = "UART_1";
};

configurations enabled for UART:

CONFIG_UART_0_INTERRUPT_DRIVEN=n
CONFIG_UART_0_ASYNC=y
CONFIG_UART_1_ASYNC=y
CONFIG_UART_1_INTERRUPT_DRIVEN=n
CONFIG_UART_ASYNC_API=y
CONFIG_SERIAL=y

We are able to bind the device configured – UART-1, also we are able to receive the accurate data in rx buffer which is sent from terminal, but we are not able to get exact length of received data, we are using this implementation for rx_index = evt->data.rx.len; but length is not accurate, can you please help if there procedure needs to be followed to clear rx_buffer and rx_index once we recieve data in one instance? we can observe the buffer is not getting cleared and there is mismatch in rx_index

Thank you,

Parents
  • Hello,

    First, I would like to point out that you can look at the sample NCS\nrf\samples\bluetooth\peripheral_uart for an example on how you can use the UART on the nRF5X chip. 

    I am not sure exactly where in the libraries you are now, but if this is the callback containing the uart_event struct, then the uart_event_rx struct contains three parameters. 

    uint8_t *buf;
    size_t offset;
    size_t len;

    where *buf is the pointer to the buffer, offset is the currently received data offset in bytes, and len is the number of new bytes received. (This description is from uart.h in NCS\zephyr\include\drivers\uart.h).

    It also says: "The data represented by the event is stored in rx.buf[rx.offset] to rx.buf[rx.offset+rx.len]. That is, the length is relative to the offset".

    This means that the new data in this event is starting at "offset", and it has "len" bytes. 

    Best regards,

    Edvin

  • Hi,

    as described it is working as per offset,

    there is a situation here,

    Situation -1 

    I have 30 bytes rx buffer, if i send 4 bytes

    buffer - it'll fill rx buffer from 0th index to 3rd index

    offset - 4

    and length - 4

    Situation -2

    post sending 4 bytes I'll send 20 bytes, so in rx buff it'll start filling from 4th index to 23rd index

    offset will also be 24 

    length will be - 20

    but as per our requirement in every transaction we want buffer and offset to be cleared,

    we don't want to keep historic data received in previous frame,

    can you pls suggest ways to do this or any sample application 

    Thank you

Reply
  • Hi,

    as described it is working as per offset,

    there is a situation here,

    Situation -1 

    I have 30 bytes rx buffer, if i send 4 bytes

    buffer - it'll fill rx buffer from 0th index to 3rd index

    offset - 4

    and length - 4

    Situation -2

    post sending 4 bytes I'll send 20 bytes, so in rx buff it'll start filling from 4th index to 23rd index

    offset will also be 24 

    length will be - 20

    but as per our requirement in every transaction we want buffer and offset to be cleared,

    we don't want to keep historic data received in previous frame,

    can you pls suggest ways to do this or any sample application 

    Thank you

Children
  • hiteshk0104 said:

    but as per our requirement in every transaction we want buffer and offset to be cleared,

    Why do you need this? The uart module that you are using requires a ring buffer. The reason for this is that it needs to be able to handle incoming data while you are handling the previous interrupt. I don't see any good reasons to overwrite the logic in this driver. If you want a buffer with offset 0 and length equal the length of the new data in this interrupt, I suggest you write something on top that handles this for you. Pretty much like the peripheral_uart example does. You can see in the ble_write_thread, it always receives a simple buffer with a length, and no offset.

    BR,

    Edvin

Related