NOTICE: The Processors Wiki will End-of-Life on January 15, 2021. 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.

Opening DSP Pools dynamically

From Texas Instruments Wiki
Jump to: navigation, search

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.

Overview[edit]

One of the common issues encountered with the POOL module in DSP/BIOSTM Link, is the guideline that all pools must be opened before PROC_start. This is a big limitation since all application buffer requirements must be known in advance, and prevents true multi-application support, and also results in consumption of extra memory.
This limitation is due to:

  • In DSP/BIOS 5.3x, all pools are statically registered with DSP/BIOS through POOL_config structure.
  • All pools get automatically opened on DSP-side before main (as part of POOL_init in DSP/BIOS). The configuration within user-specified POOL_config structure gets used for this.
  • DSPLink shared memory pool is only configured from GPP-side. DSP-side simply opens the pool and polls to make sure that GPP-side has completed opening and configuring the pool shared memory.
  • Due to this, DSPLink SMAPOOL_open call during BIOS initialization ends up hanging the system due to a handshake conflict between the DSPLink driver and the pool.

However, this limitation can be worked around by dynamically opening the DSP pools using the method detailed below.

Details[edit]

The procedure detailed in this section can be followed to enable opening shared pools after PROC_start on the ARM-side. This does not require any change in DSPLink.

(Note that the code given below is only indicative. This code cannot be associated with anything in any actual DSPLink release. You will need to make similar changes in your actual application.)

  • On the DSP-side, instead of specifying the actual pool configuration, use a dummy configuration. This ensures that BIOS boot-up in POOL_init does not hang waiting for the GPP-side pool to be opened.

<syntaxhighlight lang=c>

  1. define NUM_POOLS 1

/** ============================================================================

*  @name   MESSAGE_Pools
*
*  @desc   Array of pools.
*  ============================================================================
*/

POOL_Obj MESSAGE_Pools [NUM_POOLS] = {

   POOL_NOENTRY

} ;

/** ============================================================================

*  @name   POOL_config
*
*  @desc   POOL configuration information.
*          POOL_config is a required global variable.
*  ============================================================================
*/

POOL_Config POOL_config = {MESSAGE_Pools, NUM_POOLS} ; </syntaxhighlight>

  • After the GPP-side pool is opened (which may be after PROC_start), the application can notify the DSP-side (possibly through NOTIFY_notify, since NOTIFY module does not have any dependency on POOL). Note that the application must ensure that it does not attempt to use the POOL either directly or indirectly before the pool is opened on both GPP and DSP-sides.
  • When the notification is received from GPP that the pool has been opened, the DSP-side application can now provide the actual configuration parameters and open the pool. This is to ensure that the DSP-side application does not spin waiting for the pool to be opened by GPP-side. With this method, the DSP-side can simply wait on a semaphore for the GPP-side pool to be opened, and the notification callback posts this semaphore. The pool can be opened on DSP-side by:

<syntaxhighlight lang=c> /* Define actual SMAPOOL parameters */ SMAPOOL_Params MESSAGE_PoolParams [NUM_POOLS] ;

/* Setup SMAPOOL parameters*/ MESSAGE_PoolParams [poolId].poolId = poolId ; MESSAGE_PoolParams [poolId].exactMatchReq = TRUE ;

/* Populate the global POOL configuration structure with actual POOL configuration.*/ MESSAGE_Pools [poolId].initFxn = SMAPOOL_init ; MESSAGE_Pools [poolId].fxns = (POOL_Fxns *) &SMAPOOL_FXNS ; MESSAGE_Pools [poolId].params = &(MESSAGE_PoolParams [poolId]) ; MESSAGE_Pools [poolId].object = NULL ;

/* Open the POOL dynamically */ status = POOL_open (poolId, &(MESSAGE_Pools [poolId])) ; </syntaxhighlight>

  • POOL_open is defined as:

<syntaxhighlight lang=c>

  1. if !defined (POOL_open) /* To ensure no clash with future BIOS definition */

/** ============================================================================

*  @name   POOL_open
*
*  @desc   Macro over the allocator for opening a pool.
*
*  @arg    poolId
*              Pool id.
*  @arg    params
*              Parameters for opening the pool.
*
*  @see    POOL_close
*  ============================================================================
*/
  1. define POOL_open(poolId, params) \
       (((POOL->allocators [poolId]).fxns->open)              \
               (&(POOL->allocators [poolId].object),          \
                params))
  1. endif /* if !defined (POOL_open) */

</syntaxhighlight>

E2e.jpg {{
  1. switchcategory:MultiCore=
  • For technical support on MultiCore devices, please post your questions in the C6000 MultiCore Forum
  • For questions related to the BIOS MultiCore SDK (MCSDK), please use the BIOS Forum

Please post only comments related to the article Opening DSP Pools dynamically here.

Keystone=
  • For technical support on MultiCore devices, please post your questions in the C6000 MultiCore Forum
  • For questions related to the BIOS MultiCore SDK (MCSDK), please use the BIOS Forum

Please post only comments related to the article Opening DSP Pools dynamically here.

C2000=For technical support on the C2000 please post your questions on The C2000 Forum. Please post only comments about the article Opening DSP Pools dynamically here. DaVinci=For technical support on DaVincoplease post your questions on The DaVinci Forum. Please post only comments about the article Opening DSP Pools dynamically here. MSP430=For technical support on MSP430 please post your questions on The MSP430 Forum. Please post only comments about the article Opening DSP Pools dynamically here. OMAP35x=For technical support on OMAP please post your questions on The OMAP Forum. Please post only comments about the article Opening DSP Pools dynamically here. OMAPL1=For technical support on OMAP please post your questions on The OMAP Forum. Please post only comments about the article Opening DSP Pools dynamically here. MAVRK=For technical support on MAVRK please post your questions on The MAVRK Toolbox Forum. Please post only comments about the article Opening DSP Pools dynamically here. For technical support please post your questions at http://e2e.ti.com. Please post only comments about the article Opening DSP Pools dynamically here.

}}

Hyperlink blue.png Links

Amplifiers & Linear
Audio
Broadband RF/IF & Digital Radio
Clocks & Timers
Data Converters

DLP & MEMS
High-Reliability
Interface
Logic
Power Management

Processors

Switches & Multiplexers
Temperature Sensors & Control ICs
Wireless Connectivity