Software Migration: DM642 to DM648/DM6437

This topic discusses software application migration from DM642 to DM648 or DM6437. Hardware differences, such as changes between C64 and C64+, are not discussed. Instead, we explore the changes in software development tools: libraries, drivers, and frameworks. The reader should be able to translate old programs to a newer device, identifying disconnects and critical differences between old and new tools and migrating functionality as seamlessly as possible.

While the DM648 is the proper successor to the DM642, the DM6437 is also considered a viable migration target. Both the DM648 and DM6437 are single-core, DSP-only devices, which differ primarily in hardware considerations: clock speed, peripheral devices, etc. Their development tools (DVSDKs) are very similar, and they are thus very similar targets for software migration.

Peripheral Access

This section covers changes regarding the initialization and use of peripheral devices. For both old and new devices, we describe low- and high-level methods for accessing peripherals. Then, suggestions are given for migrating existing DM642 applications.

Software layers in DM642 development compared to DM648 or DM6437 development.

Low-Level Access on DM642

For DM642 applications, low-level peripheral access refers to using a peripheral device through functional CSL (FCSL). The FCSL packages provide APIs to initialize and control peripheral devices with relatively little abstraction. Rather than making one function call to complete an IO transaction, it may be necessary to make separate calls to initiate, manage, and terminate a single transfer. The use of FCSL does not require DSP/BIOS. For more information and example code using FCSL with the DM642, refer to Using Functional CSL with DM642.

FCSL is built on top of register-layer CSL (RCSL), but RCSL is rarely used directly in DM642 applications. Throughout this topic, a low-level DM642 application refers exclusively to an application using FCSL.

High-Level Access on DM642

High-level access on the DM642 refers to the use of minidrivers which run within DSP/BIOS under the IOM specification. The DM642 DVSDK does not include a full complement of drivers, but a few sample drivers are provided to help users understand the requirements and structure of IOM. The Driver Development Kit (DDK), available for DM642 but not included with the standard DVSDK installation, provides further help for developing IOM drivers.

Drivers for the DM642 typically use the DSP/BIOS-standard GIO or SIO APIs to perform IO transactions at a high level. For instance, one call to GIO_submit may initiate and control an entire transfer, then call a user-specified callback function when complete. This sort of program will migrate readily to the newer devices, which provide similar functionality through a Platform Support Package (PSP). Refer to Using a PSP Driver in DSP/BIOS for example source code using the GIO API.

Low-Level Access on DM648 or DM6437

The DM648 and DM6437 DVSDKs do not offer FCSL packages. The only option available to users who wish to develop low-level applications for these devices is the underlying register-layer CSL. RCSL is included with the DVSDK as part of the PSP, and it consists of a set of header files that allow direct access to peripheral registers. Effectively using RCSL requires extensive knowledge of the peripheral device, and source code using RCSL tends to be complicated and difficult for others (or even the programmer!) to understand. Applications built using RCSL are effectively even lower-level than DM642 applications using FCSL.

The following code may be used to initialize an I2C device and process one byte in master receive mode. Please note that this is not a complete program; it is only meant to demonstrate the form of RCSL code.

<syntaxhighlight lang="c">#include <cslr_i2c.h>

1. include <soc.h>

CSL_I2cRegsOvly i2c0Regs = (CSL_I2cRegsOvly)CSL_I2C_0_REGS; int buffer;

