• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 98 subscribers
  • Views 433 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.

XDC Module data clarification

Nick Borton
Genius 3595 points
Other Parts Discussed in Thread: SYSBIOS

Hello,

I'm hoping someone can point me to a document, or explain the differences between the different places data can reside inside XDC Modules. I just recently became aware the module wide confiuration data can be altered "globally". There are also Module_State and Instance_State structs which can be used as well. In particular, I am interested in the difference between config data and Module_State data.

Thanks!

  • 0
    TI__Mastermind 45025 points

    Hi norton256,

    The module state reflects the state of the module itself, whereas the instance state reflects the state of a particular instance of that module.  In general, both of these state structures are used to store internal values but can also be used to store values that come from a given configuration parameter.

    For example, the SYS/BIOS Task module contains a set of properties that the user can change (configuration paramters of the Task module).  These properties are global to the Task module and all instances of the Task module.

    If a Task instance is created, each instance will have a set of configuration properties associated with it (see Task.xdc and search for "instance:" to see all instance properties).  The Instance_State may contain those properties as well as other internally used ones.

    Typically, the config params are those properties of a module or instance that are exposed to the user and that the user is allowed to change or tune.

    Have you seen RTSC-pedia? (http://rtsc.eclipse.org/docs-tip/Main_Page)

    This website has a module primer guide.  In particular:

    http://rtsc.eclipse.org/docs-tip/RTSC_Module_Primer/Lesson_8

    You may want to start at the beginning though.

    Steve

  • 0 in reply to Steven Connell
    Genius 3595 points

    I have gone through all the primers at least once, some maybe a year ago now. I guess I was under the impression that config values were meta only, and that they needed to be copied in the init function in the xs script into the Instance_State. But am I understanding correctly that instance config variables exist in C somewhere? How are they named, or accessed?

    The primers are a good start, but there are some fundamental low level detailed links which I think are missing.

  • 0 in reply to Nick Borton
    TI__Mastermind 45025 points

    Yes, config variables will get converted to C code (as long as the module itself is not meta only).  The variable will be named based upon the package path of the package that the module lives in.

    For example, the Task module's config param "defaultStackSize" will be:

    ti_sysbios_knl_Task_defaultStackSize

    norton256 said:
    I guess I was under the impression that config values were meta only, and that they needed to be copied in the init function in the xs script into the Instance_State

    There is a way to specify internal variables, which are meta only info and won't be generated in the C code.  Then, in the *.xs script, you can update those variables as needed.

    Steve

  • 0 in reply to Steven Connell
    Genius 3595 points

    So for a particular instance of a module, how do you access it's instance config values in C?

    Or a better question: Is there an XDCSpec to C translation table or quick reference?

  • 0 in reply to Nick Borton
    TI__Mastermind 37985 points

    Here is the table that partly answers your questions. However, it's still a work in progress. 

    Instance configuration parameters are not accessible in C. Only module configuration parameters have their C representation. Steve gave you an example of 'defaultStackSize' in Task, which is a module configuration parameter. However, if there are 10 statically created Task instances, their instance config parameter are not automatically represented in C. But, a module can decide to keep copies of some or all of instance configuration parameters in its Instance_State. Task copies most of the instance configuration parameters to its Instance_State.

    This is done to save space. There is no much use in target code for instance configs for staticaly created instances. Module configuration parameters are different, it's likely that dynamically created instances could reference module configs, and there is only one copy of module configs anyway, so it's limited how much space can be used by them.

    What's available is a structure with default values of the instance configuration parameters. However, you never need to access that structure directly, so it does not have a user-friendly name.