Forums

Use of clock_gettime() on DSP56F807

Started by Aaron Needles October 9, 2002
Hi,
I'm attempting to use the "Real Time Clock" feature in Motorola's
DSP but am getting inconsistent time values returned when I call
clock_gettime() successively.

The code below was added to a project created with "Embedded SDK
Stationary" and only the INCLUDE_TIMER #define added to appconfig.h.
When I run the code on our DSP56F807EVM via External RAM and then
display timeBuf[] as variable with value as hexadecimal, I get the
following (summarized)...

Idx Value
0 0x0EE6B9D8
1 0x0EE7AE23
2 0x0EE7A26E
...
15 0x0EE70A3D
16 0x0EE6FE88
17 0x0EE6F2D3
...
198 0x0EE7ABDA
199 0x0EE7A025

I was expecting a smoothly increasing integer count representing time
elapsed in nanoseconds. Has someone used the clock_gettime() function
sucessfully? I am using current versions of CodeWarrior+patch and
Motorola's SDK (2.5)

Thanks in advance,
Aaron

Aaron Needles
Senior Software Engineer
Alstom Schilling Robotics
/* File: main.c */

#include "timer.h"

/*******************************************************
* Skeleton C main program for use with Embedded SDK
*******************************************************/

#define NUM_ITERATIONS 200
unsigned long timeBuf[NUM_ITERATIONS];

void main (void)
{
int i;
struct timespec thisTime;
struct timespec timeDelay = {0, 250000000}; // 1/4 sec

// This is an attempt to allow the clock to synchronize/stabalize.
// I don't believe it makes any difference.
nanosleep(&timeDelay, NULL);

// Just in case...
for (i=0; i<NUM_ITERATIONS; i++) {
timeBuf[i] = 0;
}

for (i=0; i<NUM_ITERATIONS; i++) {
archDisableInt();
clock_gettime(CLOCK_REALTIME, &thisTime);
asm(nop);
asm(nop);
asm(nop);
asm(nop);
asm(nop);
asm(nop);
asm(nop);

// Save time
timeBuf[i] = thisTime.tv_nsec;
archEnableInt();
}

while (1) {
// Set breakpoint on asm(nop). Read timeBuf[] values after break
asm(nop);
}
return; /* C statements */
}




I have the same experience. I found THREE (!) different problems in
clock_gettime() function. Each can cause wrong clock_gettime() returns.
I sent a 'bug report' to Motorola already, but (of course) without any
answer. Report is attached to this mail, you can find a fix there.

Richard Kis

> -----Original Message-----
> From: Aaron Needles [mailto:]
> Sent: Wednesday, October 09, 2002 5:47 PM
> To:
> Subject: [motoroladsp] Use of clock_gettime() on DSP56F807 > Hi,
> I'm attempting to use the "Real Time Clock" feature in Motorola's
> DSP but am getting inconsistent time values returned when I call
> clock_gettime() successively.
>
> The code below was added to a project created with "Embedded SDK
> Stationary" and only the INCLUDE_TIMER #define added to appconfig.h.
> When I run the code on our DSP56F807EVM via External RAM and then
> display timeBuf[] as variable with value as hexadecimal, I get the
> following (summarized)...
>
> Idx Value
> 0 0x0EE6B9D8
> 1 0x0EE7AE23
> 2 0x0EE7A26E
> ...
> 15 0x0EE70A3D
> 16 0x0EE6FE88
> 17 0x0EE6F2D3
> ...
> 198 0x0EE7ABDA
> 199 0x0EE7A025
>
> I was expecting a smoothly increasing integer count representing time
> elapsed in nanoseconds. Has someone used the clock_gettime() function
> sucessfully? I am using current versions of CodeWarrior+patch and
> Motorola's SDK (2.5)
>
> Thanks in advance,
> Aaron
>
> Aaron Needles
> Senior Software Engineer
> Alstom Schilling Robotics >
> /* File: main.c */
>
> #include "timer.h"
>
> /*******************************************************
> * Skeleton C main program for use with Embedded SDK
> *******************************************************/
>
> #define NUM_ITERATIONS 200
> unsigned long timeBuf[NUM_ITERATIONS];
>
> void main (void)
> {
> int i;
> struct timespec thisTime;
> struct timespec timeDelay = {0, 250000000}; // 1/4 sec
>
> // This is an attempt to allow the clock to synchronize/stabalize.
> // I don't believe it makes any difference.
> nanosleep(&timeDelay, NULL);
>
> // Just in case...
> for (i=0; i<NUM_ITERATIONS; i++) {
> timeBuf[i] = 0;
> }
>
> for (i=0; i<NUM_ITERATIONS; i++) {
> archDisableInt();
> clock_gettime(CLOCK_REALTIME, &thisTime);
> asm(nop);
> asm(nop);
> asm(nop);
> asm(nop);
> asm(nop);
> asm(nop);
> asm(nop);
>
> // Save time
> timeBuf[i] = thisTime.tv_nsec;
> archEnableInt();
> }
>
> while (1) {
> // Set breakpoint on asm(nop). Read timeBuf[] values after break
> asm(nop);
> }
> return; /* C statements */
> } > ------------------------ Yahoo! Groups Sponsor
> ---------------------~-->
> Plan to Sell a Home?
> http://us.click.yahoo.com/J2SnNA/y.lEAA/MVfIAA/PNArlB/TM
> --------------------------
> -------~->
>
> _____________________________________
> Note: If you do a simple "reply" with your email client, only
> the author of this message will receive your answer. You
> need to do a "reply all" if you want your answer to be
> distributed to the entire group.
>
> _____________________________________
> About this discussion group:
>
> To Join:
>
> To Post:
>
> To Leave:
>
> Archives: http://www.yahoogroups.com/group/motoroladsp
>
> More Groups: http://www.dsprelated.com/groups.php3 > ">http://docs.yahoo.com/info/terms/ >
>


