cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
joe306
Scholar
Scholar
385 Views
Registered: ‎12-07-2018

High Resolution Sleep Function for ARM Core

Jump to solution

Hello, I am using the Zynq Ultrascale+ MPSOC and I am using the usleep_A53(usec) function. I am using the usleep_A53 to toggle a GPIO pin that is directly connected to the PS Side.

When I set the delay for 1usec, I measure 1.6usec delay on the o-scope. If I try 20usec I measure 20.6usec delay.

Here is the actual code for the sleep function:

/*****************************************************************************/
/**
*
* This API gives a delay in microseconds
*
* @param useconds requested
*
* @return 0 if the delay can be achieved, -1 if the requested delay
* is out of range
*
* @note None.
*
****************************************************************************/
int usleep_A53(unsigned long useconds)
{
#if defined (SLEEP_TIMER_BASEADDR)
Xil_SleepTTCCommon(useconds, COUNTS_PER_USECOND);
#else
sleep_common((u32)useconds, COUNTS_PER_USECOND);
#endif

return 0;
}

When I step through the function it only executes the "sleep_common" function and not the Xil_SleepTTCCommon function.

How can I get the Xil_SleepTTCCommon to execute?

Perhaps Xil_SleepTTCCommon will be a better function to use if I was a high-resolution delay.

If anyone can help me please let me know.

I want to be able to delay with as little as possible overhead. It looks like I'm always getting 600ns of delay.

 

Thank you

Tags (2)
0 Kudos
1 Solution

Accepted Solutions
joe306
Scholar
Scholar
291 Views
Registered: ‎12-07-2018

Hello, below is a chart showing the measured delay of an GPIO pin that is directly connected to the PS side. I wrote a little piece of code to toggle the pin high then low. The high time is the same as the low time.

DelayTime.jpg

I was expecting better results.

View solution in original post

0 Kudos
3 Replies
watari
Professor
Professor
375 Views
Registered: ‎06-16-2013

Hi @joe306 

 

I'm not sure your situation and limitation. And it's not that it's directly answer, but I reply it.

 

Do you consider Cortex R5 and/or PMU to reduce this delay ?

It seems the performance penalty to pay context switch on Cortex A53.

In like this case, you should use OCM or TAM (*1) instead of DRAM.

 

*1)

https://www.xilinx.com/support/documentation/user_guides/ug1085-zynq-ultrascale-trm.pdf#page=92

 

Would you consider them ?

 

Hope this helps.

 

Best regards,

joe306
Scholar
Scholar
359 Views
Registered: ‎12-07-2018

Hello, thank you for responding to my post. My goal is to determine how fast can I toggle a PS connected pin and also how fast can I can toggle a PL connected pin via the A53 and R5. Right now I'm only toggling a PS GPIO pin, where the GPIO pin is directly connected to the PS side. I'm noticing that when I use the usleep_A53 function I always get 600nsec extra. For example when I set the toggle to be 1us high and 1usec low. I measure on the o-scope 1.6usec. I don't know if this 600nsec is due to the usleep_A53 function of something else. In what you are describing I'm a little lost where to proceed. I see OCM as where extra data could be stored and quickly accessed. So can you expand on what you are suggesting.

By the way the input PS_REF_clk is 33.33Mhz and the R5 is running at 533Mhz and the A53 cores are running at 1.2GHz.

PS_Clock.jpg

0 Kudos
joe306
Scholar
Scholar
292 Views
Registered: ‎12-07-2018

Hello, below is a chart showing the measured delay of an GPIO pin that is directly connected to the PS side. I wrote a little piece of code to toggle the pin high then low. The high time is the same as the low time.

DelayTime.jpg

I was expecting better results.

View solution in original post

0 Kudos