Re: [ecf-dev] pi4j and OSGi (remote) services

[Scott Lewis <slewis@xxxxxxxxxxxxx>]

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:

       // create gpio controller
        final GpioController gpio = GpioFactory.getInstance();

With OSGi services, this singleton impl is pretty much an anti-pattern, and is easily replaced with a ServiceFactory that would registered something like this:

There is really only one GPIO so I guess the singleton is a requirement. I guess there is some synchronization going and that all services must share the same controller.

My gut feeling says to make a GPIOControllerService that performs operations directly on the Pin instead of passing Pin instances around. At first glance the Pin instances seem overkill and will complicate the service structure.

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