Attachment (not stored)
Motorola 56000DSP SDK Bug Report.rtf
Type: application/rtf

Something we have found that may be contributing to this problem, is that
CodeWarrior does not perform 32-bit integer calculations properly unless you
choose Optimization Level 0. This is demonstrated by the attached file
containing an example from one of our library functions.

The code in "pot_7pt_scale_bad.c" should work, but doesn't. The code in
"pot_7pt_scale.c" does work OK. This is a good example of what I meant by
"extreme defensive programming" in my message "RE: [motoroladsp] RE:
Interrupt/context problem?" at about 5:20am yesterday morning.

YES, I KNOW that we could use "#pragma optimization_level 0" in this case, but
in my (not-so-humble) opinion this is simply another work around for a
CodeWarrior bug. You may want to try this option to see if it fixes any
problems you have with 32-bit integer math calculations.

In case you are wondering, we did not send this in to Metrowerks as a bug
report. We have found that if we can develop a simple work around, it is a much
better use of our extremely limited time, rather than spending a day or so
generating a proper test case and sending it in to Metrowerks. Plus we get the
fix immediately, rather than having to wait for the next patch to be released.

I hope you find this to be helpful.

Regards,

Art Johnson
Senior Systems Analyst
PMC Prime Mover Controls Inc.
3600 Gilmore Way
Burnaby, B.C., Canada
V5G 4R8
Phone: 604 433-4644
FAX: 604 433-5570
Email:
http://www.pmc-controls.com

-----Original Message-----
From: Richard Kis [mailto:]
Sent: Wednesday, October 09, 2002 11:50 PM
To: Aaron Needles;
Subject: RE: [motoroladsp] Use of clock_gettime() on DSP56F807
I have the same experience. I found THREE (!) different problems in
clock_gettime() function. Each can cause wrong clock_gettime() returns.
I sent a 'bug report' to Motorola already, but (of course) without any
answer. Report is attached to this mail, you can find a fix there.

Richard Kis

