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.

Too Long Time to Execute an Empty Cycle

Other Parts Discussed in Thread: SYSBIOS

I am just a beginer with SYS/BIOS and I have run the exec graph. I have noticed that the exmpty function below takes (380000ns) in my Delfino F28335. The clock is correctly set to 150MHZ. I assume an exmpty function can be executed in less than 100ns. Can anybody explain what is wrong?

The function is:

Void taskFxn(UArg a0, UArg a1)

{

    System_printf("enter taskFxn()\n");

    System_printf("exit taskFxn()\n");

}

The exec graph is below:

 

  • Nezar,

    It may be that the System provider (doing the backend of the System_printf()) is doing I/O with CCS that is causing this latency you are seeing.  

    There is some description of the System provider options here: http://rtsc.eclipse.org/docs-tip/Using_xdc.runtime_System

    Is your application using SysStd?

    Thanks,
    Scott

  • My system does not use SysStd. It uses SysMin instead. Iam using XDS100v1USB emulator and I wounder if it has something to do with the latency.I have attached the source code for the .cfg thank you for your reply.

     

    var Defaults = xdc.useModule('xdc.runtime.Defaults');

    var Diags = xdc.useModule('xdc.runtime.Diags');

    var Error = xdc.useModule('xdc.runtime.Error');

    var Log = xdc.useModule('xdc.runtime.Log');

    var LoggerBuf = xdc.useModule('xdc.runtime.LoggerBuf');

    var Main = xdc.useModule('xdc.runtime.Main');

    var Memory = xdc.useModule('xdc.runtime.Memory')

    var SysMin = xdc.useModule('xdc.runtime.SysMin');

    var System = xdc.useModule('xdc.runtime.System');

    var Text = xdc.useModule('xdc.runtime.Text');

    var BIOS = xdc.useModule('ti.sysbios.BIOS');

    var Clock = xdc.useModule('ti.sysbios.knl.Clock');

    var Swi = xdc.useModule('ti.sysbios.knl.Swi');

    var Task = xdc.useModule('ti.sysbios.knl.Task');

    var Semaphore = xdc.useModule('ti.sysbios.knl.Semaphore');

    var Hwi = xdc.useModule('ti.sysbios.family.c28.Hwi');

    var Boot = xdc.useModule('ti.catalog.c2800.init.Boot');

    var Agent = xdc.useModule('ti.sysbios.rta.Agent');

    var Load = xdc.useModule('ti.sysbios.utils.Load');

    /*

    * Program.argSize sets the size of the .args section.

    * The examples don't use command line args so argSize is set to 0.

    */

    Program.argSize = 0x0;

    /*

    * Uncomment this line to globally disable Asserts.

    * All modules inherit the default from the 'Defaults' module.  You

    * can override these defaults on a per-module basis using Module.common$.

    * Disabling Asserts will save code space and improve runtime performance.

    Defaults.common$.diags_ASSERT = Diags.ALWAYS_OFF;

    */

    /*

    * Uncomment this line to keep module names from being loaded on the target.

    * The module name strings are placed in the .const section. Setting this

    * parameter to false will save space in the .const section.  Error and

    * Assert messages will contain an "unknown module" prefix instead

    * of the actual module name.

    Defaults.common$.namedModule = false;

    */

    /*

    * Minimize exit handler array in System.  The System module includes

    * an array of functions that are registered with System_atexit() to be

    * called by System_exit().

    */

    System.maxAtexitHandlers = 4;      

    /*

    * Uncomment this line to disable the Error print function. 

    * We lose error information when this is disabled since the errors are

    * not printed.  Disabling the raiseHook will save some code space if

    * your app is not using System_printf() since the Error_print() function

    * calls System_printf().

    Error.raiseHook = null;

    */

    /*

    * Uncomment this line to keep Error, Assert, and Log strings from being

    * loaded on the target.  These strings are placed in the .const section.

    * Setting this parameter to false will save space in the .const section.

    * Error, Assert and Log message will print raw ids and args instead of

    * a formatted message.

    Text.isLoaded = false;

    */

    /*

    * Uncomment this line to disable the output of characters by SysMin

    * when the program exits.  SysMin writes characters to a circular buffer.

    * This buffer can be viewed using the SysMin Output view in ROV.

    SysMin.flushAtExit = false;

    */

    /*

    * The BIOS module will create the default heap for the system.

    * Specify the size of this default heap.

    */

    BIOS.heapSize = 0x800;

    /* System stack size (used by ISRs and Swis) */

    Program.stack = 0x100;

    /* Circular buffer size for System_printf() */

    SysMin.bufSize = 0x200;

    /*

    * Create and install logger for the whole system

    */

    var loggerBufParams = new LoggerBuf.Params();

    loggerBufParams.numEntries = 32;

    var logger0 = LoggerBuf.create(loggerBufParams);

    Defaults.common$.logger = logger0;

    Main.common$.diags_INFO = Diags.ALWAYS_ON;

    System.SupportProxy = SysMin;

    Boot.pllOSCCLK = 30;

    BIOS.cpuFreq.lo = 150000000;

  • Nezar,

    OK, I will have to check to see if we have any benchmarks on expected System_printf() cycles. 

    You expect an empty Task function to be executed in less than 100nsec.  What is this number based upon?

    Have you tried removing the System_printf() calls to time an empty function?

    Scott

  • Scott,

    I have remove the fprint() statment the time is 9000ns. I have also run the function again with the fprint after initializing flash to the min wait state. The new execution time is 99,000ns. Do you think that this is resonable for a slow connection (XDS100V1 , 12Mbit/s)

    Regards,

    Nezar

  • Nezar,

    I looked and didn’t find any good benchmarking of System_printf() to compare to.  Also, the cycles spent in the System_printf() function will vary based upon the particular formatting. 

    If you are using SysMin the text will be buffered until later flushed to the debugger, so JTAG speed should not matter for what you are measuring.

    From your original graph it didn’t look like you were having any interrupt preemption.  But if you’ve changed the test, that is one thing that could contribute to the timings.

    If you are concerned about latency and are finding System_printf() too slow, have you looked at using Logging instead?

    Scott

  • Scott,

    Thank you very much I will try it with logging.

    Regards,

    Nezar