• State Not Answered
  • Replies 7 replies
  • Subscribers 76 subscribers
  • Views 835 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 315025
Options

Data got by calling the k_fifo_get() less than the data received by the UART RX

Tom.Fu

Dear Support Team

I test the peripheral_uart sample from NCS(V2.4.0), I found that the data got by calling the k_fifo_get() less than the data received by the UART RX. For example, I sent 208 Bytes to the UART RX but it just printed 200 Bytes by calling the LOG_HEXDUMP_INF()  macro as the screenshots below showing, and UART baud rate I set is 921600.

Below screenshot below shows I send 208 Bytes to the RX. This packet starts with 2c and ends with 2c.

Below screenshot shows the data printed by calling the LOG_HEXDUMP_INF()  macro. It starts with 2c but ends with 77, so there was still 8 bytes haven't been printed.

Why it would loss printing the 8 bytes? How could I print all of the any size of data packet without end with \r or \n received by the UART RX?  Many thanks.

Parents Reply Children
  • 0 in reply to Sigurd

    Dear Sigurd

    I configured the CONFIG_BT_NUS_UART_RX_WAIT_TIME  with value 50, it could print all the 240 bytes after PC sent 240 bytes to UART RX., but it was still loss printing the 8 bytes after PC sent 208 bytes to UART RX.

    Is there any other way to get all the data of any size sent to UART RX of nRF52832? Many thanks.

  • 0 in reply to Tom.Fu

    Hi,

    Tom.Fu said:
    Is there any other way to get all the data of any size sent to UART RX of nRF52832? Many thanks.

    The timeout should handle this, as long as the data is not sent too fast so it is lost because there is no available buffer.

    If you first send 208 bytes, then 32 more bytes afterwards, are you still losing the 8 bytes?

    Best regards,
    Jørgen

  • 0 in reply to Sigurd

    I'm having a similar problem.  Either the buffer has to fill up or the timeout has to occur.  If I send a shorter amount of bytes even with \r\n I still have to wait for the timeout.  As a workaround I significantly decreased the timeout CONFIG_BT_NUS_UART_RX_WAIT_TIME  which is a huge improvement but its not the optimal solution.  Race conditions and other nasty things can occur if not careful.  Ideally the data will show up immediately after the \r\n or something.  The way I'm seeing it the data only shows up with either all the data is sent or the timeout.  If that's not correct please let me know.  I think the original post I think maybe Tom Fu has a valid complaint and just reducing the timeout although is a big help its more of a bandage to me and a good solution should come forward.

  • 0 in reply to Ramulous

    Hi,

    Unless you know the exact size of the string before \r\n arrives, it is not possible to get the data before a timeout. The HW does not have any way to know when these characters are received, and it can therefor not inform the application before a timeout occurs. The other alternative is to use only 1 byte buffers for all UART transfers and check each received byte in SW, but this will cause heavy load on the CPU and is not feasible with high throughput on the UART. This will be a tradeoff that the designer makes in the application (frequency of interrupts vs. latency from transfer end until application interrupt).

    Best regards,
    Jørgen

  • 0 in reply to Jørgen Holmefjord

    Excellent, thanks for straightening me out on this!  I didn't mean to commandeer Tom Fu's post but it's all related.  If Tom needs any additional help maybe we can get him going or he might have it all figured out by now.  I will need to do some testing and so on now to consider the byte by byte transfer.  My background is embedded with bare metal so with a good context switch byte by byte back in the day wasn't that big of a deal.  It might be with such an involved operating system?  Would it be possible to hook this kind of "uart" up to the DMA?  Any other ideas?  Thanks.

Related
Terms of service