[Gambas-devel] Raspberry Pi & Gambas.

Tobias Boege taboege at ...176...
Wed Oct 21 18:40:05 CEST 2015


On Wed, 21 Oct 2015, zxMarce wrote:
> Hi,
> 
> Using the  wiringPi 2 library <http://wiringpi.com/>  , a C program can
> fiddle with the I/O pins in (I think) all Raspberry Pi (RasPi for short)
> models. A C program could also set "triggers" so that the program is
> "interrupted" whenever pin(s) change state (low-to-high or high-to-low).
> 
> The first part, twiddling with output pins and reading their state is
> achievable in Gambas with help of EXTERN calls. Unfortunately, the interrupt
> part does not play along with Gambas. Some time ago (coupla months) I read
> why, but the reason why was over my head.
> 
> Since many Gambas components are actually C adapting and rerouting things
> back and forth between low-level drivers and stuff to/from BASIC code (yes,
> I know I'm oversimplifying), I wonder if a RasPi-specific component could be
> developed that take advantage of the interrupts in form of Gambas Events.
> Point is, this component would work and be meaningful exclusively on the
> RasPi and not useable on -say- x86 for example. Is there any way a component
> can be disabled based on machine architecture? This would be the
> hardware-equivalent to disabling gb.qt5 on Ubuntu, for example.
> 

You should not decide if the component should be enabled based on the
architecture but based on the existence of the wiringPi library. This
library can, of course, only be present on systems of proper architecture.

I have once attempted to write a gb.wiringpi component but then I noticed
that I don't have the hardware to test it. All that I find of it on my
current PC is the note that apparently wiringPi (back then) wanted to fork
the Gambas process to watch for events (the wiringPiISR() function).

This is critical because some Gambas components might not want to be
forked[*]. In any case, my advice would be to let wiringPi fork the
interpreter and use a pipe from the forked process (which is where wiringPi
detects interrupts) to the main process. The main process can watch this
pipe by using the GB.Watch() API.

If an interrupt is detected in the forked process, it would write something
into the pipe which identifies the interrupt source and everything else you
need. The main process reads this data and raises the respective Gambas
event.

> I have a PDF paper explaining how to create a Gambas component in C. I'm
> afraid it does not cover events, though. If a simple explanation is given on
> how to raise Events from C code, I may risk my ar$e and try to do it if the
> platform restriction is doable.
> 

You can look at gb.inotify. I think it is a neat and small example of a
component where events are implemented. The code is at main/lib/inotify.
The GB.Watch() API is also used in gb.inotify.

Regards,
Tobi

[*] OTOH, we have Task in gb which forks the interpreter, so it should be OK
    if you do that, too. Note, however, that in my current project I had a
    case where I started ~40 background tasks on startup and the (GUI!)
    project would crash with some X server error. I solved that by adding
    Wait instructions to start the Tasks separately. I say this only so that
    you're not confused when your test project crashes randomly because
    wiringPi forks :-)

-- 
"There's an old saying: Don't change anything... ever!" -- Mr. Monk




More information about the Devel mailing list