fattoresaimon / i2cencoderv2.1 Goto Github PK

Hi. It would be very useful for me to accelerate the CVAL steps when the encoder is rotated quickly to manage large values without losing precision.
I've used this feature before through traditional rotary encoder libraries and was fine with it.
Is there any hope that you will implement it or is it better to manage externally by activating RelMode?
Isn't relative mode implemented on recent mini encoders?
Thank you, -Fede.

I'm writing a driver in Rust for the I2CEncoderV2 and noticed that my initialisation sequence does not work because as a good citizen I would like to do a RESET followed by proper initialisation but when I set the reset bit the following I2C interaction automatically receives a NACK.

Please could we have a better mechanical drawing showing the X-Y dimensions of:

1. The fixing holes
2. Pin1 of every connector.
   Regards

Triple pressing acts as a double push instantly followed by a single press. Realistically this should still fall under control of the debouncing methods, given that's it's highly unlikely someone wants to action a double press and then a single press like that. Ideally, it should not register the 3rd press... so in other words, it should action the double press method and ignore the 3rd press (within the debounce period)

Hello,

I don't know if I can post this topic here, but I would like to know if the embedded software is available/compatible for a PIC16F18346 which are similar to a 18345

Thanks !

BR
Adrien

Hi! I am very interested in this project because I am learning PIC programming and also wanting to use rotary encoders in a project. I see in your MPLAB project that you have configured the two CLC peripherals to use "2-input D flip-flop with R" configuration and reading the RA and RB pins (RC0 and RC1). Could you please explain what logic is going on here that makes this work? I am only familiar with the rotary encoders which use 4 "steps" between each detent (is this what you are using?) and am curious how the CLCs correctly interpret this?

Thanks for any info!

There's a RMOD bit in the general configuration, but what does Reading Mode X2 mode and X1 mode actually mean?

Hello! I'm designing some board in KiCad and going to use i2c Encoder there. It would be great to have it as a symbol I could insert to my design to get correct pin placement, names, etc., and footprint, all of that for inserting the i2c Encoder board into mine.

Even better is to have different connection variants in same library - for soldering, for inserting, with GP ports also being soldered, or without, in single KiCad library.

Thank you!

Congratulations on an excellent device, and thank you for porting it to Python for RPi!
I don't understand why there is not full quadrature access available - I have 24 pulses on my encoder, therefore I should be able to identify 96 positions in a revolution. I am keen to use very basic rotary encoders for very basic positional sensing and if I can get full X4 quadrature then I get twice the X2 resolution for free!

Hi,

i bought version 2.1 and i am trying to run it on a raspberry 4 later in combination with the led ring (both connected to the RPi).
I2C is set to 100kHz in the config.txt

Now it occurs after some random turns of the encoder that the, i think, mc of the encoder crashes because i2cdetect -y 1 still sees my LED ring, but the encoder is gone after the error:

Encoder min!
sum: 1289
Traceback (most recent call last):
  File "/home/pi/i2cring/./drehencoder.py", line 58, in Encoder_INT
    encoder.updateStatus()
  File "/home/pi/i2cring/i2cEncoderLibV2.py", line 192, in updateStatus
    self.eventCaller (self.onChange)
  File "/home/pi/i2cring/i2cEncoderLibV2.py", line 167, in eventCaller
    event()
  File "/home/pi/i2cring/./drehencoder.py", line 19, in EncoderChange
    temp = encoder.readCounter32()
  File "/home/pi/i2cring/i2cEncoderLibV2.py", line 298, in readCounter32
    return (self.readEncoder32(REG_CVALB4))
  File "/home/pi/i2cring/i2cEncoderLibV2.py", line 624, in readEncoder32
    data = self.i2cbus.read_i2c_block_data(self.i2cadd, add, 4)
  File "/home/pi/.local/lib/python3.9/site-packages/smbus2/smbus2.py", line 617, in read_i2c_block_data
    ioctl(self.fd, I2C_SMBUS, msg)
OSError: [Errno 121] Remote I/O error
Traceback (most recent call last):
  File "/home/pi/i2cring/./drehencoder.py", line 58, in Encoder_INT
    encoder.updateStatus()
  File "/home/pi/i2cring/i2cEncoderLibV2.py", line 171, in updateStatus
    self.stat = self.readEncoder8(REG_ESTATUS)
  File "/home/pi/i2cring/i2cEncoderLibV2.py", line 610, in readEncoder8
    data[0] = self.i2cbus.read_byte_data(self.i2cadd, add)
  File "/home/pi/.local/lib/python3.9/site-packages/smbus2/smbus2.py", line 433, in read_byte_data
    ioctl(self.fd, I2C_SMBUS, msg)
