• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 96 subscribers
  • Views 344 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Configuration Parameters

Matt Clarkson
Intellectual 920 points

I want to add a configuration parameter to my codec so that if I do this in my server .cfg:

 

MY_CODEC = xdc.useModule(codecs.my_codec.MY_CODEC);

MY_CODEC.maxArraySize = 15;

 

And use this as a constant in my_codec.c

 

unsigned int array[MY_CODEC.maxArraySize];

 

I have gone through the RTSC primers on http://rtsc.eclipse.org and have looked at how DMAN3, DSKT2, etc do the configuration parameters.  The RTSC primers look so simple but I cannot get it to work.

package.xdc

package codecs.my_codec {

    module MY_CODEC;

}

MY_CODEC.xdc (note in the RTSC primers there is no metaonly but i have to have it as inherits IVIDENC but DMAN3, etc have meta only and they can configure)

metaonly module VCA_TRACK_ENC inherits ti.sdo.ce.video.IVIDENC

{

    config  UInt maxArraySize = 5; // Default Value

}

server.cfg

MY_CODEC = xdc.useModule(codecs.my_codec.MY_CODEC);

MY_CODEC.maxArraySize = 15;

my_codec.c

unsigned int array[MY_CODEC.maxArraySize];

  • 0
    Intellectual 920 points

    For example HDINTC has some configuration parameters:

    /dvsdk_2_00_00_22/framework_components_2_23_01/packages/ti/sdo/fc/hdintc/HDINTC.xdc

    metaonly module HDINTC {

        config UInt interruptVectorId_0;

        [...]

    }

    And the following:

    /dvsdk_2_00_00_22/framework_components_2_23_01/packages/ti/sdo/fc/hdintc/hdintc.h

    /**

     *  @brief      The module configuration structure for HDINTC implementation.

     *

     *  @remarks    It is set at design time by the system integrator to ensure

     *              the interrupt lines that are used to process HDVICP generated

     *              interrupts are not mapped by any other interrupt event.

     *              Additionally, the HDVICP event-numbers are configurable to

     *              support different SoCs.

     */

    typedef struct HDINTC_Params {

        /**

         *  @brief      Interrupt Vector 0

         *

         *  @remarks    Map this to an unused interrupt vector ID

         */

         int interruptVectorId_0;

         [...]

    } HDINTC_Params;

    /**

     *  @brief      Default module configuration structure (defined in hdintc.c).

     */

    extern HDINTC_Params HDINTC_PARAMS;

     

    I've been searching through the files (as this seems the simplest framwork example of configuration parameters) but can't work out how the HDINTC_PARAMS gets set by the configurator or the program?

     

  • 0 in reply to Matt Clarkson
    TI__Genius 17205 points

    The quick tip that'll probably unblock you - there's a template file (*.xdt) that is defined in the .xdc file with the @Template directive.  That template file (.xdt) then gets energy to create code that gets dropped into the big, generated .c file that falls out during the .cfg step.

    FYI, your custom config params can also be used (with or without a template) in the package.xs file - for example in the close() or getLibs() fxns to help establish conditional dependencies or return different libraries based on config.

    I can cook up a longer reply to tell you why generating _global_ symbols that your XDAIS alg depends on may be A Bad Thing To Do... but I'm nor sure whether you want an audit or not.  :)  In general, global are bad b/c you can get into trouble when creating multiple instances of your XDAIS alg.  The preferred method for instance-specific configuration is to provide them at runtime via possibly extended create params.

    Chris

  • 0 in reply to Chris Ring
    Intellectual 920 points

    Thanks for the tip, Chris, great answer.

    I've been using the custom config params in package.xs to validate them.

    The idea behind using the configuration parameters is that we currently use ~10MB of memory for the codec due to worst case memory allocation for megapixel.  However, we would like to use the configuration parameters to define what situation the codec will be used in a allocate less memory when it is not needed.  This application should be fine for multiple instances as they will all need to allocate the same memory.

    We already use extended create params, but the memory is already allocated.  Correct me if we can use these to reduce the memory footprint.

    I am happy to hear how you would go about this problem - audit me! :)

  • 0 in reply to Matt Clarkson
    TI__Genius 17205 points

    I think the audit thread is going on over here:

    http://e2e.ti.com/support/embedded/f/356/p/61537/220723.aspx

    :)

    Chris