The library is almost finished. A few specialized methods missing and the scripts are not yet available.
If you have any comments or bugs to note: Please tell me!
This library looks great, and thanks for taking the time to convert the code to Xojo. I am not familiar with pigpio, and is it similar to the wiringpi module that @Paul Lefebvre created?
Thanks a lot, Eugene!
Yes, in many aspects it is similar, although I used a slightly different approach using methods to create virtual properties, like written in the readme. But you can access it almost exactly like Pauls implementation when you use the external declares.
In other aspects, it seems to supersede the possibilities of WiringPi (I have not tested much yet, just a bulk bit-on-and-off-function). I still have the hope that the advanced DMA functions could lead to a pure Pi NeoPixel solution. Or even to an extension of your book (which in its current form will keep me busy for quite some time; thanks a lot!)
Ill try to explore it a bit more in the next future and build some more convenience classes. All the interrupts and callbacks are implemented too, but as Norman made clear, they are officially unsupported and could stop working one day.
For now, the IISR interrupt for example seems to run very nicely if you take caution like discussed above. But whom do I tell!
For what its worth, and without any intention to cause another discussion: I have my pigpio demo project running for about 24 hours now. I installed a pigpio timer that updates the brightness of a 12 bit color RGB LED (12 bit is probably way too much, but who knows what brightness dynamics those devices will develop soon) every 10 ms, while an interrupt is firing if the state of a switch changes and another interrupt writes into the terminal when the IR motion detector detects a motion. I can have the LCD scroll some text at the same time and didnt experience a single crash.
It took some time to test what works and what not, and theres a big warning that these functions are unsupported and may stop working one day. As it all currently works without the need for a doevents even in a console app and the CPU load is usually between 0 and 1 percent, with small peaks about 9% each 15 seconds or so, Raspi 2 temperature stays stable and theres a lot of capacity free for doing other things. I am grateful for the warnings, but as the biggest problem could be that the project will stop working one day I mean, it wont blow up a Raspi , in my personal view thats a risk I am willing to take, favoring the efficiency of those methods. And whoever wants to stay on a safe path doesnt have to use them. Theres a demo using a Xojo timer instead of a pigpio type too.
RGBLED will be included in the next repository update.
RGBLED (with demos for Xojo timer and pigpio timer pulsing and coloring the LED) and servo class using the pigpio servo features added, including demo.
Executing Xojo code on a non-Xojo thread is unsupported. Full stop.
It’s possible to get away with it as of 2016r1 if all of the following are met:
The callback and all executed methods are in a module or shared methods in a class.
No calls are made to the Xojo framework or plugins. This includes invisible compiler-generated code which is intentionally undocumented and changes as needed.
The code only uses the following data types: Int8, Int16, Int32, Int64, UInt8, UInt16, UInt32, UInt64, Ptr, Single, Double, Boolean, and structures. Delegates, arrays, and any other type not mentioned are unsafe.
If the code uses structures, it can only access members with allowed data types.
No try/catch blocks are present in any of the executed code.
No AddressOf expressions are present in any of the executed code.
No soft declares are present in any of the executed code.
No global variables, shared variables, or static variables are used without being synchronized by an OS lock. If a variable is ever used by a non-Xojo thread, all access of it on any thread must go through the synchronization mechanism used for the variable. For static variables, the declaration must also be in the synchronized block of code.
None of the code gets executed while running under the debugger.
All the code that executes has stack overflow checking and background tasks disabled via pragmas at the top of the method. Disabling nil object checking, breaking on exceptions and, bounds checking are not required because other rules make those situations impossible.
This is all I can think of offhand, but I do not guarantee it’s a comprehensive list. It almost certainly will change in the future as the language and framework continue to evolve.
Thanks a lot for taking your time to write these lines, Joe!
Full recognition of the fact its all unsupported, and I swear I will never protest if it should stop working. (Although I am pretty sure you will come up with an official solution one time and Ill be happy to adapt my code then.)
Personally, I appreciate the fact that Xojo can do a lot more than it can do officially, even if it comes with a risk.
Hi Jaap,
if I remember correctly, I didnt have any use for i2c at that time and just checked that the channel opens. I still find this stuff a bit confusing. Would you mind sharing some code and set-up? Maybe we can make it work.
Just a personal preference which can be a bit confusing if you used Pauls library before, admitted
I have not yet received any feedback on the library. I use it for my own projects but there are still a lot of features I did not explore. So please feel free to send me any feedback, Ill gladly take the chance to debug it.
I need to control multiple PWMs with pi gui.
I’ve also read that pigpio has something like “hardware timed PWM” for GPIO 0-31.
Is this possible with yours pigpio library?
And is it possible to get example of that?
I have now external PWMs controlled by PIC and I control PIC from Pi:s serialport.
I though I can skip those externals if this hardware timed PWM works well enough.
HardwarePWM is included, but I have never tested it. pigpio has a SetHardwarePWM method (GPIO as UInteger, PWMFrequency as Uinteger, PWMDuty as Uinteger) to set frequency and duty for a GPIO port.
Each method has its description field set the notes on this one are:
[quote]Starts hardware PWM on a GPIO at the specified frequency and dutycycle. Frequencies above 30MHz are unlikely to work.
NOTE: Any waveform started by gpioWaveTxSend, or gpioWaveChain will be cancelled.
This function is only valid if the pigpio main clock is PCM. The main clock defaults to PCM but may be overridden by a call to gpioCfgClock.
PWMfreq: 0 (off) or 1-125000000 (125M)
PWMduty: 0 (off) to 1000000 (1M)(fully on)[/quote]
The main reason I did not test it is I did not find any examples on its use with the pigpio library. if you did, let me know and Ill investigate it further.