I'm using an optical encoder to record the pulses of an optical disc.

Problem is it the encoder values does not add up. I think It's cause I'm passing it wrong.

#include "mbed.h"

Serial pc(USBTX, USBRX);
Serial ax500(p9,p10);
InterruptIn trigger_A(p26);
InterruptIn trigger_B(p25);
Ticker calculate;
int enc_A,enc_B=0;

void tick_A(){ // This is not adding up
enc_A++;
}

void tick_B(){ // This is not adding up
enc_B++;
}

void calc(){

pc.printf("Enc_A=%i \t Enc_B=%i \r\n",enc_A,enc_B); // Values keep printing 0 for both EncA and EncB.
}


int main() {
    
    while(1) {
        calculate.attach(&calc, 1.0); 
        ax500.printf("!a7F\r");
        ax500.printf("!b7F\r");
        wait(2);
        ax500.printf("!a00\r");
        ax500.printf("!b00\r");
        wait(2);
        ax500.printf("!A7F\r");
        ax500.printf("!B7F\r");
        wait(2);
        ax500.printf("!a00\r");
        ax500.printf("!b00\r");
        wait(2);
        
          
    }
}

Move the calculate.attach outside the while(1) loop. You need to attach this only once. It will continue to print every second. You should also declare enc_A and enc_B as 'volatile int' otherwise the compiler may optimise out the increment instruction in your interrupt handler. In main, before the while(1) You have to attach the tick_A and tick_B to the interrupt pins: trigger_A.rise(&tick_A)

Okay It does finally records values Thanks. But one of the encoder records massive amount of ticks like it was multiplying it.

I thought it was hardware. But checking it through scope doesn't show problem. A nice up and down waveform.

Is there a problem with the software interrupt colliding with the hardware interrupt?

#include "mbed.h"
Serial pc(USBTX, USBRX);
Serial ax500(p9,p10);
InterruptIn trigger_A(p26);
InterruptIn trigger_B(p25);
Ticker calculate;
volatile int enc_A=enc_B=0;

void tick_A(){
enc_A++;
}

void tick_B(){
enc_B++;
}

void calc(){

pc.printf("Enc_A=%i \t Enc_B=%i \r\n",enc_A,enc_B); // adding now but enc A sometimes stops recording. Enc B smoetimes records massive amount of ticks in the thousands.
}


int main() {

    calculate.attach(&calc, 0.1);
    trigger_A.rise(&tick_A);
    trigger_B.rise(&tick_B);
     
  

       while(1){ 
        ax500.printf("!a1F\r");
        ax500.printf("!b1F\r");
        wait(2);
        ax500.printf("!a00\r");
        ax500.printf("!b00\r");
        wait(2);

                }
   
}

Can you try to cache the variables before printing them?

void calc(){
int encA = enc_A, encB = enc_B;
pc.printf("Enc_A=%i \t Enc_B=%i \r\n",encA,encB); // adding now but enc A sometimes stops recording. Enc B smoetimes records massive amount of ticks in the thousands.
}

I think there is a good chance that you have some hardware bouncing. A small capacitor (say 1n, depending on update rate) on the input pin may fix that. Note that your scope probe may even be enough of a capacitive load to remove the problem.

You could also try to fix it in software by using Andy's Pindetect lib instead of the InterruptIn: http://mbed.org/users/AjK/libraries/PinDetect/lkyxpw

Could be too, I always use encoders with schmitt-trigger outputs, which don't have that problem.

Joey, in general I would recommend that you perform your printf()s from the main() function instead of the Ticker ISR. You can use a Timer in your main loop to detect when a certain amount of time has elapsed and then issue your printf() after resetting the timer.

However, this wouldn't cause you to pick up extra encoder counts but could lead to missed counts since only one encoder interrupt can be pended while you are sending the text out over the UART (unless you lower the priority of the UART0 interrupt.) If printf() happened to perform a dynamic memory allocation (which it does seem to do on occasion) then it can lead to heap corrupt if the main program is also freeing/allocating memory from the heap when you issue the printf from the ISR. This will lead to crashes in the best cases or corrupted data in other cases.

Okay I did all that and it appears to be fine. The problem now is I can't tell if I'm missing ticks. Since I have two optical encoders to measure ticks, I have two hardware interrupt. What happens when both of them happens at the same time? Is there a way to get around this so I am able to measure it right.

This would mean that my recorded ticks are inaccurate.

The inputs looks like this.

Why does the encoder have the same values for at least 4 times? It should be constant?