hello all
i want to introduce delay in program in microsecond range. can any one give me some examples for lpc17xx.
Thanks in advance.
"LPC_TIM1->MR0 = delayInMs * (9000000 / 1000-1);"
They are driving the timer with a 9MHz signal.
So to wait 1ms, you have to wait 9000000/1000 ticks. -1 is a correction because the match register is only compared once/tick.
So MR0=0 would mean that the timer would compare (and potentially auto-reset) with MR0 once/tick. MR0=1 would mean a comparison every second tick (at 0 and at 1).
Thanks for your reply.
i just wanted to know which method is more advantageous? Is there any limitation in using a particular method for a given situation.
Thanks again
Yes, there are limitations.
Polling a timer requires a fixed amount of setup time. So it can't be used for too short delays. Very short delays is then better handled by counting clock cycles from NOP instructions or similar - and when counting clock cycles, you should use assembler so _you_ control the instructions you are counting.
But as soon as the delay times are long enough that you can accept the setup times, then you get the advantage that polling a timer can be done in C.
it means i can't use timer method for 1 microsecond delay?
One more thing in the timer example they have mentioned CCLK = 72 MHz
In the system_lpc17xx.c file PCLKSEL0 have been set as 0x00000000 i.e. peripheral clock selection for timer 0 will be CCLK/4 72 / 4= 18MHz
But the counter value have been set according to 9MHz.
If you can set up the timer and reach the polling loop within 72 clock cycles, then you can use the timer method.
The issue here is if you can guarantee that your C compiler will always manage to produce code that reaches the polling loop within 72 clock cycles. Next thing is that you don't know what instructions the C compiler uses for the polling loop, so you don't know if you may get 1, 2, 3, 4, 5, ... clock cycles worst-case error because of where you are in the loop.
For very short delays using the timer method, it's best to write the code in assembler.
About 9MHz instead of 18MHz - I don't have an explanation right now, without looking closer at the processor. Maybe the example was originally written with the peripherial clock setting 11 instead of 00, which is 1/8 division. The documentation seems to indicate that the counter should be updated every PCLK when PR=0, so 18000000/1000-1 would have seen a more logical.