So the project I'm working on calls for the use of a rotary encoder, so I decided to write a library to do the decoding.My library uses an interrupt on timer2 to poll the pins and decode the signals.At the moment it only supports one encoder, but I hope to add the possibility for more encoders in the future.

Thanks for making that change. It's good to have names that are different enough for the compiler to not have conflicts when both are installed. Calling it "V2" might imply it's a newer version of the same library, but that's a minor issue. I'd personally prefer you used a more distinctive name, but that's really your call.

Your library uses a different approach that could be really nice for people using boards with a very limited number of interrupt pins, like Arduino Uno. Would be nice if the name somehow made that difference and its advantages clear.

Regarding the library, if you're willing to consider another idea, you might make it a C++ class? That's the normal way almost all Arduino libraries are structured. The object constructor could automatically assign the "_encNum", perhaps using an array or bitmask of which ones are already in use? You'd make _encNum a private or protected class member, so there would be no need to pass it on every function call.

If you add a 32 bit counter, you could even give your C++ object the same read() and write() functions my library has. Then people could use it as a drop-in replacement. They could #include both libraries in the same project and use your library for some encoders and mine for others. All they'd do to change which encoders use which library is change the object name where the instance is created.

C++ has a lot of complex features, but for just making this an object, you can probably use almost any Arduino library as a guide.

The Encoder library I published has a lot of tricky optimizations, so it's probably not the best one to look at for an example. Libraries like Stepper or Servo are probably good ones to use for an example.

In my project, I'd need to declare an encoder dynamically. I mean, declare the encoder first, and assign pins in a second time after reading a sort of config file.is there a way to modify your library, creating a kind of "assign" function to dynamically declare the pins number instead of passing the values at declaration?

In my project, I'd need to declare an encoder dynamically. I mean, declare the encoder first, and assign pins in a second time after reading a sort of config file.is there a way to modify your library, creating a kind of "assign" function to dynamically declare the pins number instead of passing the values at declaration?

In theory, you should be able to create instances of the library with "new". But in practice, it doesn't work. There's some sort of bug. Details here:

Fixing this is on my to-do list, but currently I'm working on many much higher priority tasks. If you'd like an update when I work on this bug, please subscribe to that thread. That's where I'll post any updates about a fix.

It might be nice to change your library's name slightly, so it can be used along side this long-established library without the .h files conflicting.

It says there that SoftwareSerial is very likely to cause problems. I'm using GSM Shield on my circuit via hardware serial and Serial LCD via software serial. My microcontroller is an Arduino Uno clone. I'm about to use a rotary encoder to measure soil movement in a mountain. What problems would I be facing? Does it have something to do with my LCD displaying incorrectly? Can I turn off the interrupt whenever the Serial LCD comes up in the code? Any suggestions? Thank you in advance

SoftwareSerial disables interrupts while sending or receiving a byte. For example, at 9600 baud, 8N1 format, a byte takes 1.04 ms. During that time, the Encoder library can't recognize any changes on the encoder pins.

The pin interrupt hardware will save the fact that the pin changed, so as long as only 1 change happens during that time, it will be picked up later. But 2 missed changes can cause incorrect counting.

With hardware serial, interrupts are disabled for only a few microseconds, instead of over 1000 us, so even fairly fast movement on encoders can be properly tracked while serial data flows.

It does not disable interrupts for the entire byte, so it will interfere much less with Encoder. However, AltSoftSerial depends on Timer1, so it's incompatible with any other libraries that need Timer1.