gpio event at level change

it is possible to have a event if a gpio pin change from high to low or low to high?
i try to use a thread to watch a pin 5x a second but the app take 25% cpu.
i need to watch a movement sensor pin for house alarm system.
after phyton i use currently node-red and i will replace all with a linux xojo app at my raspberry pi 3.

my base

Hi Markus,

It seems like you are looking for an interrupt (fast polling) of a sensor. If you have my book on Raspberry Pi, there is Example 19-1 and Example 22-2 which uses the GPIO.WiringPiISR interrupt. There is more data on priorities, interrupts and threads at: Interrupts that is helpful.

I found that WiringPiISR worked pretty good, and I was having trouble with resolution and interference below about 600 microseconds.

Hello Eugene, yes that is what i was looking for.
in GPIO.xojo_code it seems it is not supported for some reason.

// Unfortunately, wiringPiISR runs the callback on a preemptive thread
// making this method unsafe to use with Xojo.

[code]Protected Function WIringPiISR(pin As Integer, edgeType As Integer, p As Ptr) As Integer
// int wiringPiISR (int pin, int edgeType, void (*function)(void)) ;
// This function registers a function to received interrupts on the specified pin.
// The edgeType parameter is either INT_EDGE_FALLING, INT_EDGE_RISING,
// initialisation of the pin will happen – it’s assumed that you have already
// setup the pin elsewhere (e.g. with the gpio program), but if you specify one
// of the other types, then the pin will be exported and initialised as specified.
// This is accomplished via a suitable call to the gpio utility program,
// so it need to be available.
// The pin number is supplied in the current mode – native wiringPi, BCM_GPIO,
// physical or Sys modes.
// This function will work in any mode, and does not need root privileges to work.
// The function will be called when the interrupt triggers.
// When it is triggered, it’s cleared in the dispatcher before calling your
// function, so if a subsequent interrupt fires before you finish your handler,
// then it won’t be missed. (However it can only track one more interrupt,
// if more than one interrupt fires while one is being handled then they will be ignored)
// This function is run at a high priority (if the program is run
// using sudo, or as root) and executes concurrently with the main program.
// It has full access to all the global variables, open file handles and so on.
// See the isr.c example program for more details on how to use this feature.

	 [b] // Unfortunately, wiringPiISR runs the callback on a preemptive thread
	  // making this method unsafe to use with Xojo.[/b]
	  // #If TargetARM And TargetLinux Then
	  // Soft Declare Function wpISR Lib "" Alias "wiringPiISR" (pin As Integer, mode As Integer, p as ptr) As Integer
	  // Return wpISR(pin, edgeType, p)
	  // #Endif
	End Function[/code]

I am trying to remember a discussion that I had about cooperative vs Preemptive threading. Since Xojo is not compatible with Preemptive threading, there is a chance that there could be a failure when the Pi’s software (not Xojo) hands control from one thread to another. If there was a way to have both threads with the same priority then this would greatly reduce the chances of errors.

Would I program a space-shuttle program with Xojo and wiringPiISR? Probably not. For most uses such as remote controls or timing cyclists around a racetrack, it would probably be fine.

Its good to know the limitations before you use interrupts.

you can also have a script do the polling, and execute a xojo console application on level changes

that is my old python script but me thought i can write all in xojo as single desktop app with visual feedback.


MR 13.01.2018 12:42

import RPi.GPIO as GPIO
import subprocess
import time


def capture(channel):

#PIR=14 war serial was man in node-red nicht auswaehlen konnte

GPIO.add_event_detect(PIR,GPIO.RISING, callback=capture)

print(“await pir …”)
while True:

except KeyboardInterrupt: