Triggering interruptions with incremental encoders and OpenCM 9.04

I am working on two counters for two incremental encoders. For this, I am using a OpenCM 9.04 C type and the Arduino IDE.
I want each counter to increment when the corresponding encoder goes from low to high (which should trigger the interruption). I have achieved this with encoder 1, which is connected to pin 18. I tried to connect encoder 2 to different pins but they don’t trigger all the interruptions (should be around 900 and they trigger 50 or less).

Note: If I connect encoder 2 to pin 18 it also works, but I can’t find another working pin for encoder 1. So the problem shouldn’t be the encoder, I think it can be the configuration or the pins.

pinMode(11, INPUT_PULLUP);
pinMode(18, INPUT_PULLUP);
attachInterrupt(digitalPinToInterrupt(11), count_0, RISING);
attachInterrupt(digitalPinToInterrupt(18), count_1, RISING);

void count_0(){
if ((millis() - lastDebounceTime_0) > falsepulseDelay) {
lastDebounceTime_0 = millis();
counter0 += Direction;

void count_1(){
if ((millis() - lastDebounceTime_1) > falsepulseDelay) {
lastDebounceTime_1 = millis();
counter1 += Direction;

  • Are both encoders incrementing at the same time?
  • When you switch the encoders and pins (encoder 1 to pin 11, and encoder 2 to pin 18) do you also receive less interrupts on pin 11?

One possible cause of the issue is that interrupts are disabled while processing an interrupt. Depending on how quickly these encoders are sending interrupts, and how the priority for these interrupts is decided by the microcontroller, they might be constantly firing the interrupt on 18 and adding ones on 11 to a continually growing queue.

Hi Jonathon, thanks for your reply!

Yes, when I switch the encoder and pins I also receive less interrupts on pin 11.

I tried the same code using Arduino uno and it works. Can it be a problem in the CM board?

Thanks in advance!

I did some digging on the OpenCR’s GitHub repo and found an example program documenting multiple inturrupts on the OpenCR board.

Could you try modifying that to see if it behaves better for your use case? I notice that the example doesn’t use the recommended digitalPinToInterrupt() function, so it’s possible that the function behaves differently on the OpenCM.