How to? Custom codec appliance

I believe GenServer has done this for me.  First, the run of GenServer from CCSv4 ended with a message reading "Don’t forget to edit codec.cfg and server.cfg to assign and modify config parameters.  See [codec engine folder then packages/]ti/sdo/ce/wizards/genserver/readme.txt file for syntax information" (brackets added).  When I look at those files superficially, server.cfg doesn't appear to relate to me.  codec.cfg, however, already contains a Server.algs[] array variable initialized with my codec [and presumably others too if I had included any].

The readme.txt simply says to replace any "undefined" in codec.cfg, but I don't have any.  I'll have to assume for now that I'm fine.  I'm quoting the files below. (duh!)

Server.cfg said:

 

/*

 *  "Use" the various codec modules; i.e., implementation of codecs.

 *  All these "xdc.useModule" commands provide a handle to the codecs,

 *  which we'll use to initialize config params and add the codecs to

 *  the Server.algs array.

 */

    var MYCODEC = xdc.useModule('mycompany.mycodec.ce.MYCODEC');

 

        MYCODEC.serverFxns = "VIDANALYTICS_SKEL";

        MYCODEC.stubFxns = "VIDANALYTICS_STUBS";

 

 

 

/*

 * The array of algorithms this server can serve up.  This array also

 * configures details about the threads which will be created to run the

 * algorithms (e.g. stack sizes, priorities, etc.).

 */

Server.algs = [ 

    {name: "mycodec", mod: MYCODEC , threadAttrs: {

        stackMemId: 0, priority: Server.MINPRI + 3},

        groupId : 2,

    },

];

Server.cfg said:

 

/*

 *  ======== server.cfg ========

 *

 *  For details about the packages and configuration parameters used throughout

 *  this config script, see the Codec Engine Configuration Guide (link

 *  provided in the release notes) and the Codec Engine Package Documentation at:

 *  http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ce/latest_2_x/xdoc/index.html

 *  which references to Framework Components configurable modules under ti.sdo.fc.

 */

 

/* scratch groups */

var MAXGROUPS = 20;

var GROUP_2 = 2;

 

/*

 *  Configure CE's OSAL.  This codec server only builds for the BIOS-side of

 *  a heterogeneous system, so use the "DSPLINK_BIOS" configuration.

 */

var osalGlobal = xdc.useModule('ti.sdo.ce.osal.Global');

osalGlobal.runtimeEnv = osalGlobal.DSPLINK_BIOS;

 

/*

 *  Uncomment and modify the following line, to change the size of the circular

 *  trace buffer, if necessary.

 */

//osalGlobal.traceBufferSize = 32 * 1024;

 

 

/* configure default memory seg id to BIOS-defined "DDR2" */

osalGlobal.defaultMemSegId = "DDR2";

 

/* activate BIOS logging module */

var LogServer = xdc.useModule('ti.sdo.ce.bioslog.LogServer');

 

/*

 *  ======== Server Configuration ========

 */

var Server = xdc.useModule('ti.sdo.ce.Server');

/* The server's stackSize.  More than we need... but safe. */

Server.threadAttrs.stackSize = 16384;

 

/* The servers execution priority */

Server.threadAttrs.priority = Server.MINPRI;

 

/*

 * The optional stack pad to add to non-configured stacks.  This is well

 * beyond most codec needs, but follows the approach of "start big and

 * safe, then optimize when things are working."

 */

Server.stackSizePad = 9000;

 

utils.importFile("codec.cfg");

 

/* to link in debug/trace FC libs, uncomment one of these */

// xdc.useModule('ti.sdo.fc.global.Settings').profile = "debug");

// xdc.useModule('ti.sdo.fc.global.Settings').profile = "debug_trace");

// xdc.useModule('ti.sdo.fc.global.Settings').profile = "trace");

 

/*

 *  ======== DSKT2 (XDAIS Alg. memory allocation) configuration ========

 *

 *  DSKT2 is the memory manager for all algorithms running in the system,

 *  granting them persistent and temporary ("scratch") internal and external

 *  memory. We configure it here to define its memory allocation policy.

 *

 *  DSKT2 settings are critical for algorithm performance.

 *

 *  First we assign various types of algorithm internal memory (DARAM0..2,

 *  SARAM0..2,IPROG, which are all the same on a C64+ DSP) to "L1DHEAP"

 *  defined in the .tcf file as an internal memory heap. (For instance, if

 *  an algorithm asks for 5K of DARAM1 memory, DSKT2 will allocate 5K from

 *  L1DHEAP, if available, and give it to the algorithm; if the 5K is not

 *  available in the L1DHEAP, that algorithm's creation will fail.)

 *

 *  The remaining segments we point to the "DDRALGHEAP" external memory segment

 *  (also defined in the.tcf) except for DSKT2_HEAP which stores DSKT2's

 *  internal dynamically allocated objects, which must be preserved even if

 *  no codec instances are running, so we place them in "DDR2" memory segment

 *  with the rest of system code and static data.

 */

