|
Hi Fred You need a watch on the *difference* of the two returned timer values, not the timer itself since the timer itself is free running. I suppose you could reset/start then stop the timer and then watch the timer directly, but the timer value itself only ticks once every two cycles so you cant (at least directly) get a single cycle accurate timing. Basically you would need to double the timer count, resulting in times that are modulo two. The trick that I was presenting is that by adding two consecutive timer tick counts, you a) Effectively double the timer count b) Optionally capture the timer transition The very interesting part of this is that the resulting 2x+transition time becomes single cycle accurate. All you need to do is account for (EG subtract) any constant offsets that are introduced by the calling of the timer sampling routine. BTW, I found this rather accidentally when trying to do benchmarking in the early DSK debugger. After getting past the initial surprise, I eventually figured it out. As a side note on this new DSK debugger, I changed how watch expressions and watch windows work. I basically noted that watches come in two types. Global variables that eventually evaluate to locations in .bss constant storage memory, and local variables that also evaluate to locations in memory, but this time in the C call stack. 1) A watch expression for a specific memory location or value can be entered in the command window. Then, on each emulation halt (screen repaint) the command window is re-evaluated and the text following the watch expression modified ->> USING THE COMMAND WINDOW MEANS NO WATCH WINDOW WAS NEEDED <<- 2) Global variables (and there symbols) are rather easily viewed using a memory window opened up with its initial address set to the beginning of .bss 3) Local variables, and the C call stack, are displayed using a specialized memory window that calculates its start address from the stack/frame pointer. I then display symbol names relative to the frame, regressing the frame down to main. By colorizing the call stack for each function level, you can now see how variables are passed on the stack! 4) I also track the variable type as fixed or float and modify the memory window display accordingly (as long as the type is auto and not something else like hex, binary or Q format). 5) The CPU registers are also saved in memory on each EMU halt. As you can guess, the CPU register window is yet again another specialized memory window. I have shown this to a few people in the TI Code Composer tools development group and they seem to like the idea. Maybe they will adopt this idea. After all, the DSK tools were also the first tools to offer ASM source tracking, among a few other neat things. Best regards, Keith Larson --------- At 11:55 AM 8/20/03 -0400, you wrote: Keith, That 's a good idea. It make you independant of the erratic behaviour of CC. Now I start the timer with a function and then I use a watch windwow with *(0x808024) which is the timer 0 counter value of the C3x Thanks for your help Fred ----- Original Message ----- From: Keith E. Larson To: frederic_terrettaz ; Sent: Tuesday, August 19, 2003 12:28 PM Subject: Re: [c3x] profile / view clock working with c33 and Code composer ? Hi Fred I am not sure *exactly* how the JTAG emulator 'clock' works so your best bet would be to contact Black-Hawk. I can however possibly provide an alternative. Any one of the four internal timers (TCLK0, TCLK1, CLKX, CLKR -serial port) can be used to get cycle accurate results, even though these timers are clock on 2-cycle boundaries. The basic idea is to read and then add the timer count on two consecutive cycles, essentialy doubling the timer count (desired) and simultaneously catching any possible transitions. The DSK tools use this concept to create a delta time parameter in the CPU context area called '_dT'. Converting this to C, we would get something like the following (that is, I did not test this!). Hope this helps Keith Larson ;--------------------- ; Function: long GetTimer0(void); ; ; Returns : Cycle accurate timer count ; Comments: Timer comparisons (benchmarking) requires the ; timer period to be greater than the event being timed. ; Also, the timer count should not roll over during this ; time. Setting count to zero is a possible solution ;--------------------- _GetTimer0 pop R0 ; Fast return using BUD bud R0 ; LDI @TCLK0_count,R0 ; get timer count ADDI @TCLK0_count,R0 ; add timer count, and possible transition nop ; void main(void) { long Offset, BM; // InitTimer0(LongPeriod); // Offset =GetTimer0(); // Determine timer function offset Offset-=GetTimer0(); // constant for this system // for(;;) { BM = GetTimer0(); // get base time // BenchmarkCode(); // run benchmark code // BM = GetTimer0()- BM - Offset; // Benchmark time in cycles } } -- At 09:59 PM 8/13/03 -0000, you wrote: Hi, Have somebody use the profile/view clock of code composer 4.10.37 with c33 (and the black hawk usb2.0 emulator) ? When I display the variable CLK in the watch window, I see it changing but its value is increasing at a too slow rate. It is unusable for one who want to do accurate benchmark. Which 'trick' use code composer to update the CLK value ? Do it use the internal DSP timer divide by a magic constant ? Thanks to answer. Fred +-----------+ |Keith Larson | |Member Group Technical Staff | |Texas Instruments Incorporated | | | | 281-274-3288 | | | | www.micro.ti.com/~klarson | |-----------+ | TMS320C3x/C4x/VC33 Applications | | | | TMS320VC33 | | The lowest cost and lowest power 500 w/Mflop | | floating point DSP on the planet! | +-----------+ |