5

As @joan points out, the bouncetime parameter in RPi.GPIO does almost exactly the wrong thing: it means when your switch bounces, you'll get the very first event, but that may not actually be representative of the correct state of the switch. While trying to come up with a more robust solution, I also realized that RPi.GPIO calls interrupt handlers ...


4

Looking at the header it appears gpio_set_debounce isnt actually implemented which would explain why your code changes didnt make a difference static inline int gpio_set_debounce(unsigned gpio, unsigned debounce) { return -ENOSYS; } Try checking/printing the return value of your call to verify it is indeed so. (I wasnt able to find the headers for the ...


4

Interrupts are not supported in the python version of wiringPi2 because it's a wrapper of the original wiringPi C library. To quote the publisher of the module in issue 8 of it's github: ... I will have to look at implementing Python-wrapped interrupts in a different manner. At the moment your only choice is to set up a polling loop. Sorry! Try using RPI....


4

The RPi.GPIO module does not really debounce switches. The parameter is used to ignore all subsequent changes for the bouncetime after the first change is reported. A correct implementation would ignore all changes which were within bouncetime of each other (which would mean the first change would not be reported either). You will have to implement your ...


3

You may have identified the problem with a comment in your code. # Idle loop while 1: # Should I be doing something else here? pass The while loop will be using up all the spare CPU in the "busy spin". The only purpose of the loop is to keep the script running so that the callbacks can do their work. Try changing the loop to: import time ... # ...


3

Python may not be the best choice if you have high or sustained data rates. You would be much better off using C. Try the following Python. It should capture all the interrupts although if you have sustained high interrupt rates it may take time for them all to be processed. #!/usr/bin/env python import time import pigpio # http://abyz.me.uk/rpi/pigpio/...


3

It depends on how you want to program. If you write "bare-metal", i.e. with no operating system, you can handle gpio interrupts yourself. If you are running under Linux you can't directly receive interrupts as Linux handles all interrupts. However you can request that you are notified of gpio interrupts. That will add a latency of say 50-70 microseconds ...


3

you can debounce buttons in software as described above. If you have an oscilloscope you can find the settling time and wait to take your measurement of button state. However, this can seriously limit your ability to respond quickly in interrupt driven implementations. If you need a faster response it is possible to debounce in hardware using a simple RC ...


3

To the best of my knowledge, when you write software dealing with the interrupts, the IRQ number you will handle always comes from the first column. That's what the CPU is seeing. The 4th column reveals some details about the interrupt controller, and as you have seen, its format is very platform-dependent. A complex SoC may have more interrupt sources than ...


2

If you are talking about Linux you can't program an interrupt. Linux handles interrupts. If you are talking about bare metal then yes, you can program interrupts. You can ask Linux for a callback when an interrupt is detected (or probably about 50µs after at least on a Pi.). A callback may be for a timed event (example after 5 seconds). A callback may be ...


2

Turn out that the relay was creating the interference as some answers pointed out. Disconnecting the relay, did not trigger any interrupt. To solve the problem, I added at the top of my interrupt function a 10 milliseconds delay and a digitalRead on the pin. If the pin was still high after that, it meant that is was triggered by interference since a human ...


2

I think the best you can do is use a gpio event callback to set a shutdown flag and have your socket loop act on the flag when it is seen. If the socket loop may not be entered for some time then you will have to find an action which triggers a socket message. Alternatively use your gpio event callback to force a restart itself.


2

The code after the while True will never be exectuted. It would only be executed if the while loop terminates. So the following code has no effect. GPIO.setup(17, GPIO.IN, pull_up_down=GPIO.PUD_UP) print("Button pressed: " + str(index)) #TakePicture() try: GPIO.wait_for_edge(17, GPIO.FALLING) except KeyboardInterrupt: GPIO.cleanup() ...


2

The problem is likely in this line: while(1){ wiringPiISR(11, INT_EDGE_RISING, &interrupt); } Here you are continuously registering an interrupt function to pin 11. This is not how this should work. Two things need to change: You should register the interrupt/event function outside of the while(1) loop. WiringPi only needs to know this interrupt ...


2

The BCM2835 datasheet that you referenced was written for the first generation Raspberry Pi, in which there were only 2 banks of GPIO pins. On the BCM2837 (the SoC used in the Raspberry Pi 3), there are actually 3 banks of GPIO pins, so there are four interrupt lines going from the GPIO controller to the interrupt controller. gpio_int[0] for BANK0 (pins 0-...


2

If you put a printf in your callback (myInterrupt) you'll probably notice it is being continually called. If so the reason is because the input is floating (Google the term). I'd set the internal pull-up resistor on the BUTTON_PIN gpio to fix it at 3.3V. That way it will normally read high but will read low when the button is pressed. I'd also explicitly ...


2

I think you mean "gpio_int[0] to gpio_int[3]", right? Not "gpio_int[0] to gpio_int[4]". There is no gpio_int[4] mentioned in that manual. The bcm2835 manual that you referenced was written for the first generation Raspberry Pi, in which there were only 2 banks of GPIO pins. On the BCM2837 (the SoC used in the Raspberry Pi 3), there are actually 3 banks of ...


2

I'm not sure what is going wrong. My Python knowledge is sketchy. I'd dump the lambda and try the following (which works for me). #!/usr/bin/env python import RPi.GPIO as GPIO import time def callback(pin): print("Pin {} was pressed".format(pin)) try: pin = 21 GPIO.setmode(GPIO.BCM) GPIO.setup(pin, GPIO.IN) GPIO.add_event_detect(...


2

When the spi.xfer2() call returns the SPI transfer has been completed. So unless you are doing the transfers in multiple threads there is no problem. E.g. the following will work. while True: select CS 1 spi.xfer2() select CS 2 spi.xfer2() ... select CS 10 spi.xfer2()


2

No problem. It is safest to introduce a resistor. Connect any Pi ground pin to any of the other Pi's ground pins. Connect any Pi GPIO pin to any of the other Pi's GPIO pins via a resistor (if you have one, anything between 300 ohms to 100 thousand ohms will do). Set the transmitting GPIO as an output and the receiving GPIO as an input. The resistor is ...


1

I'm not sure. You can use sched_setaffinity to limit a process to a single core. You can also use sched_setaffinity to tell another process not to use that core. man sched_setaffinity That might get part way to what you want. You can also tell Linux not to use a core (at least I think there is a /boot/config.txt option or it may be a standard Linux boot ...


1

I am not sure about RPi.GPIO but Joan's pigpio library also offers callbacks so I will try to explain how this could be achieved with pigpio as an example assuming the technique can be transferred to RPi.gpio (after all it's just Python doing the trick). functools.partial(func, *args, **keywords) can solve this task: Return a new partial object which when ...


1

Here's the edit I suggested which isn't working: Pushing the button for more than 4 seconds, there are three valid IF conditions. You can use else if and use a range for the second condition: if buttonTime >= 4: buttonStatus = 3 elif buttonTime >= 2: buttonStatus = 2 elif buttonTime >= .1: buttonStatus = 1 With this little change ...


1

Pushing the button for more than 4 seconds, there are two valid IF conditions. You can use else if and use a range for the second condition: if .1 <= buttonTime < 2: # Ignore noise buttonStatus = 1 # 1= brief push elif 2 <= buttonTime < 4: buttonStatus = 2 # 2= Long push elif buttonTime >= 4: ...


1

The datasheet will specify if the chip generates an interrupt or not. I don't see why it would. The normal procedure is assert SPI slave select and send command (which triggers a reading) then read result and de-assert SPI. I guess you could poll ten times a second or so. The load on the Pi would not be measurable. Why not just use a rotary encoder like ...


1

The paragraph introducing that table (pg. 112) reads: The following is a table which lists all interrupts which can come from the peripherals which can be handled by the ARM. The diagram on page 89 and the description which follow do make it explicit only three interrupt lines are used. This does not seem like any kind of contradiction or inconsistency ...


1

Here's how I would code this with pigpio. The callback function is a bit clunky, but given your requirements I don't see how to simplify it that much. #!/usr/bin/env python import time import pigpio A=4 B=5 C=6 D=7 GPIO=[A, B, C, D] levels=[] # Store levels of buttons A, B, C, and D. cbs=[] # Store callback handles for buttons A, B, C, and D. def ...


1

My recommendation is to build 8 interrupt functions, two for each button, one for GPIO.RISING and one for GPIO.FALLING. You also keep a binary variable (e.g. int) which has bit 0 = button 1 (i.e. mask 0b00000001), bit 1 = button 2 (i.e. mask 0b00000010), ... , bit 3 = button 4 (i.e. mask 0b00001000). Upon entering the RISE callback for button 1, it sets its ...


1

I have a very similar scenario as you: A distributed domotic system all over the house with a central device (Raspberry PI) and a few satellite boards with I2C (PCF8574/PCF8591) and 1-Wire (DS18B20). Everything is connected via ethernet cat5e cables. To allow long range I2C communications I'm using the P82B96 I2C bus expander. For 1-wire communication is ...


1

All the GPIO may raise interrupts. On Pis with the 40 pin expansion header that is GPIO 2 to GPIO 27 (you can also use GPIO 0 and 1 but their use is discouraged). The following GPIO may be connected to hardware PWM (note, there are only TWO channels). 12 PWM channel 0 A+/B+/Pi2/Zero and compute module only 13 PWM channel 1 A+/B+/Pi2/Zero and compute ...


Only top voted, non community-wiki answers of a minimum length are eligible