Interruptions support

[scls19fr]

Hello,

it will be nice to provide interruptions support for Pingo.
see https://groups.google.com/forum/#!topic/pingo-io/7ekBhz7wYQk

Kind regards

[Vido]

Hey guys we have a hard issue here.
In most of cases pooling threads will do. But It would be nice to have some kind of interruptions on DigitalPins (at least).

• Python has signal syscalls support:
  https://docs.python.org/2/library/signal.html
  This could be the case of API that implements signals (like RaspberryPi)
• There is this lib Watchdog that monitors file system events.
  https://github.com/gorakhargosh/watchdog
  All sysfs implementation could use that
• And there is Firmata that does pooling anyway...

I guess its possible and will turn Pingo into a serious powerful API.
However, it will take time, which is a scarce resource.

What do you think guys?

[ramalho]

I believe interruptions support is a great feature to have, but I'd like to
shift the discussion from the how to the what. WHAT we will implement and
hot HOW. To think about WHAT we need to design the API the user will see.
Event-oriented APIs are not so simple. To start thinking about the API
without getting tangled in the HOW, let's implement timers and and events
to other components we already have. For example, the Led class has a blink
method which launches a thread and blinks for a while. It should
(optionally) notify that the blinking is done by invoking a callback.

On Sun, Nov 30, 2014 at 11:33 PM, Lucas Vido notifications@github.com
wrote:

Hey guys we have a hard issue here.
In most of cases pooling threads will do. But It would be nice to have
some kind of interruptions on DigitalPins (at least).

• Python has signal syscalls support:
  https://docs.python.org/2/library/signal.html This could be the case
  of API that implements signals (like RaspberryPi)
• There is this lib Watchdog that monitors file system events.
  https://github.com/gorakhargosh/watchdog All sysfs implementation
  could use that
• And there is Firmata that does pooling anyway...

I guess its possible and will turn Pingo into a serious powerful API.
However, it will take time, which is a scarce resource.

What do you think guys?

—
Reply to this email directly or view it on GitHub
https://github.com/garoa/pingo/issues/60#issuecomment-65011050.

Luciano Ramalho
Twitter: @ramalhoorg

Professor em: http://python.pro.br
Twitter: @pythonprobr

[Vido]

Well,

I was thinking on the very basic:

def my_callback():
    print 'Foo'

pin = board.pins[X]
pin.mode = IN
pin.set_interruption(pingo.RISING, callback=my_callback)

[scls19fr]

Hello,

I understand Luciano about HOW and WHAT
but you are also right Vido, I was also looking for this kind of API.

I wonder if you shouldn't pass to callback additional information
such as which pin raises this interrupt, what kind of "event" occured...

see http://sourceforge.net/p/raspberry-gpio-python/wiki/Inputs/
for Raspberry Pi

Kind regards

[ramalho]

On Mon, Dec 1, 2014 at 11:07 AM, scls19fr notifications@github.com wrote:

I wonder if you shouldn't pass to callback additional information
such as which pin raises this interrupt, what kind of "event" occured...

Excellent point! A best practice in callback APIs is to have a
well-defined event interface so that callbacks always know what to
expect as argument: an object that implements the event interface,
with relevant data about what triggered the callback.

Cheers,

Luciano

Kind regards

—
Reply to this email directly or view it on GitHub.

Luciano Ramalho
Twitter: @ramalhoorg

Professor em: http://python.pro.br
Twitter: @pythonprobr

[scls19fr]

Exposing Board via a HTTP Server with websocket could be the WHAT ;-)

[scls19fr]

MQTT and IoT #99 are also example of "WHAT"...

A button is connected to a board. When you press this button, an interrupt should occured and a message should be send through MQTT.

A second board subscribe to a channel. A led is connected to this second board. When a message is received (button pressed for example), led change it's state.

I think this example should show why an event oriented approach (and so interrupts) is necessary.