Hello,

Can we get precise delays with Nops()?
Nop() corresponds to TCY right? In case of PIC18F, TCY=4/CrystalFreq right? (4 cycles per instruction)

Im using a PIC18F2550 with a 4MHz crystal and I just want to blink an LED on RA0 pin. I want it to be ON for 1 second and OFF for the same amount of time.

So, once 4 cycles are needed to acomplish one instruction it gives: Nop() = (4/4Mhz) = 1us. Right? Then, I need 1.000.000 Nops.

However the result is that the LED is ON for much more that 1 second. About 2.5 seconds...

Here is the code Im using:

#include <p18f2550.h>

void delay(unsigned int N){
    unsigned int i;
    for(i=0; i < N; i++) Nop();
}

void main(void)
{
    unsigned int i;

    //WDTCONbits.SWDTEN = 0;
    TRISA = 0x11111110;
    LATA = 0;

    while(1)
    {
        LATA = 1;
        for(i = 0; i < 50; i++)
            delay(20000);

        LATA = 0;
        for(i = 0; i < 50; i++)
            delay(20000);
    }
}

What am I missing?

Thanks in advance.

 

Have you factored in the time to actually process the loop ?

The loop variable needs to be decremented, compared against the limit and loop back if not finished - this all takes clock cycles. This applies to the delay function and the loop that calls it.

You are getting your 1,000,000 nops as well as 1,000,000 sets of other instructions etc.

This is, more than likely, when your extra time is coming from.

Have a look at the assembly language produced to see the extra instructions.

 

From your code I can not see which C compiler you use. But you should be able to look at your asm code output. Then you will see that your delay loop is more complex than just only NOPs. In your delay function. You will also have a counter variable. This need to be decremented and checked if the result is zero. If the result is non zero a NOP is executed. All this will take some machine code instructions to preform. Hence the long delay times

 

You are going to have to use assembly if you want accurate timing delays. Even if you can get "predictable" results with , the results may become unpredictable over the long term. If you change compilers or upgrade compilers you results may change because of the way the compiler chooses to interpret your C code or the way it chooses to optimize it.

I developed several accurate assembler based delays. The problem is that I used inline assembler and the c18 compiler is not resolving branches inside the asm block. So what happens is you have two delays withing the same function, the second delay branches to the first loop of the first call to the delay routine.

I think I will have to go to straight assembler but I need to learn how to pass values to assembler.

 

You are going to have to use assembly if you want accurate timing delays. Even if you can get "predictable" results with , the results may become unpredictable over the long term. If you change compilers or upgrade compilers you results may change because of the way the compiler chooses to interpret your C code or the way it chooses to optimize it.

I developed several accurate assembler based delays. The problem is that I used inline assembler and the c18 compiler is not resolving branches inside the asm block. So what happens is you have two delays withing the same function, the second delay branches to the first loop of the first call to the delay routine.

I think I will have to go to straight assembler but I need to learn how to pass values to assembler.

If you need precise timing use internal timers and interrupts. But for more simple task a delay made in software may do. If you only want to blink a LED at one second rate. It does not has much to say if the delay is a few cycles off.

 

If you need precise timing use internal timers and interrupts. But for more simple task a delay made in software may do. If you only want to blink a LED at one second rate. It does not has much to say if the delay is a few cycles off.

Ah yes! I got so wrapped up in programming delays I forgot to mention timers.

And in the OP's case, this might be the better option.


See my recent post on interrupts, near the bottom of this thread.

http://forum.allaboutcircuits.com/showthread.php?t=48460&page=3