pigpio Library for Xojo

I’ll just reiterate the framework engineers comments


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

Running with scissors is safe right up until it isnt but then you find out the hard way how unsafe it is
Best wishes

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!

Hi Ulrich,

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?

Well done!

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!

I know @Joe Ranieri has been watching this thread & I’d asked him about writing something up about the whole issue of pthreads and interrupts

Norman - I’ll look forward to reading anything you surface on the topic, debate, and safest and best way to poll inputs. Thanks for your pragmatism!

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:
https://dl.dropboxusercontent.com/u/21200221/Xojo/VID_20160619_200514632.mp4

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 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. :wink:

@Ulrich Bogun : Did you have gooed results with your I2C call’s in pigpio? I’ve tried a lot but nothing works.

Hi Jaap,
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:

[code]call pigpio.Initialise
dim serHandle as UInteger = 0
dim setValue as UInteger = &h30

serHandle = pigpio.SerialPortOpen("/dev/serial1", 9600, 0)
pigpio.SerialByte(serHandle, setValue)
[/code]

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?

The syntax is a bit different:

You should use

pigpio.SerialByte(serHandle) = Value

or

Value = pigpio.serialByte(Handle).

Oops! You’re right!

Just a personal preference which can be a bit confusing if you used Paul’s library before, admitted :wink:
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.

Hi,

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.

Thanks

Jukka

Hi Jukka,

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 I’ll investigate it further.

Hi Ulrich!

Do you had success on that?