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
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: http://software-dl.ti.com/dsps/dsps_registered_sw/sdo_sb/targetcontent/link/index.html
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
- free: called within
- Note: open and alloc will return an Int status value that is either
SYS_OKor 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