void main() { // Reset I2C device CSL_FINST(i2c0Regs->ICMDR, I2C_ICMDR_IRS, RESET); // Configure I2C i2c0Regs->ICMDR = CSL_FMKT(I2C_ICMDR_MST, MASTER) | CSL_FMKT(I2C_ICMDR_TRX, RX_MODE) | CSL_FMKT(I2C_ICMDR_RM, DISABLE) | CSL_FMKT(I2C_ICMDR_DLB, DISABLE) | CSL_FMKT(I2C_ICMDR_FDF, DISABLE) | CSL_FMKT(I2C_ICMDR_XA, 7BIT) | CSL_FMKT(I2C_ICMDR_BC, 8BIT); // Set slave addr CSL_FINS(i2c0Regs->ICSAR, I2C_ICSAR_SADDR, 0x50); // Configure I2C clock for 200 kHz (from 27MHz input clk) CSL_FINS(i2c0Regs->ICPSC, I2C_ICPSC_IPSC, 0x02); CSL_FINS(i2c0Regs->ICCLKL, I2C_ICCLKL_ICCL, 0x12); CSL_FINS(i2c0Regs->ICCLKH, I2C_ICCLKH_ICCH, 0x12); // Clear ICSTR (read and write back) i2c0Regs->ICSTR = i2c0Regs->ICSTR; while (i2c0Regs->ICIVR != 0) asm(" nop"); // Take I2C out of reset CSL_FINST(i2c0Regs->ICMDR, I2C_ICMDR_IRS, ENABLE); // Wait for bus busy to clear while (CSL_FEXT(i2c0Regs->ICSTR, I2C_ICSTR_BB) == CSL_I2C_ICSTR_BB_BUSY) asm(" nop"); // Generate START CSL_FINST(i2c0Regs->ICMDR, I2C_ICMDR_STT, SET); // Wait for data received while (CSL_FEXT(i2c0Regs->ICSTR, I2C_ICSTR_ICRRDY) == CSL_I2C_ICSTR_ICRRDY_FALSE) asm(" nop"); buffer = (int)(i2c0Regs->ICDRR); // Generate STOP CSL_FINST(i2c0Regs->ICMDR, I2C_ICMDR_STP, SET); }</syntaxhighlight>

High-Level Access on DM648 or DM6437

Unlike the DM642, the DM648 and DM6437 DVSDKs each include a full complement of IOM-compliant drivers. These drivers comprise a Platform Support Package, or PSP, which services each and every peripheral device. PSP drivers, like other IOM drivers, allow high-level peripheral access via the GIO or SIO APIs. For more information and example code using PSP drivers, refer to Using a PSP Driver in DSP/BIOS. High-level peripheral access on the DM648 or DM6437 refers to the use of PSP drivers.

The PSP includes full source code for each driver, allowing users to modify and rebuild drivers if necessary. The PSP source code is modular, and code is separated into different "layers" according to function. For more information on the organization of a PSP driver, refer to PSP Overview.

Migrating High-Level DM642 Applications

Migrating high-level DM642 applications to the new DVSDK is straightforward. If the existing code uses IOM-compliant drivers, it should be built using the GIO or SIO APIs. Converting this code to use a PSP-delivered IOM driver is straightforward: determine what changes, if any, are required among the parameters passes in your existing GIO or SIO calls. Also, refer to the PSP driver's User Guide and sample application (both included with the DVSDK) to determine how the driver is initialized and controlled at run time. Typically, the device is initialized with a parameter struct that must be provided in your application source code.

There are a few caveats to consider, however. First, DM648 and DM6437 applications using DSP/BIOS 5.x are configured using textual configuration files (TCFs). Older DM642 applications using DPS/BIOS 4.90 may be configured using a configurable database (CDB) file, which is vastly different from TCF. Code Composer Studio 3.3 can automatically migrate older DM642 projects to DSP/BIOS 5.x, which can spare you the effort of creating a TCF file from scratch. A comprehensive description of TCF falls outside the scope of this topic, but a description of TCF contents necessary to initialize a peripheral device for use by a PSP driver can be found in Using a PSP Driver in DSP/BIOS.

Another potential problem is a mismatch in functionality between a DM642 driver and the new device's PSP driver. For instance, the older driver may use the SIO API, while its replacement uses only GIO. A more severe situation may be that the PSP driver does not support a certain mode of operation that was serviced by the older driver. These problems must be addressed on a case-by-case basis, and at worst may require that the user modify the PSP driver to suit his or her needs.

Finally, it is possible that the DM642 application uses a non-IOM-compliant driver. It may even use a non-standard API. In this case, the existing code will need to be translated to the GIO or SIO API. For a brief description of how to use these APIs, refer to Using a PSP Driver in DSP/BIOS.

Summary

1. Setup TCF/TCI to initialize peripheral device for PSP driver.
2. Verify that existing DM642 application uses GIO or SIO API.
   • Individual PSP drivers may support GIO, SIO, or both. Check that the desired API is supported by the driver.
   • If existing application does not use GIO or SIO, translate existing driver calls to one of these APIs.
3. Verify that mode of operation (i.e. operating parameters) is supported by PSP driver.
   • If mode of operation is not supported, decide whether to modify operation or modify PSP driver to add support.
4. Modify existing GIO, SIO calls to use parameters expected by PSP driver. Refer to PSP driver's User Guide and sample application.

• See also: Using a PSP Driver in DSP/BIOS

Migrating Low-Level DM642 Appplications

Due to the absence of FCSL in newer DVSDKs, there is no clean migration path for low-level DM642 applications. Because of this, the existing application must be rewritten in one of two ways:

Rewrite Using RCSL

The application is rewritten at a lower level. The resulting source code will likely be denser and less readable, but fine control over the peripheral is maintained, or even enhanced. RCSL allows the peripheral to be exercised in any way supported by its documentation, but its use requires that the user be an expert in the use of that peripheral.

Rewrite Using PSP

Direct control of the peripheral is surrendered to the PSP driver. This allows the program to operate at a higher level, but may not be acceptable if the application is not supported by the PSP driver. For many applications, this will not be a problem. The PSP driver for each peripheral is intended to service all modes of operation possible on the EVM hardware. If the PSP driver does not support an application, it may be modified. For more information on the structure of a PSP driver and tips on where to look for certain functionality, refer to PSP Overview. For general information on how to initialize and use a PSP driver, refer to Using a PSP Driver in DSP/BIOS.

EDMA

The DM648 and DM6437 each include an integrated EDMA3 controller. The DM642, meanwhile, uses EDMA2. A detailed comparison of the features in these two EDMA revisions is available in the application note EDMA v2.0 to EDMA v3.0 (EDMA3) Migration Guide. Users should familiarize themselves with the new and different features of EDMA3 before attempting to migrate existing software that uses EDMA.

Dependencies in an application using the EDMA3 LLD.

The DM648 and DM6437 offer EDMA control through the EDMA3 LLD (low-level driver), which is included with the DVSDK installation. The EDMA3 LLD may be packaged either as part of the PSP or as a discrete package. The EDMA3 LLD consists of three libraries: the EDMA3 driver library (EDMA3 DRV) provides a FCSL-like API to control EDMA transactions; EDMA3 resource manager library (EDMA3 RM) tracks device resources and services EDMA3 DRV; and a final library provides a convenient initialization routine and abstracts the other two libraries from the DSP/BIOS operating system. The final library can be replaced by the user, but a standard implementation is included with the EDMA3 LLD installation. This "sample" library is suitable for all DSP/BIOS applications. Users who wish to use the driver apart from DSP/BIOS will need to replace the sample library.

The first step in updating an EDMA-using DM642 application is to rewrite its FCSL-based EDMA2 control using the newer, EDMA3 DRV API. Since this API operates on a level of abstraction similar to FCSL, the process should be straightforward. Refer to the EDMA3 LLD User Guides (included with the EDMA3 LLD installation in PDF format) for more information regarding initialization and use of the EDMA3 LLD. Separate User Guides exist for the EDMA3 DRV and EDMA3 RM libraries. Also, refer to the application note How to Use the EDMA3 Driver on a TMS320C643x Device. (Bear in mind that newer releases of the EDMA3 LLD are packaged using RTSC, which is not discussed in the above application note.)

The second step is to revise existing EDMA calls to accomodate changes between EDMA versions and to take advantage of new features in EDMA3. Again, refer to the application note EDMA v2.0 to EDMA v3.0 (EDMA3) Migration Guide for more information.

Summary

1. Replace FCSL-based EDMA control with the EDMA3 LLD.
2. Update code to reflect changes from EDMA2 to EDMA3.

See Also

• PSP Overview
• Using a PSP Driver in DSP/BIOS
• Using Functional CSL with DM642
• How to Use the EDMA3 Driver on a TMS320C643x Device (app note)
• EDMA v2.0 to EDMA v3.0 (EDMA3) Migration Guide (app note)
• DM642 (TI Website)
• DM648 (TI Website)
• DM6437 (TI Website)
• EDMA3 LLD (low-level driver) WebEx Presentations