FFI calls to Python Code on linux

I want to drive some Raspberry Pi add-ons via FFI; the problem being that many of them only have support software provided in Python.

Can I call python code from FFI? Specifically on ARM linux, obviously, this being for a Pi.

The alternative would appear to be digging through the python code (oh yuck) to find out what happens right at the very bottom of it and then building back up from there. Not the most efficient way to get flashyblinkenlightsparkenpopper.
I’m sure googling would list a gazillion pages but some pointers to *good* ones would save me a lot of time.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: RPSW: Randomize Program Status Word

You can probably just invoke the python scripts using OS Process. When I first started playing with GPIO on RPi, I did exactly that and it worked great.

But ultimately, the Python code is probably just using the same WiringPi library that I believe you already wrote a few FFI bindings for. Perhaps you could just use that?

What is the thing you are trying to do, if I may ask? We already have some fairly straightforward ability to interface to arbitrary I2C devices, for example.

HTH
Doug

On 27-04-2015, at 6:51 PM, Douglas McPherson <[hidden email]> wrote:

> You can probably just invoke the python scripts using OS Process. When I first started playing with GPIO on RPi, I did exactly that and it worked great.

Interesting idea; didn’t think of that one at all.

>
> But ultimately, the Python code is probably just using the same WiringPi library that I believe you already wrote a few FFI bindings for. Perhaps you could just use that?

I’m using wiringPi for quite a few things and it’s quite nice in that Gordon H has provided drivers for quite a few specific devices. But not all…

And I really should send you the code to keep us in step.

>
> What is the thing you are trying to do, if I may ask? We already have some fairly straightforward ability to interface to arbitrary I2C devices, for example.

You may indeed ask. I’m building a gpio server that doesn’t require using sockets to talk to a python program. I can drive the ‘ordinary’ pins, piglow, piface and some i2c so far but now I need to get the Unicorn HAT, Pibrella, AstroPi HAT and RyanTek motor board working. It’s all good fun getting these things in the mail but when you look at the software support and see only python code it’s a little disconcerting.

The *really* amusing part is that I’ve just closed the loop and discovered that the RPi.GPIO python library used in several places is in fact… written in C, almost completely. So at least some of it can just be called from FFI and I can probably work out what it is doing that is equivalent to the code in wiringPi, and then all (hah!) I have to do is excavate enough python to work out what it wanted to do. I dunno about anyone else out there but I find python rather hard to follow. Then again, my first exposure was to a large routine with a 1200 line case statement.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- On permanent leave of absence from his senses.

Please do. I’ll be happy to incorporate it with what I did, and release for others to use/review. I know Herbert Konig has expressed interest too.

>
>>
>> What is the thing you are trying to do, if I may ask? We already have some fairly straightforward ability to interface to arbitrary I2C devices, for example.
>
> You may indeed ask. I’m building a gpio server that doesn’t require using sockets to talk to a python program. I can drive the ‘ordinary’ pins, piglow, piface and some i2c so far but now I need to get the Unicorn HAT, Pibrella, AstroPi HAT and RyanTek motor board working. It’s all good fun getting these things in the mail but when you look at the software support and see only python code it’s a little disconcerting.

Got it. I suspect that the motor board uses the RPi's PWMs which I haven’t played with. But for anything GPIO or I2C, it is already super easy to use IMHO from Squeak.

>
> The *really* amusing part is that I’ve just closed the loop and discovered that the RPi.GPIO python library used in several places is in fact… written in C, almost completely. So at least some of it can just be called from FFI and I can probably work out what it is doing that is equivalent to the code in wiringPi, and then all (hah!) I have to do is excavate enough python to work out what it wanted to do. I dunno about anyone else out there but I find python rather hard to follow. Then again, my first exposure was to a large routine with a 1200 line case statement.
>
Indeed. I discovered the same thing about RPi.GPIO, dug out the C library it uses, and made FFI bindings to it. That is what I based my GPIO experiments on. WiringPi is the same thing, just a different implementation (which may be more supported in the Pi world), and I agree it makes sense to use WiringPi as the base C library rather than the one at the base of RPi.GPIO.

>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Useful random insult:- On permanent leave of absence from his senses.
>
>
>