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

*.tcf redundancy?

Tim Klein
Intellectual 580 points

I have a *.tcf that was given to me (attached, renamed to *.txt), and if I understand the coding correctly, it seems to be heavily redundant/conflicting.  I'd like a second opinion from the group in order to slim it down to base code in prep for migration from DSP/BIOS to SYS/BIOS.

The Configuration Tool seems to record the last set of text data in this file in the properties for each value modified.  So, if TICKLEREADTEMPS_prd is set to .period = 100 and then later to .period = 250, the .period = 250 is the value I see in the Configuration Tool GUI.

Also, should I have added the lines for the .base and .len properties for L03SARAM and L47SARAM (they were previously not defined but showed up in the GUI)?

Thanks!

  • 0
    TI__Mastermind 37985 points

    Tim,
    the TCF file records all changes made in the GUI, so there is some redundant code if a certain parameter is changed several time in the GUI. You can remove all previous changes and retain only the last one. For example,

    bios.MEM.STACKSIZE = 0x0500;
    bios.MEM.STACKSIZE = 0x04a0;
    bios.MEM.STACKSIZE = 0x047f;
    bios.MEM.STACKSIZE = 0x0500;

    can be safely replaced with only

    bios.MEM.STACKSIZE = 0x0500;

    Each TCF script loads a platform at the beginning, ti.platforms.ezdsp28335 in your case. A platform sets default values for all parameters, including the base addresses and the lengths for memory objects (L03SARAM and L47SARAM among them). The TCF script contains only the statements that change these default values. If the default values that you see in the GUI work for you, you don't need to add any statements that change L03SARAM and L47SARAM properties.

  • 0 in reply to Sasha Slijepcevic
    Intellectual 580 points

    Thanks.  That makes sense for the items such as bios.MEM.STACKSIZE.

    I'm also interested to understand the redundancy for items such as:

    bios.PRD.instance("GLedBlink_PRD").fxn = prog.extern("GLedBlink_ISR");

    Are code lines such as this one above calling to execute or setting the function "GLedBlink_ISR" from my c-code?  I ask, because this tcf has the above line several times throughout.  If it is calling to execute, I'd understand that it was "blinking the light on the board" several times as it ran through the tcf.  Otherwise, if it is simply setting the function, then I'll have to start at the end of the code and work backwards to figure out what the last-settings for bios.PRD.instance("GLedBlink_PRD") are.  Some of the settings are identical [like .fxn=prog.extern("GLedBlink_SWI")], but in this case, there is at least one change from .period=500 to 250 and it should be 500 as my c-code comments state.

    I'd like to understand if the last setting is the one that is passed when compiled, such that if the order is set at 2, then 4, then 3, then 12, then 4 again, as the code is read from top to bottom, the only thing that will matter is that order = 4 from the last setting.  Correct?

    Is there no reason to set things like priority and order throughout the script multiple times?  It should only be set once (if at all) for each SWI, PRD, TSK, etc., correct?

  • 0 in reply to Tim Klein
    TI__Mastermind 37985 points

    Setting up the functions works the same way, only the final value matters. The TCF scripts generates a C file based on the content of all parameters at the end of the script, but it does not call any of your functions.
    So yes, it's a good idea to work backward and remove all the statements that set bios.PRD.instance("GLedBlink_PRD").fxn, except the last one. Same goes for order, priority, etc.