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 Paul’s 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!)
I’ll 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 it’s 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 didn’t experience a single crash.
It took some time to test what works and what not, and there’s 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 there’s 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 won’t blow up a Raspi –, in my personal view that’s a risk I am willing to take, favoring the efficiency of those methods. And whoever wants to stay on a safe path doesn’t have to use them. There’s a demo using a Xojo timer instead of a pigpio type too.
RGBLED will be included in the next repository update.
Sorry for the lousy quality:
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:
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 it’s 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 I’ll 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. ;)
if I remember correctly, I didn’t 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.
First something else!
When I do simething likes this:
call pigpio.Initialise dim serHandle as UInteger = 0 dim setValue as UInteger = &h30 serHandle = pigpio.SerialPortOpen("/dev/serial1", 9600, 0) pigpio.SerialByte(serHandle, setValue)
the compiler generates an error at the pigpio.SerialByte line:
There is more than one item with this name and it's not clear to which it refers
What do I wrong?
Just a personal preference which can be a bit confusing if you used Paul’s 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, I’ll 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:
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)
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 I’ll investigate it further.