Clarification of the GPIO byte wide DMA capability of the TM4C123

Hello Ayemk,

Yes, that is correct. But then you have GPIO Ports A-Q. If you want to write the 8 pins of GPIO Port A, then you can use The DMA Trigger from another port-pin to do so.

Regards

Amit

Amit

Thank you for your quick response. Could you please expand on your answer.

The  confusion relates to the binding of a trigger pin to a specific GPIO channel.  For example, if Port E pin 3 is to be used to trigger read / write DMA data on Port A, then it would be defined GPIODMATriggerEnable(Port E, Pin 3) . How then is this trigger defined to apply to the Port A DMA channel and not some other channel, presuming that a number of DMA channels can be defined and enabled concurrently ?

Apologies in advance if something obvious has been overlooked.

Regards

Ayemk

Hello Ayemk,

Let us assume that the Port A's 8-pins are in output mode and that Port E Pin-3 is being used as a dma trigger. Now obviously the Port A will not generate the DMA trigger. The DMA knows only 3 things: The source address, the destination address and how to send and how much to send.

In the Source the address would be say a SRAM buffer and in the destination the address would GPIO Port A Data Register. So whenever the PE3 pin generates a DMA trigger, the DMA would send the data from SRAM buffer to Port A. The DMA is not restricted to send data to the peripheral that caused the DMA request and there is no such binding.

I hope it is now clear

Regards

Amit

Greetings Amit & Ayemk,

First off - kudos to you two - thoughtful, well described/documented post by Ayemk and nice follow-on by Amit.  (as most always!)

However - I think that Ayemk was suggesting the (likely) requirement of accommodating two, similar DMA transfers - involving 2 different GPIO 8 bit output transfers - and triggered by 2 different (separate) independent port pin triggers!

Then what?  Exactly as Ayemk so cleverly noted - there appears to be NO BINDING between trigger & DMA target!  How then does the MCU know which trigger routes to which targeted DMA?

I note that the gpio Register in question (GPIO_O_DMACTL) states "pin" (singular) thus perhaps only ONE trigger is allowed - and should this prove the case - the description language fails miserably to signal such - and has contributed to Ayemk's frustration...  (i.e. if you like your doctor SINGLE source trigger - you can keep him/her/it...)

Hello Ayemk,

Just to make sure, if Port E is used to trigger a dma request for transfer of data to/from GPIO Port A, then Port A DMA reuqest in not to be used.

Hello cb1_mobile

As always, appreciate your perspective on sometimes missing out further details. I was reading the post as Trigger from one GPIO causing DMA transfer to another GPIO. But to add to your second point "How then does the MCU know which trigger routes to which targeted DMA": There is only one DMA and just like a SW channel mode where MCU sets up the DMA for transfer between mem-2-mem, mem-2-per, per-2-mem r per-2-per, the Peripheral Triggered is the "go" condition for the DMA to do a transfer as specified in the channel descriptor.

Regards

Amit

And - in the effort to answer Ayemk's dual (or beyond) 8 bit parallel transfer under DMA - and if it proves true that only a single bit specifier is allowed w/in "GPIO_O_DMACTL" (such fact not yet in evidence) may I suggest that the simple, "Reload of "GPIO_O_DMACTL" will - at minimum - enable a different trigger source.

Alas - my idea crashes/burns (rather severely) as there remains (at least to my feeble mind) no means to "bind/link" that new trigger to, "one of N" DMA transfers.  Suspect that both the trigger and DMA set-up/config must be reprogrammed - to achieve Ayemk's goal.  (I'm looking @ competing M4 to see how (or if) they manage this neat requirement...)

Hi Amit,

Thank you - as always my intent was to some way/how "aid" in the address/resolution of poster's issue.  (and - like you - thought this a very "kool" subject)

Now this from my (RIP LX4F manual - re DMA): "Each peripheral function that is supported has a dedicated channel on the μDMA controller that can be configured independently."  I improperly used DMA when I meant "DMA Channel."  Now if it is possible to employ multiple such DMA Channels (admittedly not at the same time) then my point (inability to bind triggers to different DMA Channels) may remain valid.

Here's the channel map for our LX4F MCU:

Now if I read (and understand) the uDMA operation - channel numbers 6 & 7 enable an 8 bit port output via gpios C & D.  And - by alternate use (perhaps even ping-pong) the limitation of an 8 bit (only) port  transfer is mitigated.  (note that other ARM MCUs enable 16 bit, some even wider, data transfers) 

To further clarify - can beyond a single uDMA channel be transferred - without constant set-up/config of the uDMA structure?  If this is so then - are we not "impaled by the dilemma" Ayemk has identified and I have attempted to further detail?  (i.e. there appears no way to bind/link the uDMA trigger to beyond one uDMA channel!)

The uDMA feature is enhanced if beyond a single, 8 bit port transfer can be accommodated.  This is - if my "read of Ayemk proves correct" - what is of most value to both he & my small group.  (and likely multiple others...)

As always - thanks for your keenness & assistance to so many (especially moi) here.  (with certain departures - you are a significant addition to this "top cabin" ARM forum...)

Hello cb1_mobile.

Channel 6 and 7 enable the trigger to be accepted from GPIO C and D. Based on the trigger the uDMA can do any of the mentioned transfer type like basic, ping-pong or peripheral scatter gather, The uDMA has a single active thread and at any given time only one trigger can own the thread.

If there are multiple triggers then they get prioritized to this single thread.

Now if the requirement comes to setting up the uDMA indefinitely, once enabled then a mix of Peripheral Scatter Gather, where the last task can be used to set up the entire structure.

When it comes to GPIO, TM4C's are restricted to 8-bit port only and it cannot be parallel clubbed as the uDMA employs a single active thread which will access one peripheral at a time.

Regards

Amit

Amit,

Thank you - your caring & detail duly memorialized and much appreciated.

May I ask for bit more detail (yes - I'm starting to hate myself, too) re: AA: "If there are multiple triggers then they get prioritized to this single thread."

By my read of the uDMA Control Register - it remains unclear "if" multiple triggers may be employed.  (this was the thrust of Ayemk's post - iirc)  And - if they are allowed - must these (multiple) triggers be constrained to a single, gpio port?  To achieve multiple triggers - emanating from different gpio ports - may we employ multiple calls to the uDMA Reg. - each targeting a different gpio port?

Look now please at Ayemk's 2nd post, " How then is this trigger defined to apply to the Port A DMA channel and not some other channel, presuming that a number of DMA channels can be defined and enabled concurrently ?  It appears that Ayemk & my small group have fallen into this identical, "rabbit hole?"  (thus there is no hijack - certainly not an intentional one - of this thread)

The intent (which I believe reasonable, of value) is to extend the uDMA capability to beyond a (bit passe) 8 bit transfer.  (those days long gone - mais oui?)  The use of uDMA to achieve such (beyond 8 bit) data transfers - effectively "in the background - as the MCU manual states" adds greatly to the appeal of your MCUs. 

Might you comment upon this (transfer of beyond 8 bits, under uDMAcapability) via your TM4C series? 

And - per Ayemk's post, "...May a number of DMA channels be defined and enabled concurrently ?"  I (and perhaps he too) remain unclear upon this specific capability.  Again thank you.

Hello cb1_mobile,

Sometimes familiarity with the MCU makes me presume. I hope I am able to convey the information better with every post :-)

There are 32-channels of the uDMA which can be used to generate 32 triggers (some GPIO, sone mon-GPIO). Each trigger is just like an interrupt (if I may take as an example) requesting the uDMA to perform certain task as per the programmed control structure. The control structure can be written to do a data transfer from one address to another. So you are right in saying that different trigger can call the uDMA to target a different GPIO Port.

As for the 2nd post, the trigger is the uDMA request coming from the respective peripheral as per the uDMA channel assignment table. So once the channel mux is set then the uDMA trigger/request allows the correct control structure to be used to perform the transfer.

The 8-bit is w.r.t the GPIO. The uDMA can do 16-bit or 32-bit transfers as well. E.g. in TM4C129 the EPI has a 32-bit data write capability, while on TM4C123 and TM4C129 the SSI can be have 16-bit transfer capability. In the specific case of the GPIO, when doing a 16-bit or a 32-bit the only side-effect that will be seen is that the upper 8-bit or 24-bit will never be refected on the GPIO as the data width (DATA register of GPIO) allows 8-bits to 8-pins.

Also channels can be enabled concurrently. Only when the uDMA trigger/request is generated does the channel operate. Even if simultaneously all the enabled channel generate a trigger, then uDMA goes in the order of channel number to service each of the request.

Regards

Amit

Amit Ashara said:

Sometimes familiarity with the MCU makes me presume.

And - my friend - you are not alone in that.  (should see me - when w/our clients...)  One tends to forget what - thru nearness - we presume to be basic...  And - unfortunately - others - w/out that proximity/nearness - may not share that keenness.  (nor motivation)

Have a biz appointment now - never mean to delay response - with your indulgence I'll be back w/proper detail later this day.  (i.e. pardonnez-moi)

Again - we all owe you much for your skill, work ethic & caring.  (appears just this reporter & you - active much today)

Hi again Amit,

Again thanks your care & detail.  Have read/re-read the uDMA Chapter and past SW-DRL-UG9453 (last official one for our LX4F devices in production)  Suspect you'll agree that uDMA is one of the more complex features contained w/in past LX4F & newer TM4C - yet not one uDMA example appears (directly) w/in StellarisWare\examples\peripherals and the sole example w/in our added read/effort: SW-DRL-UG is somewhat generic and covers just one specific application - leaving the more complex ones, silent/unaddressed... 

Clearly - none of this is your doing - but too brief/imprecise written documentation leads directly to posts such as this one - and while you've made great effort & answered in detail - only a minority will wander here - and benefit from this thread.  (thus - an appeal for more complete tech. write-up - at least covering more than the simplest uDMA application - w/in both MCU manuals and latest/greatest Peripheral Driver lib.)

Returning to Ayemk's specific question (uDMA triggered by an input upon a select gpio port pin) - would you be so good as to list several "real world situations" - where the non-MCU device is "smart enough" - to be able to launch the MCU's specific, uDMA operation?  Perhaps I can somewhat assist - our group wanted to expand the ability of the "lesser" (i.e. non TM4C129s) to be able to output beyond 8 bits (say 16) to a non-intelligent, external component.  (perhaps a memory chip)  Without uDMA - this task would absorb too much MCU-time - and the cost/size of the TM4C129 may exceed our client's target budget.  Thus - we seek to enable a, "plain vanilla" TM4C to output 16 bit data (presently in MCU Sram) to an external memory/other - with minimum of penalty to all other MCU operations.  This does not seem like a good use case for a gpio-request - most memories (to my knowledge) do not have the intelligence to generate the "serve me" gpio pin signal request.  (MCU to MCU transfers seem obvious - but a minority use case)  So can you list several use-cases for such external device -gpio triggered uDMA launch requests - as first listed by Ayemk?

My hope is that this writing opens up more applications for your "non-Cadillac" devices.  Restricting wide transfers to few devices may not prove the optimal means to boost MCU Sales.  Efficient harnessing of the existing uDMA capability - which I believe proves difficult/incomplete due to current description/explanation brevity/imprecision - may provide the always sought, "win-win" for both MCU producer and we ever hopeful, user/specifiers...

Thanks again Amit for your time/attention.

Hello cb1_mobile,

For TM4C123, it is right now not possible to output 16-bit data either using CM4 or uDMA as none of the GPIO's support more than 8-bit. However using Peripheral Scatter Gather (PSG) uDMA can be made to do so by writing 8-bit data to one GPIO Port, then to the next GPIO Port and so on and the clock/control for any external device be done as the last but one task in the PSG. The last task of the PSG then can re-init the Control Structure.

On application side, we have quite a few devices like sensors and data acquistion devices (ADC's) which give a READY signal, that can be hooked up to a GPIO to generate a dma request for transfer using SSI or I2C.

Regards

Amit

Amit Ashara said:

On application side, we have quite a few devices like sensors and data acquistion devices (ADC's) which give a READY signal, that can be hooked up to a GPIO

Hi Amit,

That (various sensors, external (higher res.) ADCs with in-built "Ready" capability) makes good sense - I missed the fact that each of those external devices must first (likely) be initialized/config'ed by the MCU - and then the external device's "Ready" should be, "Almost, Good for Gov't work."  *** ("almost" - due to the chance that Ready will be asserted prior to the uDMA transfer completing - possibly complicating/confounding - and/or the external device's potential, "handshake signal requirement" to, "clear that Ready - once asserted.)"  (clients/we have encountered this - perhaps you wish to comment...)

To my mind - use of a well chosen, "Timer interval Request" to bring about the byte (or beyond) "gpio data transfer" (possibly in concert w/the external "Ready") may provide a more controlled/managed, uDMA-based transfer.

Our group (and several clients) persist in the belief that the uDMA write-up (likely the last addition to LX4F, TM4C Data Manuals & Peripheral Library Guides) really is in need of greater (i.e. "some") detailing.  A simple, single example - is most unlikely to properly convey all of the nuance of this sophisticated MCU peripheral - surely you must agree.  And - as earlier stated - your detailed effort in this thread would prove far more valuable if incorporated in the far more appropriate MCU Data Manuals and Peripheral Library Guide.  (with multiple, specific examples - well beyond the brief, basic one - currently the sole resident...)

Thanks for your patience, effort & insider knowledge.  Do note that I most always strive to provide workable alternatives (suggestions) to existing, "Gov't Work" - and that items of broad, general use to your user base (not just, "me, me, me" are, "usual targets/victims..."  Your efforts are appreciated...

To Amit and cb1_mobile

Many thanks for the (surprising) amount of thought and discussion that my original post initiated. Supporting cb1_mobile's view for additional documentation, I believe that there is more than enough hidden detail, complexity and capability to justify a specific Application Note for TM4C GPIO DMA. The 16 bit configuration suggestion is a good example of why this document is needed.

In summary , I am left with two outstanding requirements, to fully answer my original question:

1. A detailed explanation of an example such as: Port D is set up for GPIO read into SRAM via DMA on an external clock trigger on Port E Pin3 whilst Port A is set up for DMA write from SRAM via Port C Pin 2 (e.g. via an external Ready trigger).

It is my understanding there are no conflicts in concurrently specifying the DMA configurations, the enable statuses and the GPIO DMA trigger capabilities. I also understand that if there is contention, the lower ranked channel (Port A in this instance), would be prioritized.

I specifically do not understand how, in this use case, the two different GPIO DMA trigger bindings can be properly associated. 

2. A simple, proven working example, with full configuration steps, of a byte wide read into RAM (Port D) from a trigger pin on another port (Port E). 

The original reason for the initial post was that I was not able to configure this to operate under DMA, although there were no problems in either an interrupt driven read or a DMA read of the same port as the DMA trigger pin. Despite much searching I was not able to find an appropriate example.

Best Regards

Ayemk

ayemk said:

I believe that there is more than enough hidden detail, complexity and capability to justify a specific Application Note for TM4C GPIO DMA.

May I commend you again Ayemk - for illuminating this topic initially - and for the superb crafting of language & cadence - highlighted above?  Pity that humble outsiders must glimpse the emperor - then slam shut our eyes - when his state of dress fails to fully/properly camouflage those unwelcome, "goods."  (i.e. the uDMA write-up was clearly (ok, likely) a "rush job" - perhaps justified "back then" - but seriously begging for an adequate, caring, far more appropriate (i.e. some detail) effort now.)  (i.e. Q2 - 2014) 

Ayemk - know that your keen analysis cast a bright spotlight on this clear deficiency - which perhaps has been too long (dare we say, ducked?) - and really requires a more thoughtful, precision written description...

Again - valued assistance by Amit - but our combined efforts here in no way reduce (or remove) the need for a proper write-up in the "usual suspect" documentation tree...  (not this, "find if you're lucky" - over-grown, forum island...)

Hello Ayemk and cb1_mobile.

Point duly noted. the uDMA needs more explanation and may be an application note can be done in Q2-2014.

For Ayemk's point, there are no conflicts in setting up the DMA configuration, status and Trigger and as well stated the lower channel get's priority if both triggers come at the same time. Consider it to be like 2 interrupts to the CPU coming from the GPIO. The ISR for one GPIO can be used to toggle a GPIO in other Port. It is the same way for DMA which is offloading this from CPU, albeit, it is not as smart as the CPU in doing  logical operations and compares, etc.

Regards

Amit

Amit Ashara said:

Consider it to be like 2 interrupts to the CPU coming from the GPIO. The ISR for one GPIO can be used to toggle a GPIO in other Port.   It is the same way for DMA

My belief - your thoughtful & imaginative example (highlighted above) would spectacularly enhance the explanation & necessary detailing of this most helpful - yet complex - uDMA MCU capability.  Bravo to you Amit for your considered & inventive presentation of an involved subject - you've "teased out" better understanding by linking the uDMA's "methods-madness" to a more popular - and better understood - MCU capability.  (i.e. interrupts)

Low cost launchpads do sell boards - yet inadequacy of description is not seen as a, "recognized Sales Enhancement" vehicle.  I'd go so far as to suggest that your unrushed/caring participation in the necessary clarification of the existing, technical documentation tree likely will result in your/TI others "escape" from the drudgery of very much repeated time/effort - addressing issues directly caused by "lite" documentation.  (i.e. perhaps the long lingering NMI issue especially well illustrates...)

Amit

Thank you once again for your great patience. However, with the
example created ,containing 2 different GPIO triggers - Port E pin 3 and
Port C pin 2 my question stands -for each of these pin triggers, which
DMA channel transfer would each of them initiate??

There seems to be no way to bind a Port C trigger to a Port A transfer
and likewise Port E trigger for a Port D transfer: -what am I missing
here?

It seems that once a port -pin has been definedas  a DMA trigger (and presumably also once the GPIO DMA channel has been enabled) the interrupts generated by this pin will be suppressed

by the DMA controller until the full DMA transfer has been completed
-so that there would be no accessible logic to decide which channel
(in this case either Port A or Port D) should be serviced. I would
really appreciate the configuration script for the scenario(s) that I
have proposed (examples for a future AppNote ??)

Regards
Ayemk

Hello Ayemk,

1. Port E will initiate the DMA Channel for Port E and Port C will do likewise

2. On the DMA trigger from Port E the DMA control structure has to be written such that Source Address of the Control Structure is the location from where you have to copy data (could be SRAM, etc), Destination Address has to be Port D Data Register at offset 0x3FC of the Port D base address. Similarly for the Port C.

3. Yes, when the DMA is enabled, the interrupt generation capability of the Source of the DMA is suppressed till the DMA transfer is not completed. However when the DMA Channel completes, the Interrupt for DMA channel will come on the Interrupt Vector for the corresponding DMA source, in this case either Port E or Port C ISR will be remapped for DMA completion. So indirectly you would know which end port was serviced.

4. Will add this as an app note.

Regards

Amit

Amit Ashara said:

Will add this as an app note.

Might you advise just where these App Notes are now located - and just how they are best "searched?"  TI site is so massive - so many "nooks/crannies" - under long past LMI regime (admittedly far smaller/simpler site) APP Notes were easy to find - almost "jumped out" for easy search/find. 

Such "ease of use" seems to benefit from some description.  (again - regularity of your use may "mask" the lesser knowledge/precise awareness of your (necessarily) "broader focused" (less TI specific) user/clients...)

Amit

Thank you once again. BTW I think there is a typo in point 1 where it (I hope) should read: 

"Port E will initiate the DMA Channel for Port A and Port C will do likewise"

and in point 2   "Similarly for the Port A"

Let me now restate now my understanding of TM4C GPIO DMA capability as explained by you.

1. For non GPIO DMA transfers, it can support a number of simultaneous DMA configurations (e.g SRAM- UART - Timer -SSI-ADC-USB, etc) as long as the triggers can be separately and uniquely defined for each transfer pair, and where there is trigger timing contention, the highest priority channel transfer will proceed.

2. In the GPIO case however, despite the fact that multiple to-from DMA transfers can be uniquely defined and that any number of GPIO DMA trigger pins can be uniquely defined, in operation only one GPIO DMA transfer path at any time can exist. This is because, in the case of multiple channel and trigger definitions, all trigger pin events will be directed towards the the highest priority GPIO DMA channel definition.

If  this last statement is correct, it would seem to be in conflict, at least in part, with the following statements of DMA features from the TM4C123 user guide

" - Independently configured and operated channels" (the GPIO DMA channels cannot be operated independently)

" - One channel each for receive and transmit paths for bidirectional modules" (GPIO transfer is bidirectional!)

" - Interrupt on transfer completion, with separate interrupt per channel" (All GPIO DMA pin trigger interrupts will come from the highest priority DMA channel)

Lastly, I would still appreciate a configuration script of a known working GPIO DMA to SRAM example, as my lack of success here prompted the original post.

Best Regards

Ayemk

Hello Ayemk,

Yes that is a Typo. Also regarding the #1 and #2 you are correct. However the interpretation is not correct

1. The channels are independently configured. There exists a unique entry for the UDMA Channel. They work independent of each other. Again I will refer to the ISR example, The design can have ISR from multiple peripherals and each ISR can go and modify the same SRAM location for example or same GPIO Pin can be toggled.

2. The bidirectional is for Data Transfer Peripherals like UART, SSI, I2C and not for GPIO.

3. No, the DMA DONE interrupt will come from the Peripheral Interrupt on which the DMA channel is mapped.

As an example, following is a code. You may have to work the compilation details.

#if defined(ewarm)
#pragma data_alignment=1024
uint8_t pui8ControlTable[1024];
#elif defined(ccs)
#pragma DATA_ALIGN(pui8ControlTable, 1024)
uint8_t pui8ControlTable[1024];
#else
uint8_t pui8ControlTable[1024] __attribute__ ((aligned(1024)));
#endif

#define MEM_BUFFER_SIZE         1024

static uint32_t g_ui32SrcBuf[MEM_BUFFER_SIZE];

SysCtlPeripheralEnable(SYSCTL_PERIPH_UDMA);

uDMAEnable();

uDMAControlBaseSet(pui8ControlTable);

uDMAChannelAssign(UDMA_CH14_GPIOE);

uDMAChannelAttributeDisable(UDMA_CH14_GPIOE,
                                    UDMA_ATTR_USEBURST | UDMA_ATTR_ALTSELECT |
                                    (UDMA_ATTR_HIGH_PRIORITY |
                                    UDMA_ATTR_REQMASK));

uDMAChannelControlSet(UDMA_CH14_GPIOE | UDMA_PRI_SELECT,
                              UDMA_SIZE_32 | UDMA_SRC_INC_32 | UDMA_DST_INC_32 |
                              UDMA_ARB_8);

uDMAChannelTransferSet(UDMA_CH14_GPIOE | UDMA_PRI_SELECT,
                               UDMA_MODE_BASIC, g_ui32SrcBuf, 0x40004400,
                               MEM_BUFFER_SIZE);

uDMAChannelEnable(UDMA_CH14_GPIOE);

Regards

Amit

Amit

For completion, I  am trying to reconcile 2 of the (many) statements you have made:

 "the Interrupt for DMA channel will come on the Interrupt Vector for the corresponding DMA source, in this case either Port E or Port C ISR will be remapped for DMA completion. So indirectly you would know which end port was serviced"

In this example, Ports E and C were the trigger ports; Ports A and D were the byte-wide data transfer ports

And from your quick response directly above

"3. No, the DMA DONE interrupt will come from the Peripheral Interrupt on which the DMA channel is mapped."

So a simple, I hope final, question: if a Port E trigger initiates a Port D DMA transfer will the DMA completion interrupt come on the Port D or Port E interrupt ISRs ??

Regards

Ayemk

Hello Ayemk,

Port E trigger which initiates a Port D DMA Transfer will have DMA completion on the interrupt Line for Port E.

Regards

Amit

Amit

Following up on your example that I requested a few weeks back, for the sake of correctness, I believe that there may be some errors in the configuration.

The "fine print" in the uDMA section of the TivaWare™ Peripheral Driver Library indicates that, for the uDMAChannelAssign function, the parameter should be the ui32mapping value -which, in your example, is the "UDMA_CH14_GPIOE" #define, whilst all other functions (uDMAChannelControlSet,  uDMAChannelAttributeDisable,  uDMAChannelEnable,  etc) require the "ui32ChannelNum" value -which would be , in case, UDMA_CHANNEL_ADC0 or UDMA_CH14_ADC0_0 #defines, or the  channel "14" number.

This conclusion is supported by looking at, for example, the uDMAChannelTransferSet function: (udma.c)

"uDMAChannelTransferSet(uint32_t ui32ChannelStructIndex, uint32_t ui32Mode,void *pvSrcAddr, void *pvDstAddr, uint32_t ui32TransferSize)"

where the function has an  "ASSERT((ui32ChannelStructIndex & 0xffff) < 64)"; however the value for UDMA_CH14_GPIOE is as follows:

 "#define UDMA_CH14_GPIOE             0x0003000E"

The confusion is further exacerbated by the choice of channel / peripherals in the Launchpad Workshop PingPong example ( chapter 13) as the channels specified UDMA_CHANNEL_UART1RX and UDMA_CHANNEL_UART1TX are, correctly, channel numbers but it doesn't seem that  uDMAChannelAssign function is used -i.e. uDMAChannelAssign(UDMA_CH8_UART1RX) and uDMAChannelAssign(UDMA_CH9_UART1TX) (?)

If these observations are incorrect please help to remove some of the confusion.

BTW is there any news on the availability of a comprehensive, eagerly awaited, TM4C uDMA support document?

Regards

Ayemk

Hello Ayemk,

Gladly, would like to help clear the confusion.

The define UDMA_CHANNEL_ADC0 is the legacy format when there were two channels. The new define UDMA_CH14_GPIOE is for multiple DMA maps per channel, where the lower half word is for the channel number and upper half word is the control to the multiplexer-demultiplexer which will select GPIOE to be the DMA source.

As for the function which has a ASSERT, please note it checks the lower half word only to be less than 64. by first AND it with 0xFFFF.

For the Workshop the UART1RX and UART1TX have the define which will match the new define format as well. Since it comes from an older code base, it would continue to use the same notification. I do agree that it should be updated to match the new format. That is where the application note or a better description of the uDMA be covered,

It is not an easy task to get the application note in place and takes about couple of months of effort to make sure we test the attached examples and documentation with "beta" testing internally. Also with the number of application notes in the queue, it would take time (hopefully close by 2Q as promised)

Regards

Amit

Amit

Thank you for the rapid response that unclouds(!) some of the confusion. Not having any experience with the "legacy" structures and formatting does complicate understanding.

I am left with 3 queries with regards to the current APIs and documentation

1. In the uDMA APIs, is there complete equivalence between ui32Mapping  (uDMAChannelAssign) and ui32ChannelNum (uDMAAttributeEnable /Disable, etc)?

2. In what functions is it necessary to use the "new" defines that contain the additional channel mapping -i.e the multiplexer-demultiplexer component?

3. Under what circumstances is the uDMAChannelAssign not required (as seems the case in the PingPong Workshop example)? Is there a concept of default / legacy  multiplexer configuration?

Regards

Ayemk