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.

GEL in a multicore environment



It appears that GEL provides little support for multiprocessor/multicore environments.

In particular, it seems that there is no way to produce and use a GEL script that can act on several cores, for example, a script that contains a single GEL function that loads several cores (appears possible), sets a breakpoint on each (appears impossible) and starts them all running (appears impossible).

Having to load one GEL file per core and execute each separately is tedious and error-prone.

Have I misread the documentation or is GEL really limited to single-processor/core use?

  • Hi Peter,

    Check the DSS - http://processors.wiki.ti.com/index.php/Debug_Server_Scripting#Multiple_Debug_Sessions_for_Multi-core_Debug

    Thanks,

    HR

  • Peter Robertson said:
    Have I misread the documentation or is GEL really limited to single-processor/core use?

    Yes. Most of GEL's scope is mostly limited to the a single debug context (ex. CPU). That is how GEL is designed.

    As HRi mentioned, check out DSS. DSS is a true scripting environment that addresses many of GEL's limitations with regards to automation.

    Thanks

    ki

  • Thanks, that is almost exactly what I need.

    It is a pity that there are some unfortunate properties about scripting, particularly that there seems to be no way to remove additions to the scripting console without restarting CCS, a tedious process at best.

  • There is a GEL builtin function GEL_EvalOnTarget() for evaluation a GEL expression/function on a different target.

    GEL_EvalOnTarget()

    Evaluate a GEL expression on a target

    Syntax

    GEL_EvalOnTarget( target_path_name, expression );

    Parameters

    target_path_name is the path name of the target on which the expression will be evaluated

    expression is the expression to be evaluated

    Description

    The GEL_EvalOnTarget function evaluates the expression on the target whose path name is target_path_name. 

    Regards,

    Raymond

  • Peter Robertson said:
    particularly that there seems to be no way to remove additions to the scripting console without restarting CCS,

    Assuming you are using loadJSFIle to load your custom scripts to the console, you can use unloadJSFile to remove them.

    Thanks

    ki

  • Two observations about unloadjsfile:

    1. The documentation states: "unloadJSFile unload a JavaScript file or all files within a directory. You will need to restart CCS to completely unload the script from memory."
    2. Actually trying this gives the following results:

    js:> loadjsfile("E:\temp\JS\dual.js")

    js:> unloadjsfile("E:\temp\JS\dual.js")
    "E:\temp\JS\dual.js" (The system cannot find the file specified)
    js:>

  • Sorry, you are correct. The unloadJSFile command is only for scripts that was loaded with the autoload parameter set to true. Otherwise the script is unloaded when the scripting console is closed.

    And yes, all you need to do is restart the scripting console - NOT all of CCS.

    Thanks

    ki

  • Are you saying that the documentation is wrong when it states,

    "You will need to restart CCS to completely unload the script from memory."?

  • I have just tried closing the scripting console and reopening it: nothing changes.

  • What version of CCS are you using?

  • Peter Robertson said:

    Are you saying that the documentation is wrong when it states,

    "You will need to restart CCS to completely unload the script from memory."?


    This behavior may have existed in old versions of CCS but have since changed so it could out of date depending on your CCS version. Try running the help command on the unloadJSFile command:

    js:> help unloadJSFile

    Description: Unload a JavaScript file or all JavaScript files belong to the directory, the file(s) will be unloaded after the console view restart. This command will fail if the JavaScript(s) wasn't loaded with the optional "store" parameter.
    Syntax: unloadJSFile(file)
    Arguments:
      path - the JavaScript file or a directory.

  • I am using  Version: 5.5.0.00077

  • In my CCSv5.5 environment I confirmed any script not loaded with the store argument is unloaded when I restart the scripting console.

  • Please describe exactly what you mean by "restart the scripting console".

    Closing the console and reopening it from the View menu does not have the effect you describe.

  • Peter Robertson said:
    I am using  Version: 5.5.0.00077

    hmm... same version I have.

    Can you provide a test case? basically I'm looking for a js script and the steps/commands you are taking in the console (loading it, confirming it is loaded, restarting the console).

    Also note that you can have multiple instances of the console open in different perspectives. Make sure they are all closed.

  • Try this.

    1. I have a file "e:/temp/test.js" containing:
      function test() {
         print("testing");
      }
    2. Open CCS
    3. View/Scripting Console
    4. Give the command: test - this fails as expected
    5. Give the command:  loadjsfile("e:/temp/test.js");
    6. Give the command: test - it prints the message
    7. Close the scripting console
    8. Re-open using View/Scripting Console.
    9. The previous contents are displayed.
    10. Give the command: test
    11. It's still valid and prints the expected message.
  • Thanks Peter.

    I can reproduce the issue. Turns out that my test cases had an flaw in it.

    Also, I confirmed that you have been right all along. To completely unload the script, you need to restart CCS. Restarting the Scripting Console by itself is not enough. Sorry .

    ki

  • No problem.

    Perhaps you could suggest that a mechanism to remove scripts should be implemented?

    Having to restart CCS sounds like a design flaw.

    Peter

  • It certainly is a pain it the butt.The way the console is implemented and how Eclipse works, there was not a clean way to easily remove the content from a loaded script. Hopefully this can be improved in the future. Sorry.

  • Such is life.

    Eclipse is yet another example of the complexity cult that is leading us towards a mighty train crash of a disaster in the future.

    Thanks for your support.