Getting UART transmitted data length

Hello,

I'm using nRF v1.5.1 SDK.

If I have my RX buffer to be of size say 6, and I transmit 7 bytes then my code will detect a full RX Buffer and go to the endrx_isr() with the first 6 bytes. Eventually, the 7th byte will replace the first byte in the RX buffer after going back to the uarte_nrfx_rx_enable() function from the callback. If I want to ignore the transmission altogether how should I go about it? The code will detect the tx and rx len to be 6 and I have no idea how the 7th byte is actually loaded.

Thanks,

Spencer

Parents
  • Hi Spencer

    Have you looked into using the UART async driver?

    Then you can define a timeout on the receiver, and get a callback from the driver as soon as either one or the buffers have filled up, or the timeout period has passed. 

    I made a small example showing how to implement this here.

    In your case this should lead to a first interrupt with a length of 6 bytes, followed by another interrupt some time later with the length of 1 containing the last byte. 

    Best regards
    Torbjørn 

  • Hi Torbjørn,

    Following your example it does seem to work the first time I try to send more than the buffer size. However, the next time I send 7 bytes again it would start putting them in wrong locations. Is there a way i'd be able to count the evt->data rx/tx buf length before it gets manipulated in the callbacks? I think it'd be easier overall if I could just detect if say 7 bytes were received and to ignore them all and wait for a new set of bytes.

    Thanks,

    Spencer

Reply
  • Hi Torbjørn,

    Following your example it does seem to work the first time I try to send more than the buffer size. However, the next time I send 7 bytes again it would start putting them in wrong locations. Is there a way i'd be able to count the evt->data rx/tx buf length before it gets manipulated in the callbacks? I think it'd be easier overall if I could just detect if say 7 bytes were received and to ignore them all and wait for a new set of bytes.

    Thanks,

    Spencer

Children
  • Hi Spencer

    What do you mean by putting them in the wrong locations? 

    Are the bytes printed in the while loop not the same as the bytes that you expect to receive?

    The incoming bytes will be placed at different offsets in the UART RX buffers, that is true, but you can compile them as you wish once you receive them. 

    If you are implementing some form of message based UART communication I would strongly recommend using a header byte or similar to mark the start of a new message. 

    Best regards
    Torbjørn

  • For instance, if I send [1,2,3,4,5,6,7] and the buffer is [1,2,3,4,5,6] after I send another the first frame. If i send a frame of data of [1,2,3,4,5,6,7] after the buffer would then become [7,2,3,4,5,6].

    We do have a header byte to mark the beginning of a new message but this would have just been an extra form of validation. It may be more headache than it is worth but thanks for the help anyways!

  • Hi Spencer

    SpencerEtn said:
    If i send a frame of data of [1,2,3,4,5,6,7] after the buffer would then become [7,2,3,4,5,6].

    You mean the next one would be [7,1,2,3,4,5] right?

    Otherwise it looks like you have lost a byte, which would definitely be a problem. 

    Do you know how much of a delay there would be between each transaction?

    If the delay is relatively large you could always set a shorter timeout, so that the UART RX times out between each message. 
    This doesn't make the buffers align like you request, but it would ensure that receive a complete message before the next one starts. 

    Message one would be received as: [1,2,3,4,5,6] followed by [7] 

    Then the second message would be [1,2,3,4,5] (with offset 1) followed by [6,7]

    Third message [1,2,3,4] (offset 2) followed by [5,6,7]

    And so on...

    SpencerEtn said:
    It may be more headache than it is worth but thanks for the help anyways!

    I think so, yes. 

    It is also risky to trust too much in the exact behavior of the UART driver, as this might change between SDK versions, or depending on which chip you are using. 

    Best regards
    Torbjørn

Related