var DSKT2 = xdc.useModule('ti.sdo.fc.dskt2.DSKT2');

DSKT2.DARAM0     = "L1DHEAP";

DSKT2.DARAM1     = "L1DHEAP";

DSKT2.DARAM2     = "L1DHEAP";

DSKT2.SARAM0     = "L1DHEAP";

DSKT2.SARAM1     = "L1DHEAP";

DSKT2.SARAM2     = "L1DHEAP";

DSKT2.ESDATA     = "DDRALGHEAP";

DSKT2.IPROG      = "L1DHEAP";

DSKT2.EPROG      = "DDRALGHEAP";

DSKT2.DSKT2_HEAP = "DDR2";

 

 

/*

 *  Next we define how to fulfill algorithms' requests for fast ("scratch")

 *  internal memory allocation; "scratch" is an area an algorithm writes to

 *  while it processes a frame of data and is discarded afterwards.

 *

 *  First we turn off the switch that allows the DSKT2 algorithm memory manager

 *  to give to an algorithm external memory for scratch if the system has run

 *  out of internal memory. In that case, if an algorithm fails to get its

 *  requested scratch memory, it will fail at creation rather than proceed to

 *  run at poor performance. (If your algorithms fail to create, you may try

 *  changing this value to "true" just to get it running and optimize other

 *  scratch settings later.)

 *

 *  Setting "algorithm scratch sizes", is a scheme we use to minimize internal

 *  memory resources for algorithms' scratch memory allocation. Algorithms that

 *  belong to the same "scratch group ID" -- field "groupId" in the algorithm's

 *  Server.algs entry above, reflecting the priority of the task running the

 *  algorithm -- don't run at the same time and thus can share the same

 *  scratch area. When creating the first algorithm in a given "scratch group"

 *  (between 0 and 19), a shared scratch area for that groupId is created with

 *  a size equal to SARAM_SCRATCH_SIZES[<alg's groupId>] below -- unless the

 *  algorithm requests more than that number, in which case the size will be

 *  what the algorithm asks for. So SARAM_SCRATCH_SIZES[<alg's groupId>] size is

 *  more of a groupId size guideline -- if the algorithm needs more it will get

 *  it, but getting these size guidelines right is important for optimal use of

 *  internal memory. The reason for this is that if an algorithm comes along

 *  that needs more scratch memory than its groupId scratch area's size, it

 *  will get that memory allocated separately, without sharing.

 *

 *  This DSKT2.SARAM_SCRATCH_SIZES[<groupId>] does not mean it is a scratch size

 *  that will be automatically allocated for the group <groupId> at system

 *  startup, but only that is a preferred minimum scratch size to use for the

 *  first algorithm that gets created in the <groupId> group, if any.

 *

 *  (An example: if algorithms A and B with the same groupId = 0 require 10K and

 *  20K of scratch, and if SARAM_SCRATCH_SIZES[0] is 0, if A gets created first

 *  DSKT2 allocates a shared scratch area for group 0 of size 10K, as A needs.

 *  If then B gets to be created, the 20K scratch area it gets will not be

 *  shared with A's -- or anyone else's; the total internal memory use will be

 *  30K. By contrast, if B gets created first, a 20K shared scratch will be

 *  allocated, and when A comes along, it will get its 10K from the existing

 *  group 0's 20K area. To eliminate such surprises, we set

 *  SARAM_SCRATCH_SIZES[0] to 20K and always spend exactly 20K on A and B's

 *  shared needs -- independent of their creation order. Not only do we save 10K

 *  of precious internal memory, but we avoid the possibility that B can't be

 *  created because less than 20K was available in the DSKT2 internal heaps.)

 *

 *  Finally, note that if the codecs correctly implement the

 *  ti.sdo.ce.ICodec.getDaramScratchSize() and .getSaramScratchSize() methods,

 *  this scratch size configuration can be autogenerated by

 *  configuring Server.autoGenScratchSizeArrays = true.

 */

DSKT2.ALLOW_EXTERNAL_SCRATCH = false;

DSKT2.SARAM_SCRATCH_SIZES[GROUP_2] = 0x0000;

DSKT2.DARAM_SCRATCH_SIZES[GROUP_2] = 0x0000;

 

/*

 *  ======== RMAN (IRES Resource manager) configuration ========

 */

var RMAN = xdc.useModule('ti.sdo.fc.rman.RMAN');

RMAN.useDSKT2 = true;

RMAN.tableSize = 10;

RMAN.semCreateFxn = "Sem_create";

RMAN.semDeleteFxn = "Sem_delete";

RMAN.semPendFxn = "Sem_pend";

RMAN.semPostFxn = "Sem_post";

/* The lock/unlock/set/getContext functions will default to DSKT2 */