• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 240 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TM4C1230H6PM: Question about UART RX DMA with variable size of data being received

Terence Darwen
Intellectual 320 points
Part Number: TM4C1230H6PM

Tool/software:

Hi, I'm using the TM4C1230H6PM to receive UART data (among other things).  In my use case, I randomly might only receive a few bytes of data within a couple of seconds.  In other cases, I could be sent over 500 bytes of data all in one go.

The problem I have is similar to this question I asked last year that so kindly answered.  However, it's slightly different in that this time around I can control the sender side as well as the receiver.

On the Tiva side (the receiver) it seems ping-pong mode is the best DMA mode to use for my case, the problem I have is what size to chose for my DMA buffers.

If I chose a smaller size, say 64 bytes, if a higher priority interrupt is being serviced when I receive 500 bytes of data it's possible both my primary and alternate buffers will fill before I can service the DMA interrupt.

If I chose a larger buffer, say 512 bytes, I will have to send a full 512 bytes every time I want to process the 3 bytes of data as quick as possible.  It seems like a huge waste, making the sender send 512 bytes when I it only needs to actually send 3 bytes.

Am I missing something?  Is there a better approach I'm not thinking of?

  • 0
    TI__Guru**** 191356 points
    Terence Darwen said:

    If I chose a smaller size, say 64 bytes, if a higher priority interrupt is being serviced when I receive 500 bytes of data it's possible both my primary and alternate buffers will fill before I can service the DMA interrupt.

    If I chose a larger buffer, say 512 bytes, I will have to send a full 512 bytes every time I want to process the 3 bytes of data as quick as possible.  It seems like a huge waste, making the sender send 512 bytes when I it only needs to actually send 3 bytes.

    Hi Terence,

      Since uDMA is most important to you in terms of priority, why don't you simply just bump the uDMA interrupt priority over other interrupts. The interrupt priority is programmable. Please refer to the below API and example. Increasing your uDMA priority will ensure it does not get preempted by other interrupts. 

  • 0 in reply to Charles Tsai
    Intellectual 320 points

    Hi Charles, thanks for the reply.  Increasing the interrupt priority is certainly a possibility, and I'm willing to try that. 

    A couple of concerns with doing that is that:

    1. I use the SysTick interrupt to keep track of system up-time and would prefer to not delay that.
    2. I also have A LOT of frequent I2C communication happening with many peripherals that I don't want to be interrupted.  I can possibly work around that though.

    Mostly, the point of my question was that I just wanted to make sure I wasn't missing a uDMA feature that would work better in my case than ping pong mode.  Do you agree that there is not really a better mode or uDMA technique that I could be using?

  • 0 in reply to Terence Darwen
    TI__Guru**** 191356 points
    Terence Darwen said:
    Mostly, the point of my question was that I just wanted to make sure I wasn't missing a uDMA feature that would work better in my case than ping pong mode.  Do you agree that there is not really a better mode or uDMA technique that I could be using?

    Hi Terence,

      As I mentioned in the prior post, there is no visibility to the internal working of the uDMA other than some status registers that indicate the completion of the transfers. Bear in mind that uDMA does not know your incoming data can be variable-length. It simply interrupts for completion when the programmable transfer count is transferred. In your specific situation,  I will also suggest you devise a protocol scheme in your payload that would indicate the number of transfers to be expected. For example, you can always add a header byte that indicates the length of the transfer.  For example, let's suppose you are going to receive 500 bytes of data. When you get a uDMA interrupt after 64 bytes are transferred, you would know that there are still 500-64=436 bytes remaining. In order for the remaining bytes not to be interrupted by I2C or other interrupts, you could disable the interrupts for others until you receive and process the 500 bytes. This is just an idea and I hope you can come up with better schemes. 

  • 0 in reply to Charles Tsai
    Intellectual 320 points

    Thanks again, Charles.  Quality answers as always.  Yes, I have been toying around with some ideas for a more intelligent communication protocol as you suggest.  I think between this and increasing interrupt priority as you suggested I should be able to find a reasonable solution.

    As always, I much appreciate your help.