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

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

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
>

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

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