Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Tutorial: Raspberry Pi GPIO with OSGi Services

Revision as of 23:16, 4 August 2014 by Slewis.composent.com (Talk | contribs) (Remote Control for GPIO Pins)


Introduction

This tutorial shows how to access the Raspberry Pi GPIO using OSGi Services. OSGi Services makes the application use of GPIO pins simpler, easier, and more dynamic.

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);
 
	public boolean toggle();
 
	public void pulse(long duration, boolean pulseState);
 
	public void blink(long delay, long duration, boolean blinkState);
 
}

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 start method of 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

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

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.

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.

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 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

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 OSGi Enterprise specification.

Here is the code necessary to export the IGPIOPin service

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);

See here for the entire source.

With the presence of ECF's implementation of 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 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

Eclipsenopins.png

After discovering an instance of IGPIOPinOutput remote service via SLP LAN-based discovery the view is automatically updated

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

Eclipsepinhigh.png

and the LED that's connected to the Raspberry Pi lights up

Leghigheclipse.png

The same as if we had accessed the IGPIOPinOutput service from the Raspberry Pi directly.

Note

  1. 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.
  2. The dynamics of unreliable remote services (i.e. that services come and go over time) is handled extremely well by OSGi services.
  3. ECF provides support for using the Java8 CompletableFuture for asynchronous remote services, eliminating the potential for user interface blocking, without complicated threading code.

Related Articles

Listeners Considered Harmful: The 'Whiteboard Pattern'

The whiteboard model

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

Back to the top