> -----Original Message-----
> From: Aaron Needles [mailto:]
> Sent: Wednesday, October 09, 2002 5:47 PM
> To:
> Subject: [motoroladsp] Use of clock_gettime() on DSP56F807 > Hi,
> I'm attempting to use the "Real Time Clock" feature in Motorola's
> DSP but am getting inconsistent time values returned when I call
> clock_gettime() successively.
>
> The code below was added to a project created with "Embedded SDK
> Stationary" and only the INCLUDE_TIMER #define added to appconfig.h.
> When I run the code on our DSP56F807EVM via External RAM and then
> display timeBuf[] as variable with value as hexadecimal, I get the
> following (summarized)...
>
> Idx Value
> 0 0x0EE6B9D8
> 1 0x0EE7AE23
> 2 0x0EE7A26E
> ...
> 15 0x0EE70A3D
> 16 0x0EE6FE88
> 17 0x0EE6F2D3
> ...
> 198 0x0EE7ABDA
> 199 0x0EE7A025
>
> I was expecting a smoothly increasing integer count representing time
> elapsed in nanoseconds. Has someone used the clock_gettime() function
> sucessfully? I am using current versions of CodeWarrior+patch and
> Motorola's SDK (2.5)
>
> Thanks in advance,
> Aaron
>
> Aaron Needles
> Senior Software Engineer
> Alstom Schilling Robotics >
> /* File: main.c */
>
> #include "timer.h"
>
> /*******************************************************
> * Skeleton C main program for use with Embedded SDK
> *******************************************************/
>
> #define NUM_ITERATIONS 200
> unsigned long timeBuf[NUM_ITERATIONS];
>
> void main (void)
> {
> int i;
> struct timespec thisTime;
> struct timespec timeDelay = {0, 250000000}; // 1/4 sec
>
> // This is an attempt to allow the clock to synchronize/stabalize.
> // I don't believe it makes any difference.
> nanosleep(&timeDelay, NULL);
>
> // Just in case...
> for (i=0; i<NUM_ITERATIONS; i++) {
> timeBuf[i] = 0;
> }
>
> for (i=0; i<NUM_ITERATIONS; i++) {
> archDisableInt();
> clock_gettime(CLOCK_REALTIME, &thisTime);
> asm(nop);
> asm(nop);
> asm(nop);
> asm(nop);
> asm(nop);
> asm(nop);
> asm(nop);
>
> // Save time
> timeBuf[i] = thisTime.tv_nsec;
> archEnableInt();
> }
>
> while (1) {
> // Set breakpoint on asm(nop). Read timeBuf[] values after break
> asm(nop);
> }
> return; /* C statements */
> } > ------------------------ Yahoo! Groups Sponsor
> ---------------------~-->
> Plan to Sell a Home?
> http://us.click.yahoo.com/J2SnNA/y.lEAA/MVfIAA/PNArlB/TM
> --------------------------
> -------~->
>
> _____________________________________
> Note: If you do a simple "reply" with your email client, only
> the author of this message will receive your answer. You
> need to do a "reply all" if you want your answer to be
> distributed to the entire group.
>
> _____________________________________
> About this discussion group:
>
> To Join:
>
> To Post:
>
> To Leave:
>
> Archives: http://www.yahoogroups.com/group/motoroladsp
>
> More Groups: http://www.dsprelated.com/groups.php3 > ">http://docs.yahoo.com/info/terms/ >
>


_____________________________________
Note: If you do a simple "reply" with your email client, only the author of this
message will receive your answer. You need to do a "reply all" if you want your
answer to be distributed to the entire group.

_____________________________________
About this discussion group:

To Join:

To Post:

To Leave:

Archives: http://www.yahoogroups.com/group/motoroladsp

More Groups: http://www.dsprelated.com/groups.php3 ">http://docs.yahoo.com/info/terms/



Attachment (not stored)
calcerror.zip
Type: application/x-zip-compressed

Aaron,

 

“Real Time Clock” of the SDK has resolution of 1msec (you can verify this by calling clock_getres() function). If you look at your numbers in decimal format, you have to ignore everything below msec resolution:

 

Idx  Value
  0  0x0EE6B9D8 -> 250,000,880 -> 250 msec
  1  0x0EE7AE23 -> 250,064,419 -> 250 msec
  2  0x0EE7A26E -> 250,061,422 -> 250 msec
...
15  0x0EE70A3D -> 250,022,461 -> 250 msec
16  0x0EE6FE88 -> 250,019,464 -> 250 msec
17  0x0EE6F2D3 -> 250,016,467 -> 250 msec
...
198  0x0EE7ABDA -> 250,063,834 -> 250 msec
199  0x0EE7A025 -> 250,060,837 -> 250 msec

 

If you would run your code for over msec, you will see that 250 msec value will change to 251 msec.

 

In other words, API provides for 1 nsec resolution, but “Real Time Clock” implementation has resolution of 1 msec, so the user should not expect to have any meaningful data in msec and nsec portion of the tv_nsec member.

 

Leonard N. Elevich

