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

[Scott Lewis <slewis@xxxxxxxxxxxxx>]

For everyone's additional info:

I've created, committed, pushed 3 projects now to the RaspberryPI repo:

1) A 'GPIO pin service type'  (IGPIOPin) API project, with just two interfaces:  IGPIOPin and IGPIOPinAsync.  In the future, this may very well have a GPIO controller service type added, but for now it's keep it simple.  This is in project bundles/org.eclipse.ecf.raspberrypi.gpio.
2) A pi4j-based implementation of this GPIO Pin service, in project bundles/org.eclipse.ecf.raspberrypi.gpio.pi4j.  When started, this bundle creates 20 IGPIOPin instances using pi4j PinImpl underneath, and registers these 20 instances with the OSGi service registry.
3) A very very simple test bundle, in project test/bundles/org.eclipse.ecf.raspberrypi.test.gpio.  All this bundle does (for now) is create a ServiceTracker and report to System.out any IGPIOPin instances registered, but I'll probably hook up a light or something to one of the GPIO pins and try out the pin.toggle() to make sure pi4j works as expected.

After I do some basic testing on an actual raspberry pi I intend to use remote services to export the IGPIOPin services and run some basic test code...probably using Eclipse as a remote service consumer.

Any comments appreciated.

Scott

On 7/10/2014 2:25 PM, Scott Lewis wrote:

For everyone's info:

I just created a new 'RaspberryPi' repo at ECF's github organization [1].  Just a couple of empty interfaces for the moment (IGPIOController IGPIOPin), but we can use this project to express and share service API designs as things evolve, and we can also add new bundle projects for (e.g.) the host impl, GPIO service consumers, apps, test code, etc.

Scott

[1] https://github.com/ECF/RaspberryPI

On 7/10/2014 10:52 AM, Wim Jongman wrote:

Sounds good to me. I will try this implementation.

However, I will be off the grid for the next three weeks.

On Thu, Jul 10, 2014 at 7:17 PM, Scott Lewis <slewis@xxxxxxxxxxxxx> wrote:

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

_______________________________________________
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

_______________________________________________
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

_______________________________________________
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