Skip to main content
Jump to: navigation, search

Difference between revisions of "Tutorial: Raspberry Pi GPIO with OSGi Services"

(GPIO Input)
 
(12 intermediate revisions by the same user not shown)
Line 74: Line 74:
 
==Introduction==
 
==Introduction==
  
This tutorial shows how to access the [http://www.raspberrypi.org/documentation/usage/gpio/ Raspberry Pi GPIO] using OSGi Services. OSGi Services makes the application use of GPIO pins simpler, easier, and more dynamic.
+
This tutorial shows how to use OSGi Services to access the [http://www.raspberrypi.org/documentation/usage/gpio/ Raspberry Pi GPIO].   The use of OSGi Services to use GPIO provides several important advantages:
 +
#The OSGi Service Interface provides a simple and clear yet flexible software abstraction
 +
##Clear Contract Between Service Producer and Service Consumer
 +
##Loose Coupling and High Cohesion
 +
##Flexible yet Simple Abstractions
 +
#OSGi Services provides technical advantages
 +
##Service Dynamics - Services come and go, applications can be notified and adjust
 +
##Service Versioning - Services evolve over time
 +
##Variety of Injection Frameworks - e.g. Declarative Services, Blueprint/Spring
 +
##Network Services - [https://wiki.eclipse.org/ECF#OSGi_Remote_Services ECF Remote Services]
 +
##Service-Level Security
  
 
==GPIO Pin Output==
 
==GPIO Pin Output==
Line 93: Line 103:
 
public void setState(boolean value);
 
public void setState(boolean value);
  
public boolean toggle();
+
...
 
+
public void pulse(long duration, boolean pulseState);
+
 
+
public void blink(long delay, long duration, boolean blinkState);
+
  
 
}
 
}
Line 106: Line 112:
 
Since the implementation of this interface already exists, all we need to do use the IGPIOPinOutput service is to write our application code so that OSGi service instances of this type are accessed for the pins we are interested in manipulating.   
 
Since the implementation of this interface already exists, all we need to do use the IGPIOPinOutput service is to write our application code so that OSGi service instances of this type are accessed for the pins we are interested in manipulating.   
  
To find and use an instance of IGPIOPinOutput we can use one of several OSGi mechanisms:  1) Declarative Services; 2) ServiceTracker; 3) BundleContext.  For this tutorial, we will use a very simple ServiceTracker.  The full code for this example can be located in the start method of [https://github.com/ECF/RaspberryPI/blob/master/test/bundles/org.eclipse.ecf.raspberrypi.test.gpio/src/org/eclipse/ecf/raspberrypi/test/gpio/Activator.java this test code].  The important fragments from this example are the implementation of the '''addingService''' method, which is executed when instances of IGPIOPinOutput are registered in the OSGi service registry
+
To find and use an instance of IGPIOPinOutput we can use one of several OSGi mechanisms:  1) Declarative Services; 2) ServiceTracker; 3) BundleContext.  For this tutorial, we will use a very simple ServiceTracker.  The full code for this example can be located in the registerTracker method of [https://github.com/ECF/RaspberryPI/blob/master/bundles/org.eclipse.ecf.raspberrypi.gpio.pi4j/src/org/eclipse/ecf/raspberrypi/gpio/pi4j/AbstractPinManager.java the AbstractPinManager class].  The important fragments from this example are the implementation of the '''addingService''' method, which is executed when instances of IGPIOPinOutput are registered in the OSGi service registry
  
 
<source lang="java">
 
<source lang="java">
 
public IGPIOPinOutput addingService(ServiceReference<IGPIOPinOutput> reference) {
 
public IGPIOPinOutput addingService(ServiceReference<IGPIOPinOutput> reference) {
    System.out.println("Adding GPIO Pin Output service.   id="+reference.getProperty(IGPIOPinOutput.PIN_ID_PROP));
+
IGPIOPinOutput pin = fBundleContext.getService(reference);
    IGPIOPinOutput pin = context.getService(reference);
+
        ...
    System.out.println("  current pin state is "+(pin.getState()?"HIGH":"LOW"));
+
System.out.println("Adding GPIO Pin Output service. id="+ reference.getProperty(IGPIOPinOutput.PIN_ID_PROP));
    System.out.println("  setting state to HIGH");
+
        System.out.println("  current pin state is "+ (pin.getState() ? "HIGH" : "LOW"));
    pin.setState(true);
+
System.out.println("  setting state to HIGH");
    return pin;
+
pin.setState(true);
 +
return pin;
 
}
 
}
 
</source>
 
</source>
  
Note that when the IGPIOPinService is added, the service.setState(true) method is called, which will set the state of the pin to HIGH, turning on the LED connected to that pin.   
+
When the IGPIOPinService is added, the service.setState(true) method is called, which will set the state of the pin to HIGH, turning on the LED connected to that pin.   
  
 
As well, we will implement '''removedService''' which is executed when instances of IGPIOPinOutput are unregistered.
 
As well, we will implement '''removedService''' which is executed when instances of IGPIOPinOutput are unregistered.
Line 231: Line 238:
 
Also available is a complete working implementation of this service API based upon/using [http://pi4j.com Pi4j].  This implementation is in the bundles/org.eclipse.ecf.raspberrypi.gpio.pi4j project.
 
Also available is a complete working implementation of this service API based upon/using [http://pi4j.com Pi4j].  This implementation is in the bundles/org.eclipse.ecf.raspberrypi.gpio.pi4j project.
  
The GPIO input and output test code is available in a test bundle test/bundles/org.eclipse.ecf.raspberrypi.test.gpio.  This bundle has a single [https://github.com/ECF/RaspberryPI/blob/master/test/bundles/org.eclipse.ecf.raspberrypi.test.gpio/src/org/eclipse/ecf/raspberrypi/test/gpio/Activator.java Activator class given here].  Also available is a PDE feature and product configuration, along with a built version ready to run on a working Raspberry Pi with Java8 installed in test/features/org.eclipse.ecf.raspberrypi.test.gpio/build/raspberrypitestgpio.zip.
+
==Remote Control for GPIO Pins==
  
==Remote Access==
+
See the [[Tutorial:_OSGi_Remote_Services_for_Raspberry_Pi_GPIO | OSGi Remote Services for Raspberry Pi GPIO tutorial]].
 
+
The use of OSGi Services makes it very easy to export the Raspberry Pi GPIO control to other user interfaces.
+
For example, to export the control of GPIO pin 0 for remote access, all that's necessary is the specification of some service properties upon service registration.  These service properties are standardized by the OSGi Remote Services chapter 100 in the [http://www.osgi.org/Specifications/HomePage OSGi Enterprise specification].
+
 
+
Here is the code necessary to export the IGPIOPin service
+
 
+
<source lang="java>
+
Map<String, Object> pinProps = new HashMap<String, Object>();
+
pinProps.put("service.exported.interfaces", "*");
+
pinProps.put("service.exported.configs", "ecf.generic.server");
+
pinProps.put("ecf.generic.server.port", "3288");
+
pinProps.put("ecf.generic.server.host",InetAddress.getLocalHost().getHostAddress());
+
pinProps.put("ecf.exported.async.interfaces", "*");
+
...
+
 
+
// register GPIOPin 0 with the above export properties
+
reg = Pi4jGPIOPinOutput.registerGPIOPinOutput(0, pinProps, context);
+
</source>
+
 
+
See [https://github.com/ECF/RaspberryPI/blob/master/test/bundles/org.eclipse.ecf.raspberrypi.test.gpio/src/org/eclipse/ecf/raspberrypi/test/gpio/Activator.java here for the entire source].
+
 
+
With the presence of ECF's implementation of [[ECF#OSGi_Remote_Services | OSGi Remote Services]] in the target framework, the above registration will export an OSGi Remote Service, and make it available for discovery.  In the case of the [ https://github.com/ECF/RaspberryPI/tree/master/test/features/org.eclipse.ecf.raspberrypi.test.gpio.feature example], the SLP protocol is used for LAN-based network discovery. 
+
 
+
Once exported as a remote service, other clients may discover, import, and then use the IGPIOPinOutput service.  To demonstrate this, I created a simple Eclipse View present the discovered IGPIOPinOutput remote service instances.  The code for this Eclipse plugin is [https://github.com/ECF/RaspberryPI/tree/master/test/bundles/org.eclipse.ecf.raspberrypi.test.gpio.ide in the test/bundles/org.eclipse.ecf.raspberrypi.test.gpio.ide] project.  When run in Eclipse, the empty view (no discovered IGPIOPinOutput services) looks like this
+
 
+
[[File:eclipsenopins.png]]
+
 
+
After discovering an instance of IGPIOPinOutput remote service via SLP LAN-based discovery the view is automatically updated
+
 
+
[[File:eclipsepinlow.png]]
+
 
+
Then a simple click on the 'State (click to toggle)' cell of this Eclipse view results in the pin state changing to HIGH  via a call to IGPIOPinUpdate.setState,  the Eclipse UI is updated to show the HIGH state
+
 
+
[[File:eclipsepinhigh.png]]
+
 
+
and the LED that's connected to the Raspberry Pi lights up
+
 
+
[[File:leghigheclipse.png]]
+
 
+
The same as if we had accessed the IGPIOPinOutput service from the Raspberry Pi directly. 
+
 
+
Note
+
 
+
#OSGi Remote Services allows service consumers to ignore the underlying communications transport used for the remoting of the IGPIOPinOutput service.  The code implementing the Eclipse view does not access *any* transport-specific mechanisms, allowing both the Raspberry Pi (service host) and the Eclipse view to use whatever provider transport they prefer.
+
#The dynamics of unreliable remote services (i.e. that services come and go over time) is handled extremely well by OSGi services.
+
#ECF provides support for using the [[ECF/Asynchronous_Remote_Services | Java8 CompletableFuture for asynchronous remote services]], eliminating the potential for user interface blocking, without complicated threading code.
+
  
 
==Related Articles==
 
==Related Articles==
Line 286: Line 247:
  
 
[http://www.knopflerfish.org/osgi_service_tutorial.html#white The whiteboard model]
 
[http://www.knopflerfish.org/osgi_service_tutorial.html#white The whiteboard model]
 +
 +
[[Tutorial:_OSGi_Remote_Services_for_Raspberry_Pi_GPIO | OSGi Remote Services for Raspberry Pi GPIO]]
  
 
[[Getting Started with ECF's OSGi Remote Services Implementation]]
 
[[Getting Started with ECF's OSGi Remote Services Implementation]]

Latest revision as of 03:09, 28 April 2016


Introduction

This tutorial shows how to use OSGi Services to access the Raspberry Pi GPIO. The use of OSGi Services to use GPIO provides several important advantages:

  1. The OSGi Service Interface provides a simple and clear yet flexible software abstraction
    1. Clear Contract Between Service Producer and Service Consumer
    2. Loose Coupling and High Cohesion
    3. Flexible yet Simple Abstractions
  2. OSGi Services provides technical advantages
    1. Service Dynamics - Services come and go, applications can be notified and adjust
    2. Service Versioning - Services evolve over time
    3. Variety of Injection Frameworks - e.g. Declarative Services, Blueprint/Spring
    4. Network Services - ECF Remote Services
    5. Service-Level Security

GPIO Pin Output

Each GPIO digital pins have two modes: output and input. For output, each pin can be in either the 'HIGH' state, or the 'LOW' state, and the control of the pin state is what we would like to manipulate to give our application behavior. After connecting a single LED, changing the output on a given pin to HIGH will turn the LED on, while setting to low will turn it off. See this page for a description of how to setup such an LED.

We would like to use OSGi services to simplify software access to devices connected to the GPIO digital pins. Here's a picture of a Raspberry Pi setup with an LED connected to GPIO digital output pin 0, as per the instructions here. This is the setup that I use to test the services described below

Ledsetup.png

For OSGi services, we start by creating a service interface declaring the methods for accessing a single GPIO pin. Here is the IGPIOPinOutput service interface:

public interface IGPIOPinOutput extends IGPIOPin {
 
	public boolean getState();
 
	public void setState(boolean value);
 
...
 
}

For this tutorial, we will be interested only in the getState and setState methods from this service interfaces. Note that we can create as many instances of this service interface as desired, but are limited by the GPIO device itself, which has two rows of 10 pins for a total of 20 physical pins.

Since the implementation of this interface already exists, all we need to do use the IGPIOPinOutput service is to write our application code so that OSGi service instances of this type are accessed for the pins we are interested in manipulating.

To find and use an instance of IGPIOPinOutput we can use one of several OSGi mechanisms: 1) Declarative Services; 2) ServiceTracker; 3) BundleContext. For this tutorial, we will use a very simple ServiceTracker. The full code for this example can be located in the registerTracker method of the AbstractPinManager class. The important fragments from this example are the implementation of the addingService method, which is executed when instances of IGPIOPinOutput are registered in the OSGi service registry

public IGPIOPinOutput addingService(ServiceReference<IGPIOPinOutput> reference) {
	IGPIOPinOutput pin = fBundleContext.getService(reference);
        ...
	System.out.println("Adding GPIO Pin Output service. id="+ reference.getProperty(IGPIOPinOutput.PIN_ID_PROP));
        System.out.println("  current pin state is "+ (pin.getState() ? "HIGH" : "LOW"));
	System.out.println("  setting state to HIGH");
	pin.setState(true);
	return pin;
}

When the IGPIOPinService is added, the service.setState(true) method is called, which will set the state of the pin to HIGH, turning on the LED connected to that pin.

As well, we will implement removedService which is executed when instances of IGPIOPinOutput are unregistered.

public void removedService(ServiceReference<IGPIOPinOutput> reference,
                           IGPIOPinOutput service) {
    System.out.println("Removing GPIO Pin service. id="+reference.getProperty(IGPIOPinOutput.PIN_ID_PROP));
    System.out.println("  setting state to LOW");
    service.setState(false);
}

When the service is removed, the service.setState(false) is called, which will set the state of pin 0 to LOW, turning off the LED connected to that pin.

When this test bundle is run on a Raspberry Pi (using Java8+Equinox 4.4), this appears on the OSGi console:

osgi> start 3
Adding GPIO Pin Output service.   id=0
  current pin state is LOW
  setting state to HIGH

the LED lights up

Ledhigh.png

If we then stop this test bundle, this appears on the OSGi console

osgi> stop 3
Removing GPIO Pin service. id=0
  setting state to LOW

and the LED goes out.

Here is a short video showing the running of this test code by using the Apache Webconsole. Thanks to ECF committer Wim Jongman for creating the video.

GPIO Input

In addition to controlling devices that are connected to one or more GPIO pins, it's also possible to receive asynchronous notifications of inputs to digital pins. To do this with OSGi services we will use a very useful OSGi service pattern called the whiteboard pattern. The whiteboard pattern is described in links given under Related Articles below.

For the whiteboard pattern we need another service interface, called IGPIOPinInputListener

public interface IGPIOPinInputListener {
 
	void handleInputEvent(GPIOPinInputEvent event);
 
}

and the associated GPIOPinInputEvent

public class GPIOPinInputEvent extends AbstractGPIOPinEvent implements
		Serializable {
 
	private static final long serialVersionUID = -6103636181685626657L;
 
	private final boolean state;
 
	public GPIOPinInputEvent(int pinId, boolean state) {
		super(pinId);
		this.state = state;
	}
 
	public boolean getState() {
		return state;
	}
 
	@Override
	public String toString() {
		return "GPIOPinInputEvent [getPinId()=" + getPinId() + ", state="
				+ state + "]";
	}
 
}

With the whiteboard pattern, instead of clients looking up/retrieving services (as with IGPIOPinOutput and the ServiceTracker given above), what's necessary is that the IGPIOPinInputListener be implemented and then an instance registered in the OSGi Service registry. For example, here's a very simple class that implements IGPIOPinInputListener

class TestGPIOPinInputListener implements IGPIOPinInputListener {
    @Override
    public void handleInputEvent(GPIOPinInputEvent event) {
        System.out.println("TestGPIOPinInputListener.handleInputEvent(event="+event+")");
    }
}

and then we create an instance of this class, create some service properties and register this instance via the OSGi BundleContext (context):

// Create properties
Hashtable props = IGPIOPin.Util.createInputListenerProps(IGPIOPin.DEFAULT_INPUT_PIN);
// Create and register listener using context and props created above
context.registerService(IGPIOPinInputListener.class, new TestGPIOPinInputListener(), props);

This listener is then notified and produces output when the DEFAULT_INPUT_PIN changes it's state:

TestGPIOPinInputListener.handleInputEvent(event=GPIOPinInputEvent [getPinId()=2, state=false])

All of the code above is provided in the ECF RaspberryPi github repository. The service interfaces above (IGPIOPinOutput and IGPIOPinInputListener and event classes) are available in the bundles/org.eclipse.ecf.raspberrypi.gpio project.

Also available is a complete working implementation of this service API based upon/using Pi4j. This implementation is in the bundles/org.eclipse.ecf.raspberrypi.gpio.pi4j project.

Remote Control for GPIO Pins

See the OSGi Remote Services for Raspberry Pi GPIO tutorial.

Related Articles

Listeners Considered Harmful: The 'Whiteboard Pattern'

The whiteboard model

OSGi Remote Services for Raspberry Pi GPIO

Getting Started with ECF's OSGi Remote Services Implementation

Download ECF Remote Services/RSA Implementation

How to Add Remote Services/RSA to Your Target Platform

Copyright © Eclipse Foundation, Inc. All Rights Reserved.