instruction delay

[aarkey]

hi
can anybody tell me ..... what is the delay of various instruction of CCS C??
if u have idea then please share with me......
thank you

[jbmiller]

Short answer is it depends on instruction and processor clocks speed.
Best way is to create a small,working program( blinking LED or 'hello world'). Printout the listing (.LST file). Now consult the Microchip databook for the PIC you've chosen,lookup the instruction, and read the cycles. Put that number on the end of the line in a column. The time it takes is dependent on the xtal you use for the PIC. the classic benchmark is that a 4MHZ xtal will give you 1 us / cycle.
This should be a good start for you.
The more you read, the better you'll understand the power of the PIC.
Cheers

[aarkey]

thanks for ur reply

i know about pic controllers as u said........
but i want the time which require by the built i function of CCS C
and this timings are in us or ms....
so cant get exact time with help of leds....
so please help me....

[SherpaDoug]

I set a pin before entering the function, and clear the pin when I leave. Then I measure the time with a scope or logic analyzer.

The other way is to look at the asm code and add up the instructions. Maybe you could do it with a simulator, but I don't use them.
_________________
The search for better is endless. Instead simply find very good and get the job done.

[Ttelmah]

You need to start by understanding the difference between assembler, and a compiler. In general, an assembler has a near 1:1 relationship between an instruction, and a processor instruction. A compiler conversely, is quite 'smart', and does a lot of work for you. So a single CCS instruction, like '*', is converted into a large sequence of code to perform a multiplication. Worse though, the change is not simple, with a constant '*=XuSec', but depends on the numbers being used. There are actually seven different '*' subroutines, (signed, and unsigned, for three different integer types, plus a float version), then the time will also depend on numeric conversions that may be performed on numbers before performing these operations (so if you multiply an int8, by a float, the int8, will be converted to a float, before performing a float multiplication), and also on how the values are stored (accessing an indexed array entry, will also take a lot more time, than accessing a simple variable). So the single '*' instruction, could probably have something over a hundred different timings associated with it. Repeat for all the possible instructions, and you have something probably in the order of tens of thousands of different timings. It then gets even worse, since the optimiser in the compiler will at times realise that things can be done differently, and save time. Things like using a shift to divide by two, handling temporary values differently to reduce times, etc. etc..
Times involved in single instructions, will vary also, with your own settings.
So, the instruction 'output_high(PIN)', translates to just a single machine instruction, if you have selected 'FAST_IO' mode, but typically to three instructions in 'STANDARD_IO' mode. Things like serial I/O, will depend on whether you are using a hardware UART, or a software UART, etc. etc..
Times involved can vary for a tiny fraction of a uSec (48MHz PIC, output_high, in FAST_IO mode = 0.083uSec), to many mSec (something like a sin, on numbers stored in an array, with the value stored back into an array, can easily reach over 600uSec), while a simple 'putc' with the serial set to 2400bps, using a software UART, or the hardware UART, when the buffer is full, will reach over 4mSec...

The only practical ways to actually predict the time involved in code, are to:
1) Run it through a simulator.
2) Instruction count in the assembler.
3) Run it for real, and toggle a pin or some similar signal, that can be measured.

Best Wishes

[PCM programmer]

This thread has instructions on how to use the MPLAB Simulator's
Stopwatch feature to measure the time required to run a section of code:
http://www.ccsinfo.com/forum/viewtopic.php?t=38351

[aarkey]

thank you.........all