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.
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,
// INT_EDGE_BOTH or INT_EDGE_SETUP. If it is INT_EDGE_SETUP then no
// initialisation of the pin will happen its 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, its cleared in the dispatcher before calling your
// function, so if a subsequent interrupt fires before you finish your handler,
// then it wont 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 "libwiringPi.so" 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.