• Locked Locked
  • Replies 8 replies
  • Subscribers 31 subscribers
  • Views 1683 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.

uDMA techniques for larger transfers (than 1024 elements) in TIVA

PAk
Mastermind 7025 points


Hello again.

I am improving performance of my programs so I am intensively using uDMA as much as I can. Everything is easy and smooth is the number of elements is 1024 or less, but if the buffer of data is larger, then some doubts appear.

I would like to know how to confront different situations when the amount of data elements is higher than the maximum of uDMA (1024 elements).

For example, I can think of some periodic data to be sent that is always the same size, so I could count interrupts when enabling DMA.

Or a variable structure of data, so I may make two (or more) calls of different length starting in different elements of an array, for instance a 2248 element array, calling udma with src address at &TX_data[0] (length 1024) and, &TX_data[1024] (length 1024) and &TX_data[2048](length 200). Not sure if this one would work calling the three instance s in a function one below another, or link them inside the dma interrupt.

Could Scatter-Gather or pingpong modes solve this situations? How?

Which is a recommended technique?

Thank you very much again.

  • Mastermind 7025 points

    Hasn't anybody found this topic interesting??

    Regards

  • Guru 117855 points

    Might you "sell" your request better - by documenting the "performance improvement" you note?  

    Suspect this would raise interest - encourage response - as others would seek to similarly benefit.

    BTW  ~48 hour "turn-time" may show some impatience...  (you are seeking a considered opinion...)

  • in reply to cb1_mobile
    Mastermind 7025 points

    cb1_mobile said:

    Might you "sell" your request better - by documenting the "performance improvement" you note?  

    Suspect this would raise interest - encourage response - as others would seek to similarly benefit.

    If selling is the thing, nothing better than an image, so I can show you the miracles of a uDMA transfer on a UART port against not using it.  As you can spot, the red line (CPU time busy between processing blocks) is shrunk by almost 50%, from a 12ms time period to a 6ms one.

    A precious time to accomplish the double of matters or just saving energy.

     

     

    So nice, I think I cannot live without it anymore!!!

    cb1_mobile said:

    BTW  ~48 hour "turn-time" may show some impatience...  (you are seeking a considered opinion...)

    The sooner the better, but that is true, short time. However, by the structure of the website, some interesting posts get lost easily after a few days.
  • in reply to PAk
    Guru 117855 points

    PAk SY said:
    If selling is the thing

    There is never any doubt my young friend - "Selling is always the thing."

    Specifics you seek likely extend beyond the bounds of vendor's device - thus while natural for you to seek - recall, "Location, location, location."  (i.e. more focused SW-centric site visitors - may find your SW issue more "interesting" ...)

    Starting @ Section 8.2 - our LX4F manual - describes and guides the uDMA usage and mechanisms.  (suspect that you know & have long visited this area)  Academic press as well as on-line venues can provide the added detail you appear to seek.  And - when all else fails - clever experimentation can "pry out" necessary facts, relationships & mechanisms - which likely are outside the level of detail w/in any vendor's MCU write-up...  (some time-crunch pressure upon manual tech writers...)

  • in reply to cb1_mobile
    Mastermind 7025 points

    cb1_mobile said:

    There is never any doubt my young friend - "Selling is always the thing."

    Specifics you seek likely extend beyond the bounds of vendor's device - thus while natural for you to seek - recall, "Location, location, location."  (i.e. more focused SW-centric site visitors - may find your SW issue more "interesting" ...)

    What is life nowadays but SW and a little bit of HW?? 

    cb1_mobile said:
    Starting @ Section 8.2 - our LX4F manual - describes and guides the uDMA usage and mechanisms.  (suspect that you know & have long visited this area)  Academic press as well as on-line venues can provide the added detail you appear to seek.  And - when all else fails - clever experimentation can "pry out" necessary facts, relationships & mechanisms - which likely are outside the level of detail w/in any vendor's MCU write-up...  (some time-crunch pressure upon manual tech writers...)

    Actually we are working with a micro-DMA (uDMA), not a full DMA, so this is why I am asking here. I am pretty sure, some great stellaris-tiva artists have fought against its limitation and have defeated it with the propper techniques. 

    Why generate your own electricity when it is easy to get it from the plug and affordable? Sharing is growing faster and....better.

    Regards

  • in reply to PAk
    Mastermind 7025 points

    Bump...

    sure somebody is interested!!

  • TI__Genius 17225 points

    Pak,

    EuphonistiHack created a audio freq analyzer he allows the users to set sample frequency and several other variables.  As a consequence he has to handle variable size uDMA transfers from the ADC to a buffer.  This includes transfers from well below 1024 bytes to at least 2048 and perhaps bigger.

    http://euphonistihack.blogspot.com/

    Not sure if it exactly meets your requirement but is probably worth a look.  The code is open source.

    Aside from this i am not aware of implementations that address your desire.

    Dexter

  • in reply to Stellaris Dexter
    Mastermind 7025 points

    Stellaris Dexter said:

    Pak,

    EuphonistiHack created a audio freq analyzer he allows the users to set sample frequency and several other variables.  As a consequence he has to handle variable size uDMA transfers from the ADC to a buffer.  This includes transfers from well below 1024 bytes to at least 2048 and perhaps bigger.

    http://euphonistihack.blogspot.com/

    Not sure if it exactly meets your requirement but is probably worth a look.  The code is open source.

    Aside from this i am not aware of implementations that address your desire.

    Dexter

    Thank you Dexter, actually, I already checked this code (and used some pieces of it in my project).

    I was thinking in something more generic with the uDMA, and which most programmers could use, i.e. how to transfer long variable messages via an UART (and uDMA), or how to read long SPIs frames......

    Regards