Motorola DSPO

 

-----Original Message-----
From: Aaron Needles [mailto:a...@tde.alstom.com]
Sent:
Wednesday, October 09, 2002 8:47 AM
To: m...@yahoogroups.com
Subject: [motoroladsp] Use of clock_gettime() on DSP56F807

 

Hi,
    I'm attempting to use the "Real Time Clock" feature in Motorola's
DSP but am getting inconsistent time values returned when I call
clock_gettime() successively.

The code below was added to a project created with "Embedded SDK
Stationary" and only the INCLUDE_TIMER #define added to appconfig.h.
When I run the code on our DSP56F807EVM via External RAM and then
display timeBuf[] as variable with value as hexadecimal, I get the
following (summarized)...

Idx  Value
  0  0x0EE6B9D8
  1  0x0EE7AE23
  2  0x0EE7A26E
...
15  0x0EE70A3D
16  0x0EE6FE88
17  0x0EE6F2D3
...
198  0x0EE7ABDA
199  0x0EE7A025

I was expecting a smoothly increasing integer count representing time
elapsed in nanoseconds. Has someone used the clock_gettime() function
sucessfully? I am using current versions of CodeWarrior+patch and
Motorola's SDK (2.5)

Thanks in advance,
    Aaron

Aaron Needles
Senior Software Engineer
Alstom Schilling Robotics
a...@tde.alstom.com /* File: main.c */

#include "timer.h"

/*******************************************************
* Skeleton C main program for use with Embedded SDK
*******************************************************/

#define NUM_ITERATIONS 200
unsigned long timeBuf[NUM_ITERATIONS];

void main (void)
{
    int i;
    struct timespec thisTime;
    struct timespec timeDelay = {0, 250000000}; // 1/4 sec

    // This is an attempt to allow the clock to synchronize/stabalize.
    // I don't believe it makes any difference.
    nanosleep(&timeDelay, NULL);

    // Just in case...
    for (i=0; i<NUM_ITERATIONS; i++) {
        timeBuf[i] = 0;
    }

    for (i=0; i<NUM_ITERATIONS; i++) {
        archDisableInt();
        clock_gettime(CLOCK_REALTIME, &thisTime);
        asm(nop);
        asm(nop);
        asm(nop);
        asm(nop);
        asm(nop);
        asm(nop);
        asm(nop);

        // Save time
        timeBuf[i] = thisTime.tv_nsec;
        archEnableInt();
    }

    while (1) {
// Set breakpoint on asm(nop). Read timeBuf[] values after break
        asm(nop);
    }     
      return;          /* C statements */
}



_____________________________________
Note: If you do a simple "reply" with your email client, only the author of this message will receive your answer.  You need to do a "reply all" if you want your answer to be distributed to the entire group.

_____________________________________
About this discussion group:

To Join:  m...@yahoogroups.com

To Post:  m...@yahoogroups.com

To Leave: m...@yahoogroups.com

Archives: http://www.yahoogroups.com/group/motoroladsp

More Groups: http://www.dsprelated.com/groups.php3


">Yahoo! Terms of Service.


Excuse me, but it is not a true. 1ms is only a period for timer
interrupt routine. But:

-clock_gettime() really adding the actual (hardware) timer context to
value accounted by the timer ISR (please, take a look to the sources)
with all bugs I described:
- 16bit multiplication instead of required 32 bit !
- timer is set to counting down so added value is largest just
after the ISR event and smallest before next ISR event !

In case that you use timer as 1ms resolution only and do rounding (or
better truncating) the returned value to milliseconds resolution like
you describing, you can get the failure results too because of third
bug: use of 'timerRTElapsedTime' variable without disabling of timer
interrupt before. timer ISR event can happend during reading of
'timerRTElapsedTime' within clock_gettime()! I really saw it. Problems
with clock_gettime() costs me a few days of finding a strange,
occasional software failures... Richard Kis

