pigpio Library for Xojo

I had to work on my session for the PiAndMore conference this weekend, and this meant I had to dig a bit more into Raspi programming.
I still have the idea of trying to address a Neopixel strip with pure Raspberry code, and the pigpio library that was included in one of the latest Raspbian releases sounds quite promising to me.

That’s why I quickly set up a rough first draft of a pigpio library. No documentation yet besides the description tags in Xojo, and a slightly different approach than gpio. I only came so far to print out a few variables and make a LED light, but as it works, I’d be glad if others would join – there’ll be a lot of bugs and things in need of fine tuning: https://github.com/UBogun/Xojo-pigpio

… and the basics seem to run quite ok. Added a LCD display class mostly stolen from Paul, but with a few tweaks including quick & dirty Umlaut translation (at least for the small ones that are included in the character set).

Nice! I’ve been meaning to take a look at pigpio myself.

Thanks, Paul! Feel free to steal or join in if you like. It’s a mighty big framework.
And btw: Why don’t exception messages show up on Raspi console? I stopped putting in the error explanations when I found terminal only returns the number and an empty message.

I don’t know why exceptions don’t show in the Pi console. Seems like they ought to. Please create a Feedback case for it.

Never mind, Paul. It was me choosing the wrong property :wink:

Anyway:
Small update: pigpio.button.
This isn’t so much of a necessary class, but it installs an interrupt handler. Sure, you need to be careful what you do because it runs on a background thread, but you can access each external declare.
I added a small demo that shows how to use a switch interrupt to light a LED only when the button is pressed, fully on the background.

And if anyone could explain me why the level is low when the button is pressed and high when it’s not: Please! I expected opposite results.

I don’t know much about this stuff but can it be the button has switched NO/NC? (Normally Open/Normally Closed)

I measured the current and no, it’s a NO type.
Björn talks in his example about using the internal PullDown resistor, but then the button in my setting became a NFC device :smiley:
So I tried with PullUp and that did work – but I wonder if it changed something. I’m not that much into electronics (again, at least).

Anyway: All exception messages are included now and the compiler warnings have gone.

IRMotionDetector class (IR-driven) added.

I came to the conclusion that while it would be great to have events when a sensor level changes, this is not only difficult to handle but also eats up quite some CPU cycles. When we’re into real time data processing, the less overhead the better.
That’s why the structure introduced with the button class will become standard: A shared method you can use to insert your thread-safe code, or to fill with different code in custom subclasses (or just use the declares without any class at all).

[quote=270362:@Ulrich Bogun]
This isn’t so much of a necessary class, but it installs an interrupt handler.[/quote]
Is this an interrupt handler ? Or a signal handler ?
I would not expect either to be safe in Xojo code regardless.

It is safe if it is done correctly. It just needs a bit of care.

Not in pure Xojo code it’s not.
Joe R’s comment to me when we discussed this was

yeah, signals are absolutely unsafe for anything. ever.
pthreads you can kind of get away with sometimes, until you can’t

I must be becoming precognitive: I knew you would answer like that, Norman. :smiley:

Currently, having the app run for hours and using what pigpio calls a GPIO interrupt, I would say it’s safe for the moment and while one sticks to anything that doesn’t get a lock on objects. I know this may stop working at some time in the future but I hope it will not until we have a threadsafe native Xojo solution.
Without interrupts and such, a Raspi cybernetics project would rarely meet real world requirements. You’d have to set up a timer for every sensor or employ a tight loop which wouldn’t leave much capacity for anything else.

As far as I know, people have been happy with MacOSLib for quite some years, which employs different tricks. The alternative would have been not to use any API making use of background threads, and I believe that wouldn’t be good for Xojo’s competitiveness.

There’s a big warning note on the respective methods – only for responsible programmers. :wink: But currently I do believe the danger of blowing up your Raspi by connecting the wrong wires is much higher than what the use of these interrupt methods might bring.

[quote=270472:@Ulrich Bogun]I must be becoming precognitive: I knew you would answer like that, Norman. :smiley:

Currently, having the app run for hours and using what pigpio calls a GPIO interrupt, I would say it’s safe for the moment and while one sticks to anything that doesn’t get a lock on objects. I know this may stop working at some time in the future but I hope it will not until we have a threadsafe native Xojo solution.
Without interrupts and such, a Raspi cybernetics project would rarely meet real world requirements. You’d have to set up a timer for every sensor or employ a tight loop which wouldn’t leave much capacity for anything else.

As far as I know, people have been happy with MacOSLib for quite some years, which employs different tricks. The alternative would have been not to use any API making use of background threads, and I believe that wouldn’t be good for Xojo’s competitiveness.

There’s a big warning note on the respective methods – only for responsible programmers. :wink: But currently I do believe the danger of blowing up your Raspi by connecting the wrong wires is much higher than what the use of these interrupt methods might bring.[/quote]

I spent about an hour last Thursday looking into why a project was crashing on the Pi. It was using wiringPiISR and trying to get away with it.

wiringPiISR basically does this:

  • executes /usr/local/bin/gpio as a subprocess
  • opens a special file in /sys/class/gpio
  • spawns off a pre-emptive thread that monitors that file descriptor
  • invokes the callback from that thread whenever that descriptor is readable (the contents don’t matter)

I think it’d be possible to emulate that in Xojo code and use glib sources (or IO channels) instead of a preemptive thread. I haven’t looked further into it than that and don’t know what the tradeoff of such an approach would be.

[quote=270472:@Ulrich Bogun]
As far as I know, people have been happy with MacOSLib for quite some years, which employs different tricks. [/quote]
Calling back into Xojo from a preemptive thread isn’t safe - and interrupts definitely not
MacOSLib doesn’t do that as far as I know

Thats why you just let the thread mark the event in a variable. And let Xojo poll it with timer at far less interval than else needed. => In critical signals you wont miss a signal ever.

And it just works i been running it on servers for months under heavy load there is nothing dangerous with it if you do it right.

If you don’t do this then you can just forget Xojo for any serious Raspberry PI signal work. But there is no need to forget Xojo since it works just fine, even if you guys are trying to talk it down for no reason.

Yes it will not work and be dangerous if you don’t do it right but, if you do it right then there is nothing wrong with it.

I don’t call back into Xojo. That was really unstable: Sometimes a Xojo.core.timer.calllater might work, sometimes not.
You can, anyway, change gpio values or write into Xojo properties while on the thread.

In iOSLib and OSXLib, I do call back, but I make the system API call Xojo back on the main thread when the data comes in the background. Until today, works flawlessly too.

Just to make sure: I am aware there are limitations and most of all I heard your warnings, and I am pretty sure Joe is working a a Xojo-native, secure solution. Until then (I can imagine it’s not that trivial), I decided to be pragmatic and rather have SceneKit in Xojo probably soon for OSX too instead of learning Swift or another thing – while Paralaxia looks amazing too, admitted! :smiley:

If the thread is preemptive setting values in Xojo could cause problems although it might mostly seem to work
I wouldn’t do it

Again thats not true, that only goes if and only if your calling some class variables of classes that might Yield. If your just setting Variables that you know are just raw memory like your own Integer in your class and have the proper pragmas then you will never ever run into problems.