• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 102 subscribers
  • Views 620 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.

AM3352: 64-bit timestamp delay in RTOS

Sh.Sasaki
Guru 13625 points

Part Number: AM3352
Other Parts Discussed in Thread: SYSBIOS, AM3357

Hi all,

Please teach me about Timestamp_get64 of SYSBIOS as follows.

How many steps will it take from this API call to storing Timestamp as an argument?

I'd like to know the delay from calling to storing.

Also, when reading values with this function, will this function copy upper and lower 32 bits each?

Best regards,

Sasaki

  • 0
    TI__Guru**** 161600 points
    Hi,

    I've notified the RTOS team. Please share which SDK version are you using?

    Best Regards,
    Yordan
  • 0
    TI__Intellectual 1060 points

    Hi Sasaki,

    If you could provide the SDK version you are using that would be helpful. What optimization level are you compiling at? This can affect the number of instructions required.

    The function will store the result using the pointer you provide. If the target does not support 64 bit timestamps, the hi field will be zero.


    Thanks,

    Sean

  • 0 in reply to Sean Oliver28
    Guru 13625 points

    Hi Sean-san,

    Thank you for your reply.

    Sean Oliver28 said:

    If you could provide the SDK version you are using that would be helpful. What optimization level are you compiling at? 

    I will confirm with my customer. The environment currently known is below.

    • am3357
    • CCS6.2.0.00050
    • SYSBIOS 6.35.4.50

    Sean Oliver28 said:

    If the target does not support 64 bit timestamps, the hi field will be zero.

    The target is AM3357.
    How can I check if the target supports 64 bit timestamps?

    Best regards,

    Sasaki

  • 0 in reply to Sh.Sasaki
    TI__Intellectual 1060 points

    Hi Sasaki-san,

    Here is the API documentation page for Timestamp provider for you BIOS version:

    http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/sysbios/6_35_04_50/exports/bios_6_35_04_50/docs/cdoc/ti/sysbios/family/arm/a8/TimestampProvider.html

    From that link:

    The source of the timestamps for the A8 TimestampProvider is the A8's internal PMC counter which counts CPU cycles.
    As this counter is only 32 bits in length, provision is made in the get64() API to test if an overflow has occurred since the last invocation of get64() and compensate the return value accordingly.
    As it is possible for the 32 bit counter to roll over more than once between successive get64() calls, it is up to the user to call the get64() API often enough to guarantee coherency in successive timestamps. A simple mechanism to do this would be to add a Clock function that simply invokes get64():
      var Clock = xdc.useModule('ti.sysbios.knl.Clock');
  var TimestampProvider = xdc.useModule('ti.sysbios.family.arm.a8.TimestampProvider');
  var clockParams = new Clock.Params();
  clockParams.period = 1;     // call every Clock tick
  Clock.create($externModFxn(TimestampProvider.get64), 1, clockParams);

    As for how many instructions this would take, you can use the 'Disassembly View' in the debug mode to see the generated assembly to get a rough idea.

    I believe there is a benchmark example which may assist in getting more precise timing measurements, I will ask my colleagues and get back when I know more.

    Thanks,

    Sean

  • 0 in reply to Sean Oliver28
    Guru 13625 points
    Hi Sean-san,

    Thank you for your support!
    I will check it!

    Best regards,
    Sasaki