CC3200: Delay in seconds/msec/microsecond

Hi Vipin,

If you need accurate delays, suggest you use HW timers. Else you may use UtilsDelay itself and have a wrapper logic that does the translation from usecs/msecs/secs into clock ticks.

Best regards,

Naveen

Hi Naveen,

I need a wrapper approach as Hardware timers result in to interrupts and breaks my code flow. I need a simple sleep/delay in msec/sec. Your suggestion for wrapper logic is good and I thought of that before posting the query but the argument to UtilsDelay is not the tick I believe. Please correct me if I am wrong. Argument to UtilsDelay is loop count and one loop count takes 3 cycles. Does this mean loop take 3 ticks? Are cycle in below comment means clock tick?

Comment from utils.c file

//*****************************************************************************
//
//! Provides a small delay.
//!
//! \param ulCount is the number of delay loop iterations to perform.
//!
//! This function provides a means of generating a constant length delay.  It
//! is written in assembly to keep the delay consistent across tool chains,
//! avoiding the need to tune the delay based on the tool chain in use.
//!
//! The loop takes 3 cycles/loop.
//!
//! \return None.
//
//*****************************************************************************

In http://processors.wiki.ti.com/index.php/CC32xx_Power_Management_Framework, it said:

• Clock tick at 80 Mhz.

So MAP_Utilsdelay(8000000) may delay ~0.3sec or ~0.5sec as you mean. 

But in oob example, Why MAP_UtilsDelay(8000000) is mean ~10sec?

//
// Wait ~10 sec to check if connection to specifed AP succeeds
//
while(!(IS_CONNECTED(g_ulStatus)) || !(IS_IP_ACQUIRED(g_ulStatus)))
{
#ifndef SL_PLATFORM_MULTI_THREADED
_SlNonOsMainLoopTask();
#endif
MAP_UtilsDelay(8000000);
if(g_usConnectIndex >= usConnTimeout)
{
break;
}
g_usConnectIndex++;
}

Hi XiangBing,

"Clock tick at 80 Mhz" is correct information.

Further, in the OOB example you will find that there is a retry count and then timeout. So it means that the loop will execute usConnTimeout number of times. Hence the time it takes is actually -  (usConnTimeout * MAP_UtilsDelay(8000000)). This may have been approximated and mentioned in the comment.

Best regards,

Naveen

I am using following macro. Its not exact but close enough (at least for my application)

#define SEC_TO_LOOP(x)        ((80000000/5)*x)

Hi Vipin,

I am closing the thread, if issue still exist please open a new thread and add a link to this one for reference.

Best regards,

Naveen 

Hi Naveen,

can you tell me why it takes 5 clockticks/loop when it execute from RAM,how to calculate it.

the code follows:

#if defined(ewarm) || defined(DOXYGEN)
void
UtilsDelay(unsigned long ulCount)
{
__asm(" subs r0, #1\n"
" bne.n UtilsDelay\n");
}
#endif

#if defined(gcc)
void __attribute__((naked))
UtilsDelay(unsigned long ulCount)
{
__asm(" subs r0, #1\n"
" bne UtilsDelay\n"
" bx lr");
}
#endif

//
// For CCS implement this function in pure assembly. This prevents the TI
// compiler from doing funny things with the optimizer.
//
#if defined(ccs)
__asm(" .sect \".text:UtilsDelay\"\n"
" .clink\n"
" .thumbfunc UtilsDelay\n"
" .thumb\n"
" .global UtilsDelay\n"
"UtilsDelay:\n"
" subs r0, #1\n"
" bne.n UtilsDelay\n"
" bx lr\n");
#endif

would it be reasonable to have all these intricacies handled in SDK functions (perhaps, driverlib/utils) instead of having them defined and re-defined all over the place? notably, we have example/interrupt/systick_if which seems to go to some length in doing this, but it's under "example", so not really part of the api, and the real rub is - it defines UTUtilsDelay which clashes with driverlib/utils and takes its argument in microseconds.