Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

Encoder to Arduino

Look good!

I can see a couple of possible optimisation tweaks for the encoder routine:

Only do the IF comparisons if lastenc != enc

Once the equal states are omitted, the long comparison lines can actually be removed and increment or decrement come down to XORing the middle two bits of the sum!
If they are different (XOR result = 1), increment. Otherwise, decrement.

Something like:

if ((sum ^ (sum << 1)) & 0x04) encValue++;
else encValue--;

That skips the invalid states, where the count changes by two - but if that ever occurs, it's lost sync anyway & a faster routine reduces the chance of that happening.
I attempted to implement your suggestions into the sketch & this seems to work very well.
Code:
void updateEnc() {
  int MSB = digitalRead(encPinA);  // MSB = most significant bit.
  int LSB = digitalRead(encPinB);  // LSB = least significant bit.

  int enc = (MSB << 1) | LSB;        // Converting the 2 pin value to single number.
  if (lastEnc != enc) {              // Only do the IF comparisons if lastenc != enc
    int sum = (lastEnc << 2) | enc;  // Adding it to the previous encoded value.

    if ((sum ^ (sum << 1)) & 0x04) encValue++;  // XORing the middle two bits of the sum
    else encValue--;

    lastEnc = enc;  // Storage value for the next time
  }
}
 
Yes, I have never really looked at the Uno, I always use the Mega 2560 for testing things, only because I have a few of them.
The Pro Mini 5V is essentially a Uno in a tiny footprint, with a SM AT328, and no serial to USB converter (where a Nano is also Uno compatible includes the serial to USB converter, so is larger). The Pro Mini is very convenient for building in projects as it's so small, and you can develop on a Uno, and then just still the code in a Pro Mini.

Just one word of warning, you need to be wary of the Pro Mini 3.3V - rather bizarrely the 328 will only run at a lower speed at 3.3V, so it runs at 8MHz instead of 16MHz for the 5V version.
 
The Pro Mini 5V is essentially a Uno in a tiny footprint, with a SM AT328, and no serial to USB converter (where a Nano is also Uno compatible includes the serial to USB converter, so is larger). The Pro Mini is very convenient for building in projects as it's so small, and you can develop on a Uno, and then just still the code in a Pro Mini.

Just one word of warning, you need to be wary of the Pro Mini 3.3V - rather bizarrely the 328 will only run at a lower speed at 3.3V, so it runs at 8MHz instead of 16MHz for the 5V version.
I didn't realise the clock speed was voltage dependant on the 328, interesting.
Is that the only difference between the 3.3v & the 5v Pro Mini version being basically the voltage regulator?
 
I didn't realise the clock speed was voltage dependant on the 328, interesting.
Is that the only difference between the 3.3v & the 5v Pro Mini version being basically the voltage regulator?
And the crystal as well, and that's all - PIC's run fine at different voltages, so it's quite strange the 328 is voltage dependent.

I've got two draws with Mini Pros in, you have to make sure you get the right one! :D
 
PIC's run fine at different voltages
Many/most of the older PICs have a freq vs VDD dependency. You don't tend to see it so much since they split the devices into 'F' and 'LF' rated parts. They only used to typically spec the 'F' devices for around 4V-5V operation, but the 'LF' parts show the limits.

Newer devices/families don't tend to have those restrictions.
 

Latest threads

New Articles From Microcontroller Tips

Back
Top