-----Original Message-----
From: Leonard N. Elevich [mailto:]
Sent: Thursday, October 10, 2002 11:54 PM
To: 'Aaron Needles';
Subject: RE: [motoroladsp] Use of clock_gettime() on DSP56F807
Aaron,
"Real Time Clock" of the SDK has resolution of 1msec (you can verify
this by calling clock_getres() function). If you look at your numbers in
decimal format, you have to ignore everything below msec resolution:
Idx Value
0 0x0EE6B9D8 -> 250,000,880 -> 250 msec
1 0x0EE7AE23 -> 250,064,419 -> 250 msec
2 0x0EE7A26E -> 250,061,422 -> 250 msec
...
15 0x0EE70A3D -> 250,022,461 -> 250 msec
16 0x0EE6FE88 -> 250,019,464 -> 250 msec
17 0x0EE6F2D3 -> 250,016,467 -> 250 msec
...
198 0x0EE7ABDA -> 250,063,834 -> 250 msec
199 0x0EE7A025 -> 250,060,837 -> 250 msec
If you would run your code for over msec, you will see that 250 msec
value will change to 251 msec.
In other words, API provides for 1 nsec resolution, but "Real Time
Clock" implementation has resolution of 1 msec, so the user should not
expect to have any meaningful data in msec and nsec portion of the
tv_nsec member.
Leonard N. Elevich

Motorola DSPO
-----Original Message-----
From: Aaron Needles [mailto:]
Sent: Wednesday, October 09, 2002 8:47 AM
To:
Subject: [motoroladsp] Use of clock_gettime() on DSP56F807
Hi,
I'm attempting to use the "Real Time Clock" feature in Motorola's
DSP but am getting inconsistent time values returned when I call
clock_gettime() successively.

The code below was added to a project created with "Embedded SDK
Stationary" and only the INCLUDE_TIMER #define added to appconfig.h.
When I run the code on our DSP56F807EVM via External RAM and then
display timeBuf[] as variable with value as hexadecimal, I get the
following (summarized)...

Idx Value
0 0x0EE6B9D8
1 0x0EE7AE23
2 0x0EE7A26E
...
15 0x0EE70A3D
16 0x0EE6FE88
17 0x0EE6F2D3
...
198 0x0EE7ABDA
199 0x0EE7A025

I was expecting a smoothly increasing integer count representing time
elapsed in nanoseconds. Has someone used the clock_gettime() function
sucessfully? I am using current versions of CodeWarrior+patch and
Motorola's SDK (2.5)

Thanks in advance,
Aaron

Aaron Needles
Senior Software Engineer
Alstom Schilling Robotics
/* File: main.c */

#include "timer.h"

/*******************************************************
* Skeleton C main program for use with Embedded SDK
*******************************************************/

#define NUM_ITERATIONS 200
unsigned long timeBuf[NUM_ITERATIONS];

void main (void)
{
int i;
struct timespec thisTime;
struct timespec timeDelay = {0, 250000000}; // 1/4 sec

// This is an attempt to allow the clock to synchronize/stabalize.
// I don't believe it makes any difference.
nanosleep(&timeDelay, NULL);

// Just in case...
for (i=0; i<NUM_ITERATIONS; i++) {
timeBuf[i] = 0;
}

for (i=0; i<NUM_ITERATIONS; i++) {
archDisableInt();
clock_gettime(CLOCK_REALTIME, &thisTime);
asm(nop);
asm(nop);
asm(nop);
asm(nop);
asm(nop);
asm(nop);
asm(nop);

// Save time
timeBuf[i] = thisTime.tv_nsec;
archEnableInt();
}

while (1) {
// Set breakpoint on asm(nop). Read timeBuf[] values after break
asm(nop);
}
return; /* C statements */
} _____________________________________
Note: If you do a simple "reply" with your email client, only the author
of this message will receive your answer. You need to do a "reply all"
if you want your answer to be distributed to the entire group.

_____________________________________
About this discussion group:

To Join:

To Post:

To Leave:

Archives: http://www.yahoogroups.com/group/motoroladsp
<http://www.yahoogroups.com/group/motoroladsp>

More Groups: http://www.dsprelated.com/groups.php3
<http://www.dsprelated.com/groups.php3 ">http://docs.yahoo.com/info/terms/> Terms of Service.

