Migrating from DSPLink 1 40 to 1 50

END OF LIFE

DSP Link is still available for download, but no further releases or updates are planned. Please see IPC Software Options for details and alternatives.

Introduction

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

New features in v1.50

Overview

Major feature additions in DSPLink v1.50 are:

• Enhanced multi-process and multi-application support
• Multi-process cleanup support on Linux
• Intra-GPP MSGQ
• Addition of Programmer’s Guide document

Other minor enhancements include:

• Dynamic configuration of DSP clock rate
• Statically linked archive on Linux
• Removal of MSGQ and CHNL transfer serialization
• Addition of RingIO helper macros
• NOTIFY thread wait instead of poll
• DSP-side MPCS enhancement for interrupt latency reduction

Details of Major feature additions

Enhanced multi-process and multi-application support

For Operating Systems such as Linux with a user-kernel boundary, the enhanced multi-process and multi-application support adds the following new features into DSPLink:

• Different processes/applications no longer need to be aware of each others’ timelines
• They can come and go at any time. DSPLink internally handles the access control
• Restrictions on all DSPLink processes running simultaneously
  • Must use the same dynamic configuration
  • Must use the same DSP executable containing integrated DSP-side content required for all the co-existing GPP-side applications
  • System-wide unique DSPLink resources (e.g. RingIO/MSGQ names) must be unique for the applications. This can be easily ensured by prefixing all such resource names by the application identifier/name.
• No owner process that needs to come first (PROC_attach) and go last (PROC_detach)
• No need for LAD (Link Arbiter Daemon) or a separate utility to arbitrate access to DSPLink

Before this feature, the applications were required to follow the flow given in the below figure:
After the addition of the enhanced multi-process and multi-application support, the applications can now use the simplified flow given below:

In addition to this new flow, the previous control flow is still supported for backward compatibility, and to support fully static systems. However, for easier integration of different applications, the new flow is much more convenient, and enables applications to easily come and go irrespective of other applications that may or may not be already running and using DSPLink.

Multi-process cleanup support

Prior to DSPLink v1.50, the PROC, MSGQ and POOL startup & shutdown resources (e.g. PROC_setup, MSGQ_transportOpen, POOL_open etc.) were associated with the thread ID of the calling thread. Due to this, when Ctrl C was used to kill the application process, or there was an abnormal termination, it was possible that any thread within the process could catch the signal. In such cases, the cleanup would be insufficient, since the thread ID of the thread that had caught the signal, was used for verification of ownership. In v1.50, this association has now been changed to process ID, allowing any thread within the process to make the cleanup calls on termination.

In addition, the signal handling on Linux for cleanup is now dynamically configurable through a newly added OS-specific dynamic configuration file: $(DSPLINK)/config/all/CFG_<GPPOS>.c. The following items are now configurable:

• Handle signals for cleanup (TRUE/FALSE)
• Signal numbers to be handled

With this configuration, the user no longer needs to make modifications within DSPLink code, or build it with a different compiler define (previously required as DSPLINK_HANDLE_SIGNALS), but can simply make the required changes in the dynamic configuration file.
In case the exiting application does not call all required DSPLink shutdown APIs, DSPLink now internally ensures proper cleanup by registering atexit handler by default.
Note: While DSPLink provides basic cleanup functionality on abnormal termination through the signal handling, doing the right cleanup on exit is actually the purview of the application. Hence it is advised that the DSPLink signal handling mechanism should simply be used during development of the application to avoid having to re-boot the hardware on error.

However, in the production system, the applications should use an appropriate signal handling mechanism to cleanup all application resources, followed by DSPLink (and other driver) resources on exit, possibly through a different signal handling thread.

Intra-GPP MSGQ

Intra-GPP MSGQ support has been added into DSPLink. With this, applications can now use MSGQ to communicate between:

• process<->process
• thread<->thread

While using DSPLink MSGQ may not be the most efficient way for communication within the GPP (OS-provided messaging mechanisms will be most efficient), intra-GPP MSGQ would be useful if portable applications are to be written, where the tasks should be easily movable between the GPP and the DSP.

Addition of Programmer's Guide

A new Programmer's Guide document has been added into DSPLink in v1.50. This document:

• Provides useful information for application developers
• Gives information about different application scenarios and provides guidance to choose the right modules
• Provides useful information about different modules and DSPLink features. For example:
  • PROC configuration
  • POOL configuration
  • RingIO footBuffer usage

Other minor changes

Dynamic configuration of DSP clock rate

The DSP clock rate can now be configured through DSPLink dynamic configuration file $(DSPLINK)/config/all/CFG_<PLATFORM>.c. This enables the same DSP executable to be used on platforms running at different frequencies.

Statically linked archive on Linux

In addition to .lib file, .a archive file is also generated. This saves footprint.

Removal of MSGQ and CHNL transfer serialization

If messages or data buffers are sent at high frequency, this change allows multiple messages/buffers to be sent simultaneously through the driver without serialization. This results in more efficient message and data transfers.

Addition of RingIO helper macros

• RingIO_getValidAttrSize: Return the valid size within attribute buffer
• RingIO_getEmptyAttrSize: Return the empty size within attribute buffer

NOTIFY thread wait instead of poll

• NOTIFY module creates a thread on user-space that checks for any notifications from DSP-side (kernel-space)
• Prior to v1.50, this was done in polling mode.
• In v1.50, this was enhanced to wait on a semaphore to minimize CPU load

DSP-side MPCS enhancement for interrupt latency reduction

• Prior to v1.50, DSP-side MPCS disabled interrupts when waiting for lock to be available. This may cause high interrupt latency
• In v1.50, this was changed to disable SWIs (scheduler) instead of interrupts.
• This change requires move to DSP/BIOS 5.32.01
• After this change, DSPLink DSP-side API calls that may take MPCS lock must not be called from ISR context.

Make system enhancement

Support for platform variant to minimize porting effort

Support for new platform/GPP OS configurations

• DM6467 (Davinci HD)
• DM6446 (Davinci): Support for Linux kernel version 2.6.18
  • Uses MVL Pro 5 with engineering LSP
  • Supports glibc & uclibc
• DRA44x: Support for PrKernel v4 ver3.1 rev3 with eBinder

Upgrade and compatibility information

This section gives the details of backward compatibility and upgrade information for applications to move to DSPLink v1.50

from the previous release v1.40.05 with latest patch p4.

• API-level backward compatibility with v1.4x
• Generic changes
  • Changes in dynamic configuration structures
    • If using dynamic configuration, ensure that a diff is done between the application copy and the new default configuration
  • Binaries are now generated in $(PLATFORM)/$(VARIANT) directory, if variant is present for the platform (e.g. DM6467 and DM6446 are variants of Davinci)
  • Changes related to RingIO notification for flush & cancel APIs
• GPP-side
  • POSIX compliant threading library (e.g. NPTL) must be used. If LinuxThreads or other non-POSIX-compliant threading library is used, multi-process cleanup functionality may not work as expected.
  • Values of DSPLink error/success codes have been changed. This does not have any impact if provided macros in $(DSPLINK)/gpp/inc/errbase.h are used instead of magic numbers.
  • Additional success and error codes have been added
    • Startup & shutdown APIs now indicate if they were being called for the first/last time to support enhanced multi-process scenarios
• DSP-side
  • DSPLink APIs can no longer be called from ISR context. SWI or TSK must be used.
  • DSP/BIOS™ 5.32.01 version or later must be used

For full details, refer to Release Notes section on “Upgrade and compatibility information”