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.

Planning EDMA resource usage to avoid bottlenecks



Hi,

I'm using the C6747. The McASP 0 will receive and send data @ 48 kHz. These data streams are continuous. I also want to use a UART Tx to send packets of data. These packets will contain up to 350 bytes @ 115200 kbps and sent at every 35 to 40 ms (the UART will be used about 75% of the time).

The EDMA has two transfer controllers (TC) in this chip. I was thinking of associating the McASP 0 Rx with queue/TC0 and McASP 0 Tx with queue/TC1. Both of these transfers would use A-synchronization. Furthermore, I plan on using linked packets for both Rx and Tx to write/read to the internal input/output buffers in SRAM since the streams are continuous. Hence, the "completion rate" depends on buffer size (ACNT*BCNT*CCNT) and in my case these are relatively large. The completion interrupts would be well spaced out.

To minimize CPU intervention, I also want to use the EDMA to service the UART Tx.

I read through many EDMA-related documents and my understanding is that since I'm occupying both TC0 and TC1 continuously, any other transfer request that has a lengthy duration (the UART in my case) will cause an overrun/underrun of the McASP Rx or Tx (depending on which queue is used for the UART). When the McASP Rx/Tx terminates, the linked McASP transfer requests will be queued but since the UART transfer request is already in the queue, the UART transfer request will be sent to the TC before thereby stalling the next McASP transfer request. Are my observations exact?

To avoid this situation, I think I need to split my transfers into small packets thereby augmenting the completion rate and allowing the McASP Rx, McASP Tx and UART Tx transfer requests to be interleaved. I know that this will drastically reduce the EDMA utilization percentage because of overhead but do I have a choice? If I don't want to have McASP and UART overruns/underruns, I was thinking of doing single-element transfers (1 data word for the McASP and 1 byte for the UART) where BCNT=CCNT=1. The only way I think I can do this is to modify the next transfer request by updating the DMA channel's link PaRAM destination/source address registers to point to the next buffer locations (otherwise I will always read/write at the buffer base address). This would have to be done in the transfer completion interrupt. Is this the way it has to be done to make it work?

By the way, maybe it would be best to use queue 0 for single-word McASP Rx and Tx transfers and use the other queue solely for UART Tx thereby letting the EDMA take care of the whole packet instead of operating on a single-byte basis. What to you think?

Best regards,

SC

  • SC,

    Honestly, I had to read the EDMA3 User's Guide cover to cover twice and then study individual sections several times before I started to understand its operation. I also had the privilege of being nearby to some of the experts, but this was many years ago. You have come up to speed much more quickly than I did.

    But some of the fundamental concepts of the EDMA3 peripheral still need to be studied to understand how the interactions will occur.

    scoutu75 said:
    I read through many EDMA-related documents and my understanding is that since I'm occupying both TC0 and TC1 continuously, any other transfer request that has a lengthy duration (the UART in my case) will cause an overrun/underrun of the McASP Rx or Tx (depending on which queue is used for the UART).

    Your understanding is not correct. If you will point out the specific wording that led you to this concern, I will be glad to explain why it does not apply to your situation.

    Although it can be good practice to plan ahead to avoid problems, it is also good practice to build your system and measure the performance before being concerned about whether the system needs to be optimized.

    In your case, put all of these slow, non-bursting peripherals on the same Queue/TC. Then use the other TC for other DMA and QDMA operations that may be bursty, such as copying buffers from SDRAM to L2 and L2 to SDRAM.

    I will point you to the EDMA3 User's Guide, Section 2.1.1 "EDMA3 Channel Controller (EDMA3CC)", to understand the relationship between the events from the peripherals and the size of the Transfer Request (TR) that is sent to the Queue for each event. I will also point you to Section 2.2.1 "A-Synchronized Transfers" to the first paragraph that also explains the amount of data requested in each TR for an A-Sync event.

    There is a set of training videos (slides + audio) for the C6474 here. The EDMA3/QDMA/IDMA module presents features and operation that is common to any EDMA3 implementation, although it will discuss a few specifics about the C6474 that will not apply for the C6747. It may be too basic for you, but I wanted to offer it as another choice for your study.

    Regards,
    RandyP

     

    If you need more help, please reply back. If this answers the question, please click  Verify Answer  , below.

  • Hi RandyP,

    I found a section in the EDMA datasheet that I think describes what I'm concerned about. Please read the section "3.4.5.2 Breaking Up Large Transfers with Intermediate Chaining" in SPRUFL1C.

    The example in this section talks about a large memory transfer using A synchronization. But in my case, I'm servicing McASP Rx and Tx events so I don't think I can use this approach of "chaining to myself" to force the synchronization of the next data packet because I must use the McASP events to do this.

    In light of this, please let me know if I too must divide my continuous McASP to/from memory transfers in small or individual packets. To recap, I have a 16kB input buffer and a 80kB output buffer (two large Transfer Requests) and I want to use the EDMA to send packets via the UART (~75% occupancy).

    Regards,

    Stephane

  • Stephane,

    Please go through the training video on the EDMA. In my previous post, I gave you a link to the full video set of which EDMA is one of that video set. This will help you understand the nature of Transfer Requests. Then, it will be easier to read the EDAM3 User's Guide again to understand more specific points.

    You do not have any large transfers. The training video may help you understand this.

    Regards,
    RandyP