Moving from DSPLink 1 30 to 1 40

From Texas Instruments Embedded Processors Wiki

Contents 1 Overview 2 Details 3 New functionality 4 Changes required in existing applications 4.1 Generic changes 4.2 GPP-side changes 4.3 DSP-side changes 4.4 Other information

Overview

This page gives information for users attempting to move applications from DSPLink v1.30.xx to v1.40.xx.

Details

Details of changes between v1.30.xx and v1.40.xx are available within ReleaseNotes of each subsequent release.

• 1.40.03
• 1.40.05
• Subsequent patches p1, p2, p3 and p4 on 1.40.05

This page details the changes having significant impact on application writers.

New functionality

New modules and features have been added in the 1.40.xx versions of DSPLink. If the new modules are to be used, their description and usage are documented in the UserGuide document available within the DSPLink release package. New sample applications have also been written to demonstrate the functionality of these new modules. A summary of the major new modules & features added in 1.40.03 is:

• Dynamic configuration
• RingIO: Circular ring buffer based data streaming
• NOTIFY: User-level event notification
• MPCS: Multi-processor critical section
• MPLIST: Multi-processor doubly linked circular list

Changes required in existing applications

If the user only requires existing features and wants to move from v1.30.xx to v1.40.xx, the subsequent sections detail important points for upgrading the application to the new version

Generic changes

• 1.40.xx uses dynamic configuration ($(DSPLINK)/config/all/CFG_<PLATFORM.c) instead of static configuration ($(DSPLINK)/config/all/CFG_<PLATFORM.TXT). Configuration source and header files are no longer generated. Applications can modify the configuration without having to rebuild the DSPLink kernel-module or DSP-side libraries. Only the GPP-side user-side DSPLink library dsplink.lib needs to be rebuilt. Optionally, users can include this configuration file within their application build after modifying the name of the configuration structure LINKCFG_config in their copy. The address of this structure can then be passed to PROC_setup call. If this is done, even the GPP-side library does not need to be re-built, and just the application can be re-built.
• A version string is now included within the GPP-side and DSP-side of DSPLink. This ensures that incompatible versions of GPP and DSP-side can no longer be used. If there is a version mismatch between GPP and DSP-sides of DSPLink, PROC_start will wait, timeout and return with error, and also print the version mismatch information.
• If there is some issue in configuration between the GPP and DSP-side, or if the DSP-side startup failed, PROC_start will now wait, timeout and return with error, and also print information about which DSP-side module was not correctly initialized.
• Applications only need to include a single header (dsplink.h) on both GPP and DSP-sides for the basic DSPLink services. Additional module-specific headers are only required if the module is used: e.g. proc.h, msgq.h, chnl.h, mpcs.h, mplist.h, ringio.h, notify.h, pool.h. (This is optional. Even if you keep the files, no major impact is seen)
• If users are not using the DSPLink make system for building their applications, they need to be aware of the compiler flags, defines and include paths required for the build. This information is provided through generated files in: $(DSPLINK)/[gpp|dsp]/export/BIN/[OS]/[PLATFORM]/[VARIANT]. For e.g. if the application writer needs to know the include paths needed for MSGQ module on GPP side, he/she needs to refer to: $(DSPLINK)/gpp/export/BIN/Linux/Davinci/DEBUG/MESSAGE_includes.TXT.
• By default, PROC_start waits for a finite amount of time to let the DSP-side start up and initialize all the components. If applications wish to debug on the DSP-side and have hence placed an infinite loop in main (), this may cause GPP-side to timeout. This is the default behavior, To avoid this, now users can configure this in the dynamic configuration file. Within the LINKCFG_linkDrvObjects first entry, HSHKPOLLCOUNT has a finite value. This can be changed to -1 if infinite wait is desired, as for debugging. After making this change, either GPP-side user library, or application needs to be rebuilt, depending on whether the configuration file is included in the application build (as mentioned in the first point above).

GPP-side changes

• GPP-side API signatures and types have changed to follow DSP/BIOS^TM naming convention. The older APIs and types have been deprecated, however, defines for backward compatibility have been provided in this release. (You will not see a build error as backward compatible API’s have been provided, but it is advisable to move to the new naming convention. The new modules following the new naming convention.)
• User can optionally use signals to cleanup DSPLink on Linux. The default is that signals will not be used. If user prefers that the process termination signals are caught and handled by DSPLink, user must define the compile flag DSPLINK_HANDLE_SIGNALS and rebuild the GPP-side user-level library (dsplink.lib).

DSP-side changes

• DSP-side applications must call DSPLINK_init in their application’s main () function before using any DSPLink functionality. If any earlier module-specific init functions were being called, these calls must now be removed. If DSPLINK_init is not called, PROC_start will fail.
• DSP-side applications must now include different libraries for the different modules (dsplink.lib, dsplinkdata.lib, dsplinkmsg.lib, dsplinkpool.lib, dsplinkmpcs.lib, dsplinkmplist.lib, dsplinknotify.lib, dsplinkringio.lib) based on whether these have been selected in the build configuration (when running the dsplinkcfg script).

Other information

Note that this does not cover the complete list, but only summarizes the major changes. For the complete list, you will need to refer to the Release Notes of all intermediate releases as mentioned earlier on this page

Leave a Comment