<http://rd.yahoo.com/M!9695.2310151.3725769.2113459/D=egroupweb/S05
771855:HM/A26184/R=0/*http://ad.doubleclick.net/jump/N879.ameritrade.
yahoo/B1054521.11;sz00x250;adc=ZHS;ord34287845?>

<http://us.adserver.yahoo.com/l?M!9695.2310151.3725769.2113459/D=egrou
pmail/S=:HM/A26184/randq5554770>

_____________________________________
Note: If you do a simple "reply" with your email client, only the author
of this message will receive your answer. You need to do a "reply all"
if you want your answer to be distributed to the entire group.

_____________________________________
About this discussion group:

To Join:

To Post:

To Leave:

Archives: http://www.yahoogroups.com/group/motoroladsp
<http://www.yahoogroups.com/group/motoroladsp>

More Groups: http://www.dsprelated.com/groups.php3
<http://www.dsprelated.com/groups.php3 ">http://docs.yahoo.com/info/terms/> .


Aaron Unfortunately, I don't know about such a bug list. I didn't think that
it is so bad with the SDK, I believe that this is a exception rather.

But just different other point of view to SDK: use of SDK brings some
overhead in your software:
- unnecessary code linked (SDKs function are pretty general so not to
fit to your application only)
- SDK configuration constant data (mostly unnecessary for current
application requirements)
- SDK data (568XX CPU has not excess of internal XRAM so for example use
of proforma 'file descriptors' can frustrate someone who has problems
with the RAM capacity).

So I think that for real application it is better use SDK restricted as
much as possible. Even though I think that SDK is excellent source of
inspiration. Richard Kis
> -----Original Message-----
> From: Aaron Needles [mailto:]
> Sent: Thursday, October 10, 2002 5:25 PM
> To: Richard Kis
> Subject: Re: Use of clock_gettime() on DSP56F807 > Richard,
> I took a look at your bug report. Unbelievable! I can't
> imagine how bugs of this kind got past any testing that would/should
> have been done on the SDK. I really appreciate your help. Is there
> a list of known bugs available from Motorola that includes this and
> other bugs to SDK 2.5?
>
> Thanks,
> Aaron.
>
> --- In motoroladsp@y..., "Richard Kis" <richard_kis@s...> wrote:
> >
> > I have the same experience. I found THREE (!) different problems in
> > clock_gettime() function. Each can cause wrong clock_gettime()
> returns.
> > I sent a 'bug report' to Motorola already, but (of course) without
> any
> > answer. Report is attached to this mail, you can find a fix there.
> >
> > Richard Kis
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: Aaron Needles [mailto:aaron.needles@t...]
> > > Sent: Wednesday, October 09, 2002 5:47 PM
> > > To: motoroladsp@y...
> > > Subject: [motoroladsp] Use of clock_gettime() on DSP56F807
> > >
> > >
> > > Hi,
> > > I'm attempting to use the "Real Time Clock" feature in
> Motorola's
> > > DSP but am getting inconsistent time values returned when I call
> > > clock_gettime() successively.
> > >
> > > The code below was added to a project created with "Embedded SDK
> > > Stationary" and only the INCLUDE_TIMER #define added to
> appconfig.h.
> > > When I run the code on our DSP56F807EVM via External RAM and then
> > > display timeBuf[] as variable with value as hexadecimal, I get
> the
> > > following (summarized)...
> > >
> > > Idx Value
> > > 0 0x0EE6B9D8
> > > 1 0x0EE7AE23
> > > 2 0x0EE7A26E
> > > ...
> > > 15 0x0EE70A3D
> > > 16 0x0EE6FE88
> > > 17 0x0EE6F2D3
> > > ...
> > > 198 0x0EE7ABDA
> > > 199 0x0EE7A025
> > >
> > > I was expecting a smoothly increasing integer count representing
> time
> > > elapsed in nanoseconds. Has someone used the clock_gettime()
> function
> > > sucessfully? I am using current versions of CodeWarrior+patch and
> > > Motorola's SDK (2.5)
> > >
> > > Thanks in advance,
> > > Aaron
> > >
> > > Aaron Needles
> > > Senior Software Engineer
> > > Alstom Schilling Robotics
> > > aaron.needles@t...
> > >
> > >
> > > /* File: main.c */
> > >
> > > #include "timer.h"
> > >
> > > /*******************************************************
> > > * Skeleton C main program for use with Embedded SDK
> > > *******************************************************/
> > >
> > > #define NUM_ITERATIONS 200
> > > unsigned long timeBuf[NUM_ITERATIONS];
> > >
> > > void main (void)
> > > {
> > > int i;
> > > struct timespec thisTime;
> > > struct timespec timeDelay = {0, 250000000}; // 1/4 sec
> > >
> > > // This is an attempt to allow the clock to
> synchronize/stabalize.
> > > // I don't believe it makes any difference.
> > > nanosleep(&timeDelay, NULL);
> > >
> > > // Just in case...
> > > for (i=0; i<NUM_ITERATIONS; i++) {
> > > timeBuf[i] = 0;
> > > }
> > >
> > > for (i=0; i<NUM_ITERATIONS; i++) {
> > > archDisableInt();
> > > clock_gettime(CLOCK_REALTIME, &thisTime);
> > > asm(nop);
> > > asm(nop);
> > > asm(nop);
> > > asm(nop);
> > > asm(nop);
> > > asm(nop);
> > > asm(nop);
> > >
> > > // Save time
> > > timeBuf[i] = thisTime.tv_nsec;
> > > archEnableInt();
> > > }
> > >
> > > while (1) {
> > > // Set breakpoint on asm(nop). Read timeBuf[] values after break
> > > asm(nop);
> > > }
> > > return; /* C statements */
> > > }
> > >
> > >
> > > ------------------------ Yahoo! Groups Sponsor
> > > ---------------------~-->
> > > Plan to Sell a Home?
> > > http://us.click.yahoo.com/J2SnNA/y.lEAA/MVfIAA/PNArlB/TM
> > > --------------------------
> > > -------~->
> > >
> > > _____________________________________
> > > Note: If you do a simple "reply" with your email client, only
> > > the author of this message will receive your answer. You
> > > need to do a "reply all" if you want your answer to be
> > > distributed to the entire group.
> > >
> > > _____________________________________
> > > About this discussion group:
> > >
> > > To Join: motoroladsp-subscribe@y...
> > >
> > > To Post: motoroladsp@y...
> > >
> > > To Leave: motoroladsp-unsubscribe@y...
> > >
> > > Archives: http://www.yahoogroups.com/group/motoroladsp
> > >
> > > More Groups: http://www.dsprelated.com/groups.php3
> > >
> > >
> > > ">http://docs.yahoo.com/info/terms/
> > >
> > >
> > >
> > >



