NOTICE: The Processors Wiki will End-of-Life in December of 2020. It is recommended to download any files or other content you may need that are hosted on processors.wiki.ti.com. The site is now set to read only.
Moving from DSPLink 1 30 to 1 40
This page gives information for users attempting to move applications from DSPLink v1.30.xx to v1.40.xx.
Details of changes between v1.30.xx and v1.40.xx are available within ReleaseNotes of each subsequent release.
- Subsequent patches p1, p2, p3 and p4 on 1.40.05
This page details the changes having significant impact on application writers.
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
- 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.libneeds to be rebuilt. Optionally, users can include this configuration file within their application build after modifying the name of the configuration structure
LINKCFG_configin their copy. The address of this structure can then be passed to
PROC_setupcall. 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_startwill 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_startwill 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.
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:
- By default,
PROC_startwaits 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
HSHKPOLLCOUNThas 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 API signatures and types have changed to follow DSP/BIOSTM 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_SIGNALSand rebuild the GPP-side user-level library (
- DSP-side applications must call
DSPLINK_initin 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_initis not called,
- DSP-side applications must now include different libraries for the different modules (
dsplinkringio.lib) based on whether these have been selected in the build configuration (when running the
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.