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 */ } |
|
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/ > > | |||
|
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/ | |||
|
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
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-----
Hi, 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/ > | |||
|