Rick,

I made one more change regarding 'clock_gettime()' : I moved clearing of
timer interrupt flag after call of the timer callback so waiting loop in
clock_gettime() (wait for timer ISR completed in case when QTB_TCF == 1
( timer interrupt pending)) will work correctly and returns really
after timer callback was called. Please, look to attached file...

Regarding Motorola 'bug report policy' : NO COMMENT... Richard Kis
> -----Original Message-----
> From: Corey, Rick [mailto:]
> Sent: Wednesday, October 23, 2002 5:56 PM
> To: Richard Kis
> Subject: RE: [motoroladsp] Use of clock_gettime() on DSP56F807 > Richard,
>
> Thanks for the warning and fix for clock_gettime() on the
> '807. We may have
> to check that out for use with the 56803.
>
> I was told by one Motorola guy that the people in his group are not
> *allowed* to work on fixes unless they are submitted through
> the website.
> They have to get some official number assigned, and then they
> can spend time
> on it.
>
> He was very clear that, if it was "just Email", he couldn't
> spend time on
> it.
>
> I wonder why there is no Motorola guy assigned to reading
> about critical
> bugs in "just Email", and entering them "officially" on the
> Moto website
> under Tech Support or Service Request.
>
> One must "register" and "login" in order to place a service
> request (or
> report a bug).
>
> The link is:
>
> http://e-www.motorola.com/support/index.html > Rick Corey > -----Original Message-----
> From: Richard Kis [mailto:]
> Sent: Thursday, October 10, 2002 2:50 AM
> To: Aaron Needles;
> Subject: RE: [motoroladsp] Use of clock_gettime() on DSP56F807 >
> I have the same experience. I found THREE (!) different problems in
> clock_gettime() function. Each can cause wrong
> clock_gettime() returns.
> I sent a 'bug report' to Motorola already, but (of course) without any
> answer. Report is attached to this mail, you can find a fix there.
>
> Richard Kis >
>
> > -----Original Message-----
> > From: Aaron Needles [mailto:]
> > Sent: Wednesday, October 09, 2002 5:47 PM
> > To:
> > Subject: [motoroladsp] Use of clock_gettime() on DSP56F807
> >
> >
> > Hi,
> > I'm attempting to use the "Real Time Clock" feature in
> Motorola's
> > DSP but am getting inconsistent time values returned when I call
> > clock_gettime() successively.
> >
> > The code below was added to a project created with "Embedded SDK
> > Stationary" and only the INCLUDE_TIMER #define added to
> appconfig.h.
> > When I run the code on our DSP56F807EVM via External RAM and then
> > display timeBuf[] as variable with value as hexadecimal, I get the
> > following (summarized)...
> >
> > Idx Value
> > 0 0x0EE6B9D8
> > 1 0x0EE7AE23
> > 2 0x0EE7A26E
> > ...
> > 15 0x0EE70A3D
> > 16 0x0EE6FE88
> > 17 0x0EE6F2D3
> > ...
> > 198 0x0EE7ABDA
> > 199 0x0EE7A025
> >
> > I was expecting a smoothly increasing integer count
> representing time
> > elapsed in nanoseconds. Has someone used the
> clock_gettime() function
> > sucessfully? I am using current versions of CodeWarrior+patch and
> > Motorola's SDK (2.5)
> >
> > Thanks in advance,
> > Aaron
> >
> > Aaron Needles
> > Senior Software Engineer
> > Alstom Schilling Robotics
> >
> >
> >
> > /* File: main.c */
> >
> > #include "timer.h"
> >
> > /*******************************************************
> > * Skeleton C main program for use with Embedded SDK
> > *******************************************************/
> >
> > #define NUM_ITERATIONS 200
> > unsigned long timeBuf[NUM_ITERATIONS];
> >
> > void main (void)
> > {
> > int i;
> > struct timespec thisTime;
> > struct timespec timeDelay = {0, 250000000}; // 1/4 sec
> >
> > // This is an attempt to allow the clock to
> synchronize/stabalize.
> > // I don't believe it makes any difference.
> > nanosleep(&timeDelay, NULL);
> >
> > // Just in case...
> > for (i=0; i<NUM_ITERATIONS; i++) {
> > timeBuf[i] = 0;
> > }
> >
> > for (i=0; i<NUM_ITERATIONS; i++) {
> > archDisableInt();
> > clock_gettime(CLOCK_REALTIME, &thisTime);
> > asm(nop);
> > asm(nop);
> > asm(nop);
> > asm(nop);
> > asm(nop);
> > asm(nop);
> > asm(nop);
> >
> > // Save time
> > timeBuf[i] = thisTime.tv_nsec;
> > archEnableInt();
> > }
> >
> > while (1) {
> > // Set breakpoint on asm(nop). Read timeBuf[] values after break
> > asm(nop);
> > }
> > return; /* C statements */
> > }
> >
> >
> > ------------------------ Yahoo! Groups Sponsor
> > ---------------------~-->
> > Plan to Sell a Home?
> > http://us.click.yahoo.com/J2SnNA/y.lEAA/MVfIAA/PNArlB/TM
> > --------------------------
> > -------~->
> >
> > _____________________________________
> > Note: If you do a simple "reply" with your email client, only
> > the author of this message will receive your answer. You
> > need to do a "reply all" if you want your answer to be
> > distributed to the entire group.
> >
> > _____________________________________
> > About this discussion group:
> >
> > To Join:
> >
> > To Post:
> >
> > To Leave:
> >
> > Archives: http://www.yahoogroups.com/group/motoroladsp
> >
> > More Groups: http://www.dsprelated.com/groups.php3
> >
> >
> > ">http://docs.yahoo.com/info/terms/
> >
> >
> >
> >
>
> ------------------------ Yahoo! Groups Sponsor
> ---------------------~-->
> Home Selling? Try Us!
> http://us.click.yahoo.com/QrPZMC/iTmEAA/MVfIAA/PNArlB/TM
> --------------------------
> -------~->
>
> _____________________________________
> Note: If you do a simple "reply" with your email client, only
> the author of
> this message will receive your answer. You need to do a
> "reply all" if you
> want your answer to be distributed to the entire group.
>
> _____________________________________
> About this discussion group:
>
> To Join:
>
> To Post:
>
> To Leave:
>
> Archives: http://www.yahoogroups.com/group/motoroladsp
>
> More Groups: http://www.dsprelated.com/groups.php3 > ">http://docs.yahoo.com/info/terms/ >


Attachment (not stored)
qtimerdrv.fix
Type: application/octet-stream