AIC23 | C5509 | CCS | CSL | EMIF | EVM | GEL | GPIO | HPI | Interfacing | JTAG | McBSP | OMAP | Omap15 | OMAP59 | RTDX | SDRAM | TMS320VC5509 | USB | XDS5

Group members,

I have a basic understanding question concerning real-time timing more
specifically TSK_sleep() function.  Here a simple point-form outline of
the test application:

- Single task with priority 2   (only task explicitly created by me i.e.
There's obviously the other tasks implicitly created by the DSP/BIOS)

- timer 0: 100us/int               (clock manager properties, I'm
assuming the clock generator is the tick generator)

- TSK_sleep(5)                   (I'm calling this function within the
task I created to produce a 500us delay -- the real application (not
this test application) is multi-tasked)

I would be expected a 500us delay instead I get a 1.1ms delay.   Of
course, the TSK_sleep(5) call is the minimum delay, but an overhead
600us is not what I expected.

Why am I not seeing about 500us?  What could possibly be accounted for
that 600us extra overhead?  

To insert a guaranteed delay of 500us, without blocking the rest of a
multi-task application is using a TSK_sleep the appropriate way to go
about it.  Should I simply let the task run and only poll the tick
count.

I thank you in advance for any help or comment.

Daniel

______________________________
New Code Sharing Section now Live on DSPRelated.com. Learn about the Reward Program for Contributors here.



(You need to be a member of c55x -- send a blank email to c55x-subscribe@yahoogroups.com )

Daniel-
> I have a basic understanding question concerning real-time timing more
specifically
> TSK_sleep() function.  Here a simple point-form outline of the test
application:
>
> - Single task with priority 2   (only task explicitly created by me i.e. 
There’s
> obviously the other tasks implicitly created by the DSP/BIOS)
>
> - timer 0: 100us/int               (clock manager properties, I’m assuming
the
> clock generator is the tick generator)
>
> - TSK_sleep(5)                   (I’m calling this function within the
task I
> created to produce a 500us delay -- the real application (not this test
> application) is multi-tasked)
>
> I would be expected a 500us delay instead I get a 1.1ms delay.   Of course,
the
> TSK_sleep(5) call is the minimum delay, but an overhead 600us is not what
I
> expected.
>
> Why am I not seeing about 500us?  What could possibly be accounted for that
600us
> extra overhead?
>
> To insert a guaranteed delay of 500us, without blocking the rest of a
multi-task
> application is using a TSK_sleep the appropriate way to go about it. 
Should I
> simply let the task run and only poll the tick count.
>

How did you measure the delay?  There are lots of I/O methods in CCS that are
"Heisenberg" -- they disturb the thing you're trying to measure.

Also, what is the *measured* period of your system timer (TIMER0)?  I.e. not
assuming
that what you see in DSP/BIOS configuration is what's actually happening.  My
guess
is that if you measured your tick generator using a GPIO signal on a dig scope,
you'd
see about 200 usec.

-Jeff

______________________________
New Code Sharing Section now Live on DSPRelated.com. Learn about the Reward Program for Contributors here.



(You need to be a member of c55x -- send a blank email to c55x-subscribe@yahoogroups.com )

Actually this is pretty much what I have observed, without explicitely
toggling specifically on the tick gen.  The 1.1 ms delay I'm "seeing"
was measured with an oscilloscope by toggling a GPIO pin, but I did have an
emulator hooked up to my card. The GPIO pin is set before the TSK_sleep(5) and
cleared after, within an explicitely created single task of priority 2
application. I may then infer from the CCS effect you are referring to, that
un-hooking the emulator should remove any "non real-time" effect.  I
should then get an appoximate 500us (i.e. more or less 1 % range not +/- 100%
range) with the task sleep function.  Am I hearing you right.

Greatly appreciated,

Daniel

Daniel-
>>  I have a basic understanding question concerning real-time timing more
specifically
>>  TSK_sleep() function.  Here a simple point-form outline of the test
application:
>> 
>>  - Single task with priority 2   (only task explicitly created by me
i.e.  There’s
>>  obviously the other tasks implicitly created by the DSP/BIOS)
>> 
>>  - timer 0: 100us/int               (clock manager properties, I’m
assuming the
>>  clock generator is the tick generator)
>> 
>>  - TSK_sleep(5)                   (I’m calling this function within
the task I
>>  created to produce a 500us delay -- the real application (not this
test
>>  application) is multi-tasked)
>> 
>>  I would be expected a 500us delay instead I get a 1.1ms delay.   Of
course, the
>>  TSK_sleep(5) call is the minimum delay, but an overhead 600us is not
what I
>>  expected.
>> 
>>  Why am I not seeing about 500us?  What could possibly be accounted for
that 600us
>>  extra overhead?
>> 
>>  To insert a guaranteed delay of 500us, without blocking the rest of a
multi-task
>>  application is using a TSK_sleep the appropriate way to go about it. 
Should I
>>  simply let the task run and only poll the tick count.
>>How did you measure the delay?  There are lots of I/O methods in CCS
that are
>"Heisenberg" -- they disturb the thing you're trying to measure.
>
>Also, what is the *measured* period of your system timer (TIMER0)?  I.e. not
assuming
>that what you see in DSP/BIOS configuration is what's actually happening. 
My guess
>is that if you measured your tick generator using a GPIO signal on a dig
scope, you'd
>see about 200 usec.
>
>-Jeff
>

______________________________
New Code Sharing Section now Live on DSPRelated.com. Learn about the Reward Program for Contributors here.



(You need to be a member of c55x -- send a blank email to c55x-subscribe@yahoogroups.com )

Daniel-

> Actually this is pretty much what I have observed, without explicitely
toggling specifically on the tick gen.
> The 1.1
> ms delay I'm "seeing" was measured with an oscilloscope by
toggling a GPIO pin, but I did have an emulator hooked up
> to my card. The GPIO pin is set before the TSK_sleep(5) and cleared after,
within an explicitely created single task
> of priority 2 application. I may then infer from the CCS effect you are
referring to, that un-hooking the emulator
> should remove any "non real-time" effect.  I should then get an
appoximate 500us (i.e. more or less 1 % range not +/-
> 100% range) with the task sleep function.  Am I hearing you right.

Well it depends on that CCS is doing.  If the emulator is connected but CCS is
"quiet" -- no breakpoints set, no watch
windows, no RTDX, no LOG_printf() statements in the DSP code -- then there
shouldn't be any effect on DSP code.  But
yes, unhooking the emulator after code is running is an absolute test (which you
can do if you're careful of the way
you pull the JTAG header off, make sure Vcc pin is not pulled first).

If you're already using GPIO pins and dig scope measurements, then it would seem
to me your measurement is accurate. 
In that case I might suspect the DSP/BIOs tick rate.  Have you concretely
measured that?  There should be a TOUT pin
that you can configure to give you a pulse each time TIMER0 counts down to
zero.

-Jeff

> Daniel-
>>>  I have a basic understanding question concerning real-time timing
more specifically
>>>  TSK_sleep() function.  Here a simple point-form outline of the
test application:
>>>
>>>  - Single task with priority 2   (only task explicitly created by
me i.e.  There’s
>>>  obviously the other tasks implicitly created by the DSP/BIOS)
>>>
>>>  - timer 0: 100us/int               (clock manager properties, I’m
assuming the
>>>  clock generator is the tick generator)
>>>
>>>  - TSK_sleep(5)                   (I’m calling this function
within the task I
>>>  created to produce a 500us delay -- the real application (not this
test
>>>  application) is multi-tasked)
>>>
>>>  I would be expected a 500us delay instead I get a 1.1ms delay.  
Of course, the
>>>  TSK_sleep(5) call is the minimum delay, but an overhead 600us is
not what I
>>>  expected.
>>>
>>>  Why am I not seeing about 500us?  What could possibly be accounted
for that 600us
>>>  extra overhead?
>>>
>>>  To insert a guaranteed delay of 500us, without blocking the rest
of a multi-task
>>>  application is using a TSK_sleep the appropriate way to go about
it.  Should I
>>>  simply let the task run and only poll the tick count.
>>>How did you measure the delay?  There are lots of I/O methods in CCS
that are
>>"Heisenberg" -- they disturb the thing you're trying to
measure.
>>
>>Also, what is the *measured* period of your system timer (TIMER0)?  I.e.
not assuming
>>that what you see in DSP/BIOS configuration is what's actually
happening.  My guess
>>is that if you measured your tick generator using a GPIO signal on a dig
scope, you'd
>>see about 200 usec.
>>
>>-Jeff

______________________________
New Code Sharing Section now Live on DSPRelated.com. Learn about the Reward Program for Contributors here.



(You need to be a member of c55x -- send a blank email to c55x-subscribe@yahoogroups.com )

Daniel-

I forgot to mention the "Free Run" option on Debug menu in CCS.  The
idea is that CCS
ignores any current breakpoints, watch windows, etc. and lets the processor run
unencumbered.

But I'm not too sure about this.  I seem to recall that even if Free Run is
enabled,
and I have a disassembly or data display window active, and I adjust that
window, say
move the start address, I can "disturb" the running code.  You can
really see this
effect if code is running that's up against a real-time limit and has low margin
for
resources to be "borrowed" by CCS + JTAG.

-Jeff

-------- Original Message --------
Subject: Re: [c55x] Re:  Real time delay using TSK_sleep
Date: Wed, 2 May 2007 14:33:10 -0500 (CDT)
From: "Jeff Brower" <j...@signalogic.com>
To: "Daniel Caron" <d...@solacom.com>
CC: c...@yahoogroups.com

Daniel-

> Actually this is pretty much what I have observed, without explicitely
toggling specifically on the tick gen.
> The 1.1
> ms delay I'm "seeing" was measured with an oscilloscope by
toggling a GPIO pin, but I did have an emulator hooked up
> to my card. The GPIO pin is set before the TSK_sleep(5) and cleared after,
within an explicitely created single task
> of priority 2 application. I may then infer from the CCS effect you are
referring to, that un-hooking the emulator
> should remove any "non real-time" effect.  I should then get an
appoximate 500us (i.e. more or less 1 % range not +/-
> 100% range) with the task sleep function.  Am I hearing you right.

Well it depends on that CCS is doing.  If the emulator is connected but CCS is
"quiet" -- no breakpoints set, no watch
windows, no RTDX, no LOG_printf() statements in the DSP code -- then there
shouldn't
be any effect on DSP code.  But
yes, unhooking the emulator after code is running is an absolute test (which you
can
do if you're careful of the way
you pull the JTAG header off, make sure Vcc pin is not pulled first).

If you're already using GPIO pins and dig scope measurements, then it would seem
to
me your measurement is accurate. 
In that case I might suspect the DSP/BIOs tick rate.  Have you concretely
measured
that?  There should be a TOUT pin
that you can configure to give you a pulse each time TIMER0 counts down to
zero.

-Jeff

> Daniel-
>>>  I have a basic understanding question concerning real-time timing
more specifically
>>>  TSK_sleep() function.  Here a simple point-form outline of the
test application:
>>>
>>>  - Single task with priority 2   (only task explicitly created by
me i.e.  There’s
>>>  obviously the other tasks implicitly created by the DSP/BIOS)
>>>
>>>  - timer 0: 100us/int               (clock manager properties, I’m
assuming the
>>>  clock generator is the tick generator)
>>>
>>>  - TSK_sleep(5)                   (I’m calling this function
within the task I
>>>  created to produce a 500us delay -- the real application (not this
test
>>>  application) is multi-tasked)
>>>
>>>  I would be expected a 500us delay instead I get a 1.1ms delay.  
Of course, the
>>>  TSK_sleep(5) call is the minimum delay, but an overhead 600us is
not what I
>>>  expected.
>>>
>>>  Why am I not seeing about 500us?  What could possibly be accounted
for that 600us
>>>  extra overhead?
>>>
>>>  To insert a guaranteed delay of 500us, without blocking the rest
of a multi-task
>>>  application is using a TSK_sleep the appropriate way to go about
it.  Should I
>>>  simply let the task run and only poll the tick count.
>>>How did you measure the delay?  There are lots of I/O methods in CCS
that are
>>"Heisenberg" -- they disturb the thing you're trying to
measure.
>>
>>Also, what is the *measured* period of your system timer (TIMER0)?  I.e.
not assuming
>>that what you see in DSP/BIOS configuration is what's actually
happening.  My guess
>>is that if you measured your tick generator using a GPIO signal on a dig
scope, you'd
>>see about 200 usec.
>>
>>-Jeff

______________________________
Start your Android Ice Cream Sandwich development on TI's AM35x Sitara ARM Cortex-A8 processor today.



(You need to be a member of c55x -- send a blank email to c55x-subscribe@yahoogroups.com )