OSError: [Errno 121] Remote I/O error
^CTraceback (most recent call last):
  File "/home/pi/i2cring/./drehencoder.py", line 114, in <module>
    pass
KeyboardInterrupt

After this error i have to disconnect the Encoder/LED Ring. It doesnt help to just rerun the script.

I tried it multiple times to see if there is a kinf of pattern. But it crashes after 700.... 3000 clicks. Slow or fast does also seem to do the same.
Any ideas?

import smbus2
import RPi.GPIO as GPIO
from time import sleep
import i2cEncoderLibV2
#import ledring


oldEncValue = 0
sum=0

minLedLoudness = 34
maxLedLoudness = 0

def EncoderChange():
    encoder.writeLEDG(100)
    global sum
    sum = sum +1
    print('sum: %d' % (sum))
    temp = encoder.readCounter32()
    oldEncValue = temp
    print ('Changed: %d' % (temp))
    
    #ledring.LEDRing_Set_RGB(temp,0x12345)
    
    #ledring.LEDRing_Set_RGB(temp+1,0)
    #ledring.LEDRing_Set_RGB(temp-1,0)
#    if temp >= minLedLoudness:
#        temp = minLedLoudness
#    ledring.LEDRing_loudness(temp,0x50)
    #encoder.writeLEDG(0)

    

def EncoderPush():
    #encoder.writeLEDB(100)
    print ('Encoder Pushed!')
    #encoder.writeLEDB(0)

def EncoderDoublePush():
    #encoder.writeLEDB(100)
    #encoder.writeLEDG(100)
    print ('Encoder Double Push!')
    #encoder.writeLEDB(0)
    #encoder.writeLEDG(0)

def EncoderMax():
    #encoder.writeLEDR(100)
    print ('Encoder max!')
    #encoder.writeLEDR(0)

def EncoderMin():
    #encoder.writeLEDR(100)
    print ('Encoder min!')
    #encoder.writeLEDR(0)

def Encoder_INT(self):
    encoder.updateStatus()
    

        


GPIO.setmode(GPIO.BCM)
bus = smbus2.SMBus(1)
INT_pin = 4
GPIO.setup(INT_pin, GPIO.IN, pull_up_down=GPIO.PUD_UP)

encoder = i2cEncoderLibV2.i2cEncoderLibV2(bus, 0x50)
#ledring= ledring.ledRing(bus, 0x28)
#ledring.setup()

#ledring.LEDRing_ClearAll()
#ledring.LEDRing_Set_RGB(1,0x12345)
#ledring.LEDRing_Set_BLUE(34,0x60)
#ledring.LEDRing_Set_BLUE(47,0x60)

encconfig = (i2cEncoderLibV2.INT_DATA | i2cEncoderLibV2.WRAP_DISABLE | i2cEncoderLibV2.DIRE_RIGHT | i2cEncoderLibV2.IPUP_ENABLE | i2cEncoderLibV2.RMOD_X1 | i2cEncoderLibV2.RGB_ENCODER)
encoder.begin(encconfig)

encoder.writeCounter(0)
encoder.writeMax(47)
encoder.writeMin(0)
encoder.writeStep(1)
encoder.writeAntibouncingPeriod(8)
encoder.writeDoublePushPeriod(50)
encoder.writeGammaRLED(i2cEncoderLibV2.GAMMA_2)
encoder.writeGammaGLED(i2cEncoderLibV2.GAMMA_2)
encoder.writeGammaBLED(i2cEncoderLibV2.GAMMA_2)

encoder.onChange = EncoderChange
encoder.onButtonPush = EncoderPush
encoder.onButtonDoublePush = EncoderDoublePush
encoder.onMax = EncoderMax
encoder.onMin = EncoderMin

encoder.autoconfigInterrupt()
print ('Board ID code: 0x%X' % (encoder.readIDCode()))
print ('Board Version: 0x%X' % (encoder.readVersion()))

encoder.writeRGBCode(0x640000)
sleep(0.3)
encoder.writeRGBCode(0x006400)
sleep(0.3)
encoder.writeRGBCode(0x000064)
sleep(0.3)
encoder.writeRGBCode(0x00)

GPIO.add_event_detect(INT_pin, GPIO.FALLING, callback=Encoder_INT, bouncetime=10)

while True:
  #  if GPIO.input(INT_pin) == False: #
   #     Encoder_INT() #
    pass

First I'm enabling the RGB LED by setting the ETYPE bit and then I'm calling a function which tries to do a write on RLED, then GLED then BLED in succession but depending on the combination of colours and the previous value this yields completely random results; single colours mostly work, combinations of RGB deliver completely random results.

Reading back the RLED, GLED and BLED registers shows the correct colours I've set before. Fading is disabled.

Because it is now a more advanced product and you can use more than one, make it event driven. Hopefully you understand the idea and why this would be nice. It makes it easier to handle more objects at once and avoids a if then else mess (structorize the code).

for example:

#define MAX_ENCODERS 5
#define ENC_ID_CHANNEL1 0x30
#define ENC_ID_CHANNEL2 0x31
#define ENC_ID_CHANNEL3 0x32
#define ENC_ID_CHANNEL4 0x33
#define ENC_ID_CHANNEL5 0x34


i2cEncoderLibV2* encoders[MAX_ENCODERS];

// Just an example event handler: 
void myRotaryEncoderChangeEvent(  i2cEncoderLibV2* opSender, int8_t iValue )
{
  Serial.print( opSender->addres );
  Serial.print( "has been changed to " );
  Serial.println( iValue );

 if( opSender->addres == ENC_ID_CHANNEL3 )
 {
   // do something nice 
 }
}

void setup()
{ 
  uint8_t i = MAX_ENCODERS;
  while( i-- )
  {
    encoders[i]= new i2cEncoderLibV2(ENC_ID_CHANNEL1+i);
    encoders[i]->onEncoderChange = myRotaryEncoderChangeEvent;
  }  
}

void loop()
{
  uint8_t i = MAX_ENCODERS;
  while( i-- )
  {
     // if something has been changed, it triggers an event if assigned
     encoders[i]->update();
  }  
}


--------------------

I'm using the kickstarter RGB encoder.

Here are my initial config values:

{REI2C_GCONF, REI2C_GCONF_ETYPE},
{REI2C_CVAL, 0}, // Counter Value
{REI2C_CMAX, 32}, // Counter Max value
{REI2C_CMIN, -32}, // Counter Min value
{REI2C_ISTEP, 1}, // Increment step value

With GCONF = 0x20 (DIRE=0) turning it clockwise decrements the cval.
With GCONF = 0x24 (DIRE=1) turning it clockwise still decrements the cval.

I would expect that:
DIRE=0 a clockwise turn would increment cval.
DIRE=1 a clockwise turn would decrement cval.

It seems that some delay() is needed after writeEEPROM() issued. Without this delay(), following read/write I2C register requests will fail and Arduino board and the I2C Encoder lose their sync.

for (int k = 0; k < 16; k++) {
  for (int j = 0; j < 16; j++) {
    Encoder.writeEEPROM(k*16+j, (k*16+j));
    delay(3);  // THIS IS NEEDED
  }
}

Is there any method to detect if the I2C Encoder is ready to receive next I2C request?

i've got two fresh v2.1 boards, wired up with a plain std. encoder with switch. my multimeter shows the switch conducts exactly when pushed. the boards are unconfigured, ie. using the
default values for all config bits, which according to the datasheet should mean 'std encoder'.
symptom: the i2cencoder doesn't report anything in the button-related bits of ESTATUS when or
after i press the button.

tldr: looks as if STD_EncoderMode() isn't called unless GCONF is written.
workaround: write to the GCONF register even if it's just the same 0x0 as the defaults.
proper fix: i think that the function FirstConfig needs to be called sometime during startup, not just as part of RegisterWrite.

minor problematic aspects: the datasheet doesn't describe the pinout of the 5 pins below the gp1/2 pins (which are listed in figure 1.16). the hardware/schematic sheet also doesn't describe how a std encoder's switch is wired up. would be great if that was amended in a future revision.

i've beeped the board traces and figured out that way that the 5 pins correspond
(top near 'v2.1' to bottom) to PWM_LR_GP3, PWM_LG_SW, SW_RGB, PWM_LB_SWC and VCC.
the two switch terminals are connected to PWM_LG_SW and PWM_LB_SWC.

digging through the code in Encoder.c and GPports.c i see that in std encoder mode
PWM_LG_SW should be pulled up weakly, and PWM_LB_SWC is pulled low. PWM_LG_SW is then read as inverted input.

the crux: if i just power up the chip and start using it then the multimeter tells me that PWM_LG_SW is floating. only after i write to GCONF the pull up is pulling up and things start working.

I am still figuring out what is happening.
I got the encoder working on Arduino Uno 5v, and also on A CYPRESS PSOC processor where I am planning to use it. But trying a simple I2c.scan I can't discover the device on a micropython pyboard 3v.
The strangest is though I put 2 I2c devices in series. The encoder and a pressure sensor. With exactly the same configuration and termination I tried on all 3 processors and having a different outcome. Scanning on micropython reveals only the pressure sensor on the bus, and on the PSoC I can discover only the encoder. When I connect only the encoder with termination I also can't discover on micropython. No idea what is going on here, anybody?

Every time the GCONF (add:0x00) register is wrote, the ISTEP (add:0x14 - 0x17) register is reset to the default value of 1.

Workaround: After writing the GCONF register restore the correct value of the ISTEP.