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

API changes

Important Notes

See Also