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.

Time delay with Task_sleep API

Other Parts Discussed in Thread: CC2640, SYSBIOS

Hi,

I am using CC2640, BLE stack 2.2.1, TIRTOS 2.13.00.06, CCS6.1.2.

In my SimpleBLEPeripheral .cfg file, I have the tick period set to 10 us.

When I try:

time1 = Clock_getTicks();
            Task_sleep(10);    
            time2 = Clock_getTicks();
            System_printf("\nTime difference = %lu", (ULong) (time2-time1));
            System_flush();

I see the time difference being printed out is 18 or 19. Does this mean the delay

is 180 us or 190 us?

If I needed a more exact delay, what is the best way to set it?

Thanks,

Priya

 

  • Priya,

    Yes, if you are seeing values of 18/19 then that corresponds to 180/190 us.  Versus the 100 us you were probably expecting. 

    There are a lot of details that I won’t get into, but briefly…  Task_sleep() will create a Clock object for implementing the timeout.  On this device Clock uses the RTC, which resides in a different timing domain, running at 32KHz.  There is a cross-domain synchronization mechanism, plus a setup time for configuring the soonest possible interrupt event from the RTC.  This all means that the soonest you’ll be able to start a new Clock object, and have it trigger and run its function on the M3, is typically on the order of 120 us.  There are some other factors too, e.g., the phasing of when the Clock object is started versus the 32KHz update rate of the RTC, how many other objects are in Clock’s queue of objects, if any of them are simultaneously timing out, and some thread scheduling delays to get back to your function, which can contribute additional delays/jitter.

    So… if you need a 100us trigger at high accuracy, you won’t be able to get that from the Clock module (or other modules that have timeouts via Clock ticks).  To achieve that you might be able to create a one-shot Timer, using either the NVIC’s SYSTICK counter (ti.sysbios.family.arm.m3.Timer), or possibly one of the general purpose timers (ti.sysbios.family.arm.lm4.Timer).  Timer functions are run in ISR context, so there won't be scheduling delays that might occur with Clock objects, or posting a Semaphore, etc.  If you need some assistance with configuring this let me know…

    Regards,
    Scott

  • Hey Scott, I found your response very helpful. Could you elaborate more on how you would set up one shot Timer with SYSTICK in order create delays as small as 1us? Would it be something like this: 

    Timer_Handle timer;
    Semaphore_Handle sem;
    
    void hwiFxn(UArg arg){ Semaphore_post(sem);}
    
    main() {
       Timer_Params timerParams;
       Timer_Params_init(&timerParams);
       uint16 time1, time2;
    
       timerParams.period = 1; // will this be 1 us??
       timer = Timer_create(Timer_ANY, hwiFxn, &timerParams, &eb);
       sem = Semaphore_create(0, NULL, &eb);
    
       BIOS_start();
    
       while(1) {
         time1 = Timer_getCount();
         Semaphore_pend(sem, BIOS_WAIT_FOREVER);
         time2 = Timer_getCount();
         System_printf("\nTime difference = %lu", (ULong) (time2-time1));
         System_flush();
       }
    }

    I cobbled that code together from reading through the SYS/BIOS User guide and API Reference... I'll try to implement it on the CC2640 and see if it doesn't mess up normal BLE operation... I plan to run it in a separate Task from the SimpleBLEPeripheral Task and at a lower priority such that the pending of the Semaphore (sem) will allow the BLE operations to run, albeit ever so briefly. 

  • Hi Richard,

    This thread is closed. Can you please open a new thread and post your questions along with the device name and software versions that you are using?

    Thanks,
    Vikram