Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

[SOLVED] Calculating time for a module and avoiding delay in ISR

Status
Not open for further replies.

tajiknomi

Member level 4
Joined
Nov 2, 2015
Messages
79
Helped
0
Reputation
0
Reaction score
0
Trophy points
6
Activity points
754
I want to know how can I calculate the reasonable time taken by the module in real time. Here is an interrupt module for which I want to calculate the time.
I will be using a 4Mhz oscillator as a clock and as PIC MCU take 4cycles for "most" of the simple statements so one statement would require almost 1us. (Correct me if i am missing something). I have wrote the program in C therefor it is quite difficult for me to know which statement(s) would require how much cycles.

Here is the module for which i want to calculate time. Another thing which i want to mention i.e. "Delay" in the interrupt routine is quite a wierd thing and i want to ignore it. Should i put the flag in ISR and then come back to the MAIN() to execute my delay ? Or shoud i execute the whole ISR in the main function and just identify the interrupt in the vector section ? What would be the best way and why ?
Code:
void interrupt(){

    if (INTCON.RBIF){
        char tmp;                                 // PORTB Change Interrupt ??
        if((KEYPAD_DATA & 0xF0) != 0XF0){            // Check to see that it is TRUE INTERUPT  ( i.e. Falling Edge Interrupt)
           char i;
           [B]delay_ms(20);[/B]                             // Avoid debouncing
           tmp=0x10;
           for(i=0;i<4;i++){                        // Find the row
              if((KEYPAD_DATA & tmp) == 0x00)
                   {row=i;break;}
              tmp=(tmp<<1);
           }
           KEYPAD_DATA=0X01;
           for(i=0;i<4;i++){                        // Find the column
              if((KEYPAD_DATA & tmp) == tmp)
                  {colum=i;break;}
              KEYPAD_DATA=(KEYPAD_DATA<<1);          //01,10,100,1000
           }
           tmp=array[row][colum];
           LCD_character_write((tmp+48));
           KEYPAD_DATA=0x00;                        // Clear DATA PORT
         }
           tmp=KEYPAD_DATA;                   // MUST Read KEYPAD_DATA, otherwise flag will not clear
           INTCON.RBIF = 0;                   // Clear the flag

     }
}

I would be glad if someone can direct me. Thank you :)
 

They best way is to never write such code again. NEVER use delays inside interrupts.
 

..as PIC MCU take 4cycles for "most" of the simple statements so one statement would require almost 1us. (Correct me if i am missing something). I have wrote the program in C therefor ..

The execution clock cycles are valid for assembly language instruction and not for C statements.
 

They best way is to never write such code again. NEVER use delays inside interrupts
But I need a delay in order to avoid debouncing, What should be done to avoid it?

The execution clock cycles are valid for assembly language instruction and not for C statements
Yes, but how could I measure it for the C statements, Should I convert the above module to Assembly and then check for each assembly-statement? Or there is another easy way?
 

ISRs must be as short as possible. Got interrupt, set(clear) the flag, return. And your main loop just does the rest part of the job. Variations might be, but general rule is the same: the shorter your ISR, the better your code works.
 

But I need a delay in order to avoid debouncing, What should be done to avoid it?

Only timer interrupt. Do not read keys in "normal" external interrupts.


Yes, but how could I measure it for the C statements, Should I convert the above module to Assembly and then check for each assembly-statement? Or there is another easy way?
No you need to count every generated machine code instruction - but if you have to do so - that means in 99% circumstances that your code is badly written. It is needed only in some very time sensitive situations (eg software implementation of UART).
 

Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top