|
|
View previous topic :: View next topic |
Author |
Message |
kavarwax Guest
|
Problem Timer2 |
Posted: Fri Nov 23, 2007 9:48 am |
|
|
Hello everybody,
I have a problem with my Timer2.
I have set it on a 50µs cycle.
setup_timer_2(T2_DIV_BY_4,24,1);
When i just test output_bit(PIN_C0, !input(PIN_C0)); it works very fine (the C0 switch value each 50µs).
However I added more code inside the TIMER2 (about 15 lines), and now, the duration of my output_bit is no longer 50µs but something between 25 ans 40µs (it is random).
Does anybody knows if too heavy code inside a Timer can slow it down or if some routines takes long time before switching to next ones ?
I thaught that routines took only few nano seconds to be executed, but it seems not to be the case...
Can anybody help me please ?
Thanks,
Kavarwax |
|
|
Ttelmah Guest
|
|
Posted: Fri Nov 23, 2007 10:29 am |
|
|
nSec!......
Different planet!.
Each instruction, takes _4_ clock cycles. Instructions like jumps, take 8. This for the actual machine instructions. A single 'C' instruction, will typically involve anything from a couple of machine instructions, to _several thousand_...
On your processor, if the line you have posted, takes 50uSec, then your master clock is 8MHz. Each machine instruction will then take _0.5uSec_.
So, yes 'nSec', but rather a lot of them!...
For an interrupt, there is typically about 60 machine instructions of overhead, involved in saving the registers, and restoring these, before and after the 'handler' is called.
The behaviour will depend on the code. If the code itself involves variable times (anything with a test, some arithmetic routines, etc. etc.), then on some occasions the interrupt will set a second time _before_ the routine exits. On these, the interrupt clear at the end of the routine, will result in the second interrupt being immediately cleared, and _skipped_, giving 'fast' execution. When this happens, the timing will depend on the duration of the handler itself, and when the previous interrupt actually occurred. In this case, 'yes', too much code in the handler can result in the timer apparently running fast (it doesn't, but individual ticks are being thrown away).
You have no hope at all, of handling any significant code, on a processor at 8MHz, in a 50uSec interrupt.
Best Wishes |
|
|
Kavarwax Guest
|
|
Posted: Mon Nov 26, 2007 5:15 am |
|
|
Hello Ttelmah
Thank you for your answer.
You right, I'm using a 8MHz quartz.
So if I understand well, faster is my quartz, faster the source code will be executed.
Thats mean if I use a 40MHz quartz instead of a 8MHz, I will execute routines 5 times faster, so 0.1µs instead of 0.5µs for a standard C line.
So my 20-25µs delay will decrease at 4-5µs delay using the Timer2.
Is my analysis too simple ?
Secondly, I used a PIC16F870, and I'm changing with a PIC18F2420.
Will it change anything regarding the speed of code executing ?
Note that actually my µController is full memory : 90% RAM, 99% ROM.
Thank you for your support ! :-) |
|
|
Ttelmah Guest
|
|
Posted: Mon Nov 26, 2007 5:59 am |
|
|
Basically yes.
However, for an _instruction_, _not_ for a 'C line'.
A _single line of C_, can represent tens of thousands of instructions. For instance, the single operation a=b/c, where the values are floating point numbers, will use about 1700 processor instructions.
Remember also, that the fastest _crystal_ allowed, is often 25MHz. For speeds above this, either an external oscillator, or an internal PLL is needed.
The 18 chip, will add slightly the the overhead on interrupts (typically another half dozen instructions), but will be quicker at some operations (such as multiplication, which is typically about twice as fast for a given clock rate, because of the hardware multiplier).
Best Wishes |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|