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.
Thats 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, Id be glad if others would join therell 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).
Thanks, Paul! Feel free to steal or join in if you like. Its a mighty big framework.
And btw: Why dont 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.
Never mind, Paul. It was me choosing the wrong property
Anyway:
Small update: pigpio.button.
This isnt 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 its not: Please! I expected opposite results.
I measured the current and no, its 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
So I tried with PullUp and that did work but I wonder if it changed something. Im not that much into electronics (again, at least).
Anyway: All exception messages are included now and the compiler warnings have gone.
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 were into real time data processing, the less overhead the better.
Thats 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 isnt 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.
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.
Currently, having the app run for hours and using what pigpio calls a GPIO interrupt, I would say its safe for the moment and while one sticks to anything that doesnt 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. Youd have to set up a timer for every sensor or employ a tight loop which wouldnt 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 wouldnt be good for Xojos competitiveness.
Theres a big warning note on the respective methods only for responsible programmers. 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.
Currently, having the app run for hours and using what pigpio calls a GPIO interrupt, I would say its safe for the moment and while one sticks to anything that doesnt 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. Youd have to set up a timer for every sensor or employ a tight loop which wouldnt 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 wouldnt be good for Xojos competitiveness.
Theres a big warning note on the respective methods only for responsible programmers. 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.
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 dont 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 its 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!
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.