Using grovepi.set_pin_interrupt

Archives GrovePi
1

Hi All

I’m using a Pi3b and a GrovePi with a wheel encoder connected to D4.

I can read signals if I use “grovepi.digitalRead(4))” but using interrupts to create a counter doesnt work. While I get a value back, it doesnt make any sense and remains static e.g. 121 or just 1

I’m looking to have the count of encoder wheel changes. I’ve accomplished the same using GPIO module and direct pin access, but I wanted to do this over the grovepi and a grove connector.

Any reasons why this wouldnt work?

import grovepi
import time

print('Start Program')
grovepi.set_pin_interrupt(4, grovepi.COUNT_CHANGES, grovepi.CHANGE, 65535)

while True:
  time.sleep(0.5)
  value = grovepi.read_interrupt_state(4)
  print("value is: ", value)
  print("raw encoder: ", grovepi.digitalRead(4))

Any suggestions? I’ve seen some comments that interrupts arent supported on the grovepi, but yet this function call is documented.

Cheers

Ross

1 Like
2

So having played some more it seems that perhaps I’ve misunderstood how this function works.

It seems that it behaves as follows:

  • At startup it stores the current value (0/1) and makes it available under read_interrrupt_state as a static value.
  • At startup it also begins to count the number of state changes(if you told it to) and continues to count until your defined “period” in ms expires at which point this accumulated count becomes the current value of read_interrupt_state for the next “perios” in ms duration.
  • rinse, repeat.

Am I correct? If so, I think there is no way to use this for my use case which is as a wheel encoder because you would have to synchronise the time you made the function call too closely with the period duration or risk losing all your count data.

Ideally I would like to access the actual count in “real time” instead of the count from the last defined period. Any thoughts?

Thanks

Ross

1 Like
3

A couple of thoughts here:

Are you using hardware i2c or software i2c? (i.e. are you connected to an i2c connector or an “analog” connector.)

I ask this because hardware i2c on the Raspberry Pi has its issues and may be unsuitable. You can find my article on this issue here:

Since I’m not an expert on either the Grove Pi or i2c, I am going to ask a few experts to step in.

@cleoqc @mitch.kremm @KeithW and @cyclicalobsessive are my go-to people for i2c problems. Maybe they can help?

4

Hi @jimrh

Thanks for your reply. This is through the Grove Pi shields grove digital ports, rather than the bare pins. I believe this abstracts away from the direct GPIO to the PI which is where part of this issue lies. I dont want to use the pins directly because I will have students using this in a education centre and grove connectors reduce the chance of damage and mistakes.

I think I will jst have to live with it for now and am considering grove hat which seems to pass thru the connections.

Kind Regards

Ross

1 Like
5

This is the big problem.
Even if the board somehow abstracts the specific i2c pins on the Pi, you will still have problems because of the sucky implementation on the Pi itself.

The only real solution is to implement i2c in software (which is what Dexter/Modular Robotics does), or use a controller board that implements i2c correctly. (i.e. Something other than the Pi.)

Are you using an Arduino shield, or a hat specifically designed for the Raspberry Pi?

I’m not an expert here, but I would suspect that Arduino shields might not work, or the implementation would be non-trivial.