It seems to work well but only with pins with interrupts but if i'm not wrong the board only have six of them, and I need maybe 20 pins (for 10 encoders).
I have had success using a single interrupt pin as the trigger to check the status of two encoders before.
Think of using the interrupt as a source and when either of the encoders changes state, the code checks both encoders for change.
10 encoders with just 2 pins would be amazing, however, if they are all being handled by the same pin how do you detect which of them is the one that emitted the signal?
From your posted link, you appear to be using manually operated mechanical encoders. Typically you do not need interrupts to catch changes as the Arduino is very fast compared to your fingers and polling in the loop will work. Much will depend upon how you write your code and if there are "blocking" elements like delay() or serial print.
Are the ten encoders rotating simultaneously? Are they turned by hand?
As you have found, debounce, either software or hardware with caps, is critical for these mechanical encoders.
Do these encoders have detents and how many pulses are there per revolution? The link does not say. Do you need to count every transition or is quarter or half resolution OK for your application? The code for reading the encoder will vary depending upon what resolution you require.
cattledog:
From your posted link, you appear to be using manually operated mechanical encoders. Typically you do not need interrupts to catch changes as the Arduino is very fast compared to your fingers and polling in the loop will work. Much will depend upon how you write your code and if there are "blocking" elements like delay() or serial print.
Are the ten encoders rotating simultaneously? Are they turned by hand?
As you have found, debounce, either software or hardware with caps, is critical for these mechanical encoders.
Do these encoders have detents and how many pulses are there per revolution? The link does not say. Do you need to count every transition or is quarter or half resolution OK for your application? The code for reading the encoder will vary depending upon what resolution you require.
Thanks for all that information, I'll try to answer your questions
I'm not printing any output to the serial monitor but I Serial.write() to an external app, not sure if it's the same for this case.
Are the ten encoders rotating simultaneously -> No, one at time
Are they turned by hand? -> Yes, all them
The don't have detents, they seem to have about 40 or 50 "ticks" per revolution
About resolution, I think is not critical, I'll be happy just fixing the problem I mentioned before when I randomly get a CCW count when moving the encoder CW, is this caused by the lack of debounce? Should I add a pull up resistor to each signal?
You would still need 11 pins I think, 1 for the combined A signals and 1 each for all the B signals. I've not tried it but if you store the last state of the 10 B pins then compare that against the current state when you get a change on any A you could make a decision about which one had moved and in which direction.
As you only have a single one move at a time that would be a bit easier although it wouldn't make much difference to the code (if any).
I don't think it would be hard to do but it's too hard to knock up some sample code.
The don't have detents, they seem to have about 40 or 50 "ticks" per revolution
About resolution, I think is not critical, I'll be happy just fixing the problem I mentioned before when I randomly get a CCW count when moving the encoder CW, is this caused by the lack of debounce? Should I add a pull up resistor to each signal?
These mechanical encoders are switches and the C pin is ground. A and B connected to the Arduino should be either on a pin declared as INPUT_PULLUP or use external pull up resistors to 5V. I am assuming, that there is no V++ pin on the encoder where 5v is applied. The more information you can provide on the encoders, the easier it will be to help.
Please define the term "ticks". Are these simply counts as you spin the encoder around, or are they positions you can feel with your fingers and it takes some force to move to the next position. The reason why I ask, is if there are no rest positions, the backwards counts could be due to the mechanical imprecision and it is actually slipping backwards. Forty or Fifty counts per revolution is pretty high for these cheap encoders.
Most likely, the backward count is caused by switch bounce and you will definitely need to debounce, but you said that you tried Jim's code, which he said was debounced, and you had the same erratic counts. Have your tried lengthening the debounce interval in his code?
I don't know how you will add debounce to the encoder.h library, and you may have to write your own code to read the encoders. It is not very complex, and you can certainly add whatever debounce works for the digitalRead of your device. You will make your task easier if you can devote 20 pins to the 10 encoders, which should be able to do on a Mega.
You can try a .47uf capacitor between the A pin and ground and the B pin and ground which will allow you to keep using the library.
All my available code is for optical encoders and I haven't integrated debounce into it, so I can't supply you with something that works, right now, but I will take a look at doing this.