Hello, I am using the MC9S08AC128 and want to have a simple way to find out the number of clock cycles to execute from one C program line to another C program line. There might be a big for loop within this C code segment, and it could take up to one second to execute.
I tried studying the LST file with the generated assembly instructions and clock cycles, but I have to manually add up the number of clock cycles to run a loop, and multuiply it by the loop count, which seem not a very smart method. Then I try to use an internal timer to find out the clock cycles, but the timer is only 16-bit which cannot go beyond a few tens of milliseconds. Besides, I don't want to waste a hardware timer just for this purpose. Then I tried using the profiling, which is very hard to use, and the trace buffer seems to be only 300 cycles, which is less than what I need. Moreover, the trace only trace result only shows the execution, it does not add up the clock cycles. It also seems to slow down the normal execution of the program which is not acceptable as I have to interface run it with hardware drivers together. Shouldn't there be a more simple way to do this?
I have use another IDE environment, and they have a clock counter. All I need to do is set two breakpoints at A and B locations. Execute the code to location A, reset the clock counter, then execute the code to location B, and it will show the number of clock cycles. This is the simple thing I am talking about.
BR - Henry
Unfortunately there's no dedicated cycle counter in your MCU, which could be read by debugger. I think debugger could show you execution time only (I think NoICE has such feature). Simulator can count cycles, but simulators usage is very limited.
For short delays I'm using timer. For long delays you may use some periodic interrupt and increment counter variable in ISR. Take the difference of counter at point A and at point B, then multiply it by interrupt period expressed in CPU cycles.
I have had success with using full chip simulation mode, which does have a cycle counter. This should work provided you are not waiting for a hardware event to occur within the code you are testing, and provided you are not attempting to program/erase flash memory.
The total CPU cycles will be affected by any potential interrupt execution. However, it should be possible to separately measure the cycles for the execution of each ISR code, to take these into account for a worst case estimation.
I suggest that you give full chip simulation at try. If it is not suitable for your application, you can then revert to the timer methods previously outlined.
Thanks all of your help. I have tried using a pin and scope method, and I have tried using simulator with cycle counter. They both worked well and the result seems to match quite good. I have not tried with interrupt timer.
If using the internal timer, you would of course need to count the number of timer overflow interrupts.
The easiest way however, is to drive an I/O pin high at the beginning of the code, then drive it low at the end. Measure with your oscilloscope. You cannot develop embedded software without one.