AM64x MCU+ SDK  10.00.00
UDMA Migration Guide

This section describes the differences between UDMA APIs of MCU+ SDK and Processor SDK RTOS (PDK). This can be used as a migration aid when moving from Processor SDK RTOS (PDK) to MCU+ SDK.

API changes

There are few changes in API names, structure names and macro names along with few behaviour changes with respect to SysConfig integration. These are listed in below table.

PDK MCU+ SDK Remarks
UDMA_WAIT_FOREVER and UDMA_NO_WAIT SystemP_WAIT_FOREVER and SystemP_NO_WAIT Use SystemP macro for timeout parameter in all relevant APIs
OSAL Abstraction through function pointer using Udma_OsalPrms, Udma_OsalCachePrms and Udma_PrintFxn structures NA These are removed as abstraction is done through DPL layer directly
Udma_RmInitPrms NA Removed user override of resources. Instead the driver queries the DMSC board configuration and populate the default value during driver init
UdmaUtils_makeTrpd first param type changed from: void * UdmaUtils_makeTrpd to: uint8_t * None
All UTC, DRU, Proxy and generic flow related interfaces NA These are removed as these modules are not present in AM64x/AM243x
Udma_chDequeueTdResponse NA This is removed as this feature is not applicable for AM64x/AM243x
Udma_flowAlloc NA This is removed as this feature is not applicable for AM64x/AM243x
struct Udma_DrvObj Udma_DrvObject Renamed and is also made as an abstract structure for user
struct Udma_ChObj Udma_ChObject Renamed and is also made as an abstract structure for user
struct Udma_RingObj Udma_RingObject Renamed and is also made as an abstract structure for user
struct Udma_FlowObj Udma_FlowObject Renamed and is also made as an abstract structure for user
struct Udma_EventObj Udma_EventObject Renamed and is also made as an abstract structure for user
rmInitPrms, skipRmOverlapCheck, printFxn and osalPrms members in Udma_InitPrms structure Removed These are removed for reasons stated in above rows

Important Notes

  • In MCU+ SDK, users are recommended to use SysConfig as this will greatly simplify the task of driver configuration.
    • UDMA driver init and deinit APIs are called through the SysConfig generated init code - user need not explicitly call them
    • In case of UDMA blockcopy channels,
      • User can select number of channels needed in the application through SysConfig
      • Channel open, configuration and close is automatically done by the SysConfig generated code
      • This also includes ring memory allocation and configuration
      • User can then use the created channel handle through gConfigUdma0BlkCopyChHandle like SysConfig generated globals as declared in "ti_drivers_open_close.h" and use them in other runtime APIs

See Also