Please note as of Wednesday, August 15th, 2018 this wiki has been set to read only. If you are a TI Employee and require Edit ability please contact x0211426 from the company directory.

Creating custom pool allocators

From Texas Instruments Wiki
Jump to: navigation, search


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

How to create a custom allocator for pools

To implement a customized version of a DSP/BIOS or DSP/LINK Pool allocator, the following needs to be considered:

  • the POOL module within BIOS does not include any APIs. It is used used internal by MSGQ. The only actions needed by the user is to set up the POOL_config variable and enable POOL.
  • BIOS ships with one implementation of a POOL (STATICPOOL) but the sources are not included in the distribution
  • DSP Link does add some POOL APIs that simply wrapper the interface functions. DSP Link also ships some POOL implementations with source code.

A good approach for writing a specific pool is to use an existing one for reference.

Refer for example at the DSPLink Shared Memory Allocator POOL (SMAPOOL) as an example implementation.

  • The DSPLink SMAPOOL implementation is in dsplink/dsp/src/pools/DspBios/sma_pool.c.
  • The wrapper POOL APIs are in dsplink/dsp/inc/dsplink.h.

In DSP Link there are also documents which explain the architecture of the various modules.


You can download DSP/Link form here:

Here you have also some FAQs on SMAPOOL:

More details on the BIOS POOL module

Regarding the POOL_Obj:

  • initFxn: the module init function that is called before main(). It has no parameters and is a void return.
  • fxns: The interface functions. Please refer to \packages\ti\bios\include\POOL.h for the prototypes.
open: called during boot after the initFxn is called. It is passed the object and the parameters from the POOL_Obj
close: currently not called within BIOS
alloc: called within MSGQ_alloc()
free: called within MSGQ_free()
Note: open and alloc will return an Int status value that is either SYS_OK or some SYS_* error value; all other functions have a return type of Void and thus should always succeed.
  • params: object parameters. This are going to be module specific (thus the generic Ptr type)
  • object: module specific (thus the generic Ptr type). Having the user supply the memory for the object allows the module to avoid making a memory allocation