[SOLVED] Feature Request RTT: SEGGER_RTT_GetAvailWriteSpace

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • [SOLVED] Feature Request RTT: SEGGER_RTT_GetAvailWriteSpace

    Hi!

    We're using RTT to write out a binary packet log file (e.g. like .pcap). To avoid using a special outgoing packet buffer and extra memcpy calls, we first write the packet header and then the packet itself with SEGGER_RTT_Write. If the RTT buffer gets full after writing the header and the RTT mode is set to SEGGER_RTT_MODE_NO_BLOCK_SKIP, the packet can not get written and the log gets corrupted.

    Would it be possible to add a SEGGER_RTT_GetAvailWriteSpace(bufferIndex) or SEGGER_RTT_CanWriteBytes(bufferIndex, numBytes)?

    Here's a draft: github.com/bluekitchen/btstack…639c0a9cb764edb04e3d5e483

    I'm aware that this would only works without multi-threading or when using RTT from ISRs.

    Thanks for consideration
    Matthias
  • Hello Matthias,

    Thank you for your feedback.
    We discussed this internally and will add a API call that returns number of free space in the buffer.
    This should be available with the next J-Link release.

    But keep in mind that the buffer will be free in most cases after the callback _GetAvailWriteSpace has been executed in SEGGER_RTT_WRITE due to the speed of J-Link and asynchronous nature of RTT as the callback will only return the current buffer state while in the background J-Link continues grabbing the data.

    Another way would be to use RTT in TRIM mode and use the return value from SEGGER_RTT_Write(). Then try to resend the difference of requested bytes and written bytes again.

    Best regards,
    Nino
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • Thanks, that's Awesome!

    Yes, I think I'm aware of the limitations and the async nature. To me, it looks like RTT TRIM + retry is similar to NO_SKIP_BLOCK, if the retry happens right after the write (if there's another queue, the retry could happen later, but then, a larger RTT buffer could be used ).

    Best regards
    Matthias