Hi Folks,
I've been thinking about this and wanted to communicate some
thoughts about Raspberry Pi GPIO.
I'm now thinking that perhaps what we should have is at least two
service types:
1) a 'IGPIOController' service, which would likely be a singleton
service that exposed the basic semantics of
provisioning/configuring GPIO pins, managing shutdown, etc...i.e.
most of the non-Pin-specific things exposed by pi4j GpioController
interface [1]. This service could be remoted, or perhaps it's
not remoted. I can imagine it either way, but to simplify things
initially perhaps it's not remoted.
2) A set of 'IGPIOPin' services, each one representing a physical
pin on a single raspberry pi GPIO device [2]. Each instance of
this service would represent a single GPIOPin. Then when the
GPIOController 'provisions/configures' the GPIO device, instances
of GPIOPin would be exported for remote access, and could then be
discovered by consumers/clients (e.g. and injected by DS).
Service properties can/could be defined for the IGPIOPin service
instances so that consumers could filter to get only the pins that
are needed for a particular application. I think the IGPIOPin
service type (or possibly types/sub-types if necessary) could be
kept quite simple and of course be made remote-friendly
(parameters/return types). Also, with java8 and ECF's
asynchronous remote service [3] each of the IGPIOPin instances
can/could be easily accessed asynchronously and/or synchronously
as needed by the application, while keeping IGPIOPin as simple as
possible.
The reason I think this might be a nice approach is that in
looking at several of the pi4j examples, the interaction with the
GPIO controller is sort of boilerplate, and most of the actual
application use is with the pin. By having IGPIOPin service
instances, it may be simpler for most applications to use GPIO
Pins without that extra boiler plate.
If others have pi4j examples, experience, or use cases it would be
nice to hear about them.
Thoughts/comments/alternatives?
Thanks,
Scott
[1]
http://pi4j.com/apidocs/index.html
[2]
http://pi4j.com/example/control.html
[3]
https://wiki.eclipse.org/ECF/Asynchronous_Remote_Services
On 7/4/2014 1:14 PM, Scott Lewis wrote:
On 7/4/2014 12:17 PM, Wim Jongman
wrote:
Perhaps you are right, but my concern about putting everything on
a GPIOControllerService could result in a complex API...for
example it might require quite a few methods for simply
controlling a single pin (e.g. in the pi4j example [1]).
One thought I've had: What if there was a local only (not
exported/remoted) GPIOControllerService, and as part of this
service multiple pin-specific services were automatically
create/provisioned, registered and then exported as remote
services, with service properties/meta-data that identified the
pin (pin #5) and associated a name with the physical pin (e.g.
'lightbulb'). Then clients could specify desired/required values
for these pin identifiers in the (remote) service OSGi
filter...e.g.
($(('pin.id'==5)("pin.name"=="lightbulb"))
via DS or others.
Then the pin-specific service interface could be something very
simple, like:
public IGPIOPin {
public Boolean toggle();
public Boolean getToggleState();
}
Or something similar.
I don't know for sure whether this would work (haven't thought it
through) but it might be a nice approach for OSGi services, and
remote services.
Scott
[1] http://pi4j.com/example/control.html#
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ecf-dev