Hi All,
I'm curious about interfacing Squeak with the i/o pins on the Raspberry Pi et al. Should we write a plugin? Does the FFI work just fine? What's a good guide? Who's done this already? What was good/bad about the approach you (if it is you) took?
_,,,^..^,,,_ best, Eliot
On 04-08-2015, at 11:14 AM, Eliot Miranda eliot.miranda@gmail.com wrote:
I'm curious about interfacing Squeak with the i/o pins on the Raspberry Pi et al. Should we write a plugin? Does the FFI work just fine? What's a good guide? Who's done this already? What was good/bad about the approach you (if it is you) took?
I’ve been using Gordon Henderson’s wiringPi library via FFI so far. No especial technical reason for that choice; Gordon is a ‘friend of Pi’, it was suggested to me as worth a look, it made getting the first few Pi add-ons working reasonably simple. It does have a few issues, not least the way that he chose to make errors totally-fatal after getting fed up with people complaining about problems and admitting they weren’t bothering to check error flags.
The is also pigpio, which may be a better target since it appears to be a deamon that can avoid needing to sudo to get pin access. Haven’t done any investigation yet.
Doug was using bcm2835.so with some considerable success. I’ve been building wiringPi handler classes modelled on his work.
Generally performance does not seem to be an issue; I can make assorted add-ons dance arbitrarily fast in test code and within Scratch the gpio bandwidth is not the limiting issue. I’ve also extended the paradigm to talk serial (for PiLite, file (for the framebuffer interface to the AstroPi LED array) and just plain text for invoking time, ip address etc.
The only related area notably affecting me is that a lot of Pi stuff has python libraries. Right now we can’t call them so I have to dig into the code (oh, yurgh) and replicate relevant functionality. Tedious. I have noticed that a lot of python libraries are merely shims around C++ code but we can’t call that either without a C shim - and anyway the python code often does extra bits around the edges.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Never do at compile-time what you can put off till run-time
On Wed, Aug 5, 2015 at 4:54 AM, tim Rowledge tim@rowledge.org wrote:
The only related area notably affecting me is that a lot of Pi stuff has python libraries. Right now we can’t call them so I have to dig into the code (oh, yurgh) and replicate relevant functionality. Tedious. I have noticed that a lot of python libraries are merely shims around C++ code but we can’t call that either without a C shim - and anyway the python code often does extra bits around the edges.
Kilon Alios (aka Dimitris Chloupis) has developed a Pharo/Python bridge that is perhaps malleable for use with Squeak.
http://forum.world.st/invoking-python-from-pharo-td4780229.html
https://www.youtube.com/results?search_query=Ephestos
cheers -ben
I am using sockets for my implementation since its simpler to code. But that impose some speed limit, its ok for invoking code that responds down to a milisecond but if your goal is microsecond then a C lib would make more sense. There was a guy doing it this way with nativeboost (which AFAIK does not work on Squeak but you could use the Squeak FFI) but not for Python but for the R programming language.
Bare in mind that a lot of python libraries contain python code , so they not just C++ wrappers .
It makes more sense to invoke python libs from python .
Thats what I did with my implementation, I let python run its own libraries and my project all it does is say to python what to do. This way I can use any python library from Pharo. There is some extra care that should be taken with libraries that mess with threads , I had my issues for example using pyQT but thats the usual issues you have with threading and concurrent programming.
Most Python libraries use the Python C API which can wrap C and C++ for python, gives you the ability to manage refernce counting which is what cpython uses for its GC and wrap C/C++ types to python objects.
I have been recommended to use openQwaq implementation for running python scripts but the documentation and the code was not so clear and I decided to implement my own. Also my goal was to make writting python code optional for users. I prefer using python libraries as if they are pharo libraries which I managed to do with some basic regex parsing and overiding MNU ;)
On Wed, Aug 5, 2015 at 4:12 AM Ben Coman btc@openinworld.com wrote:
On Wed, Aug 5, 2015 at 4:54 AM, tim Rowledge tim@rowledge.org wrote:
The only related area notably affecting me is that a lot of Pi stuff has
python libraries. Right now we can’t call them so I have to dig into the code (oh, yurgh) and replicate relevant functionality. Tedious. I have noticed that a lot of python libraries are merely shims around C++ code but we can’t call that either without a C shim - and anyway the python code often does extra bits around the edges.
Kilon Alios (aka Dimitris Chloupis) has developed a Pharo/Python bridge that is perhaps malleable for use with Squeak.
http://forum.world.st/invoking-python-from-pharo-td4780229.html
https://www.youtube.com/results?search_query=Ephestos
cheers -ben
On 04.08.2015, at 20:14, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi All,
I'm curious about interfacing Squeak with the i/o pins on the Raspberry Pi et al. Should we write a plugin? Does the FFI work just fine? What's a good guide? Who's done this already? What was good/bad about the approach you (if it is you) took?
I’d think the sysfs should be usable without any additional VM support? I guess that what Dimitris means with “sockets”:
http://elinux.org/RPi_GPIO_Code_Samples#sysfs http://elinux.org/RPi_GPIO_Code_Samples#sysfs
Otherwise I’d go for a lightweight plugin solution using direct IO:
http://elinux.org/RPi_GPIO_Code_Samples#Direct_register_access http://elinux.org/RPi_GPIO_Code_Samples#Direct_register_access
Advantage (besides being most efficient) is that there are no dependencies at all, and it does look pretty trivial.
If we desire an interface similar to the WiringPi lib (which is GPL) then that should be easily accomplished in the image.
- Bert -
On 26-08-2015, at 10:37 AM, Bert Freudenberg bert@freudenbergs.de wrote:
Otherwise I’d go for a lightweight plugin solution using direct IO:
http://elinux.org/RPi_GPIO_Code_Samples#Direct_register_access
Advantage (besides being most efficient) is that there are no dependencies at all, and it does look pretty trivial.
I’m not 100% sure but I think that approach requires sudo etc.
An advantage of wiringPi is that it wraps some nasty stuff quite nicely. A disadvantage is that Gordon apparently believes in a rather medieval approach to errors - Ka-Boom! A veritable Earth-shattering Ka-Boom!
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful Latin Phrases:- Gramen artificiosum odi = I hate Astroturf.
On 26.08.2015, at 19:54, tim Rowledge tim@rowledge.org wrote:
On 26-08-2015, at 10:37 AM, Bert Freudenberg bert@freudenbergs.de wrote:
Otherwise I’d go for a lightweight plugin solution using direct IO:
http://elinux.org/RPi_GPIO_Code_Samples#Direct_register_access
Advantage (besides being most efficient) is that there are no dependencies at all, and it does look pretty trivial.
I’m not 100% sure but I think that approach requires sudo etc.
How does WiringPi get around that?
An advantage of wiringPi is that it wraps some nasty stuff quite nicely. A disadvantage is that Gordon apparently believes in a rather medieval approach to errors - Ka-Boom! A veritable Earth-shattering Ka-Boom!
And its license.
- Bert -
Am 26.08.2015 um 20:13 schrieb Bert Freudenberg:
On 26.08.2015, at 19:54, tim Rowledge tim@rowledge.org wrote:
On 26-08-2015, at 10:37 AM, Bert Freudenberg bert@freudenbergs.de wrote:
Otherwise I’d go for a lightweight plugin solution using direct IO:
http://elinux.org/RPi_GPIO_Code_Samples#Direct_register_access
Advantage (besides being most efficient) is that there are no dependencies at all, and it does look pretty trivial.
I’m not 100% sure but I think that approach requires sudo etc.
How does WiringPi get around that?
If it accesses the registers directly via mem-mapped access to I/O space, it has to run as root, there's no way around it. A socket-based solution is probably cleanest as it keeps the critical code that runs with elevated privs reasonably small. Any other IPC mechanism might do just as well (Don't know whether there is a significant difference, though).
Cheers, Hans-Martin
vm-dev@lists.squeakfoundation.org
-
Ben Coman -
Bert Freudenberg -
Dimitris Chloupis -
Eliot Miranda -
Hans-Martin Mosner -
tim Rowledge