GPIO performance on raspberry pi is an often discussed topic.

New scratch uses a build in gpioServer, other options are scratchClient.
Especially stepper motors need quite high pulse rate, so I have set up a test harness for a small stepper with 2ms step width. The scenario are

• a DMA pulse driven approach
• a python program
• scratch, using scratchClient
• scratch, using GPIOserver

The main focus is on performance of scratch to GPIO.
For scratchClient, some bottleneck analysis is performed.

DMA created pulses

As expected, DMA pulse widths are precise. The glitch on third line is due to a limitation in my modified RPIO.PWM-library which does not yet allow impulse roll over. The interval time printed on the image is for four steps and precise 8ms.

This DMA approach is listed for reference only, as it is not easily controllable from scratch. It is either on or off, but number of pulses can’t be determined.

python created pulses

python code is also pretty good. Pulse with is exceeding the expected 8ms by 0.5ms, which could quite easily compensated by some more advanced time handling.

scratch and scratchClient

The scratchClient approach is expected to be slower. Time scale is changed for this chart and the result is 326ms for 4 steps, which is 40 times slower than python or DMA.

scratch with gpioserver

GPIOserver, build in into scratch, is finally at 101ms, three times faster than scratch with scratchClient, only 12 times slower than python. The assymmetric pulses are due to to ‘forever loop’, I suppose.

All of the measurements have been taken on a RPI2, Model B, raspbian ‘jessie’, scratch is 2015-11-11.
Python is 2.7, the DMA code is a modified RPIO.PWM, adjusted for PI2.

scratchClient bottleneck analysis

The result for scratchClient was unexpectedly bad. So I have set up some tests to find out where the bottleneck is located.

First approach was to change the variable based communication to the stepper module by an event based ‘broadcast’. This approach resulted in 101ms cycle time, a good match to the result from GPIOserver.

Second approach was to write a small python code which simulates scratch: a socket server for port 42001, sending out sensor updates like “sensor-update “br0.0” 0 “.

The delay time was 2ms, and the result from this is a cycle time of 9ms. Pretty close to the pure python approach.
From these results it is clear that the bottleneck is on scratch side. Looks as if scratch variable access and sending them out is three times slower than sending out broadcasts from scratch.
Socket communication imposes some overhead, but is not limiting performance.

See also scratch performance 2, gpioserver reaction time

blink(1) is a neat small USB device with two RGB LED inside. See also their home page.

The scratch code is straightforward. With variable ‘led_1’ the LED#1 is set, and ‘led_2’ sets LED#2. The device supports also a setAll-Command, a variable ‘led_all’ or ‘led_0’ is used for this purpose.

Download and install scratchClient-Software. In addition to the usual installation of scratchClient it is needed to install ‘pyusb’. This installation is described in the documentation.

scratchClient is designed to work with raspberry pi, but as pyusb is available on linux in general, this should be generally available on these platforms.

Start scratchClient with

cd ~/scratchClient
python src/scratchClient.py -c config_blink

This is the sample scratch Code from the animation. The two led are controlled by a small delay.

Basically, there is the possibility to use more than one blink(1) device. These are identified by their serial number, which can be used to control them separately. Drop me a note if you need this feature.

The usb-control software needs some additional installation, see the the installation remarks in barcode scanner for details.

With scratchClient, it is possible to connect multiple scratch instances with events. ScratchClient can combine this feature with other adapters, as GPIO or alike.

To demonstrate a ‘chain reaction’ type application, I have connected six scratch screens in a 2*3-array to have a red dot traverse the screens.

As I do not own 6 hdmi-monitors for scratch, I have collected 6 vnc-sessions with 600*400-resolution on a desktop computer. The video is taken from this machine.

Each scratch instance sends a specific start broadcast to the next scratch instance to trigger the display-move-hide sequence there. So Instance 0 sends ‘start_1’, instance 1 sends ‘start_2’ and so on. Instance 5 sends ‘start_0’ and the sequence starts again.

The sample is in the scratchClient-distribution, scratch/chainReaction-folder. If you want to run this sample, you need six raspberry computers. Start scratch/chainReaction/reaction_0.sb on each of the raspberryPi. Change the value of ‘whoami’ to 0, 1, 2.. 5 and arrange the screens in

0, 1, 2
5, 4, 3

order.

On one of the computers, the scratchCommunicationServer needs to be started.

cd  ~/scratchClient
python src/scratchCommunicationServer.py

For each of the computers, there is a distinct computer-specific config script. Adjust the

 <parameter name="server" value="192.168.2.90" />

in the config-files to match the ip-address of the server computer.

For computer 0, use config_start_0.xml:

cd  ~/scratchClient
sudo python src/scratchClient.py -c scratch/chainReaction/config_start_0.xml

and start scratchClient on other computers with config_start_<N>.xml, N=1..5.

The remote connection adapter can be combined with other adapters like GPIO or whatever needed. This is the reason to start the python application with sudo.

The current configuration combines the remote communication adapter with a GPIO output on GPIO18. This is a feature unique to scratchClient.

piFace uses MCP23S17-chip, which is supported by scratchClient.

The chip is a 16bit port expander; in piFace one group is used as an input, the other group of 8 bits are used as outputs, connected to a open collector driver.
One of the interrupt pins of the chip ‘intB’ is connected to  GPIO25. This is not used by scratchClient (but does not allow to use this pin for other purpose.

The hardware setup: two LED, a green one and red one, and a small motor powered by a battery and controlled with the relais.

This post demonstrates the use of scratchClient as a ‘hardware abstraction layer’, assigning meaningful names to scratch variables.

In this example, I connected a red and green LED to piFace.
With default configuration, the default names are ‘out_2’, ‘out_3’.

Here a sample of a blinking LED, using these definitions.

This works, but the variable names are not very conclusive. There is the need to keep a record on what this ‘out_2’ is meaning. But scratchClient allows to tweak the configuration files and provide more meaningful names for the variables controlling the hardware.

When editing scratchClient/config/config_mcp23s17.xml, the names of the variables in scratch can be changed. ‘green_led’ and ‘red_led’ are better describing what is connected to the hardware.

Restarting scratchClient is needed when configuration is changed.

Side topic: the ‘all’-variable, common to all outputs here, can be used to set all values immediately to either ‘0’ or ‘1’. Useful for a ’emergency shutdown’ or alike.

With the meaningful names, a scratch script looks like this:

The script gets more expressive. There is no need to map the abstract names to the thing connected.

Another example. Suppose a small motor is connected to relais_1.

Here, the variables ‘relais_1’, ‘out_1’, ‘all’ can be used to drive this output.

Setting this variable is straightforward, but ‘relais_1’ is not a descriptive name.

When editing the configuration, the scratch variable names can be changed to ‘motor’.

This changes the names in scratch to  ‘motor’.

The following snippets show the changes: left side are the default definitions, right side the more meaningful names.

In a quite popular computer magazine, c’t 2015-03-07 (heise verlag), there is a nice article about how to connect a smartphone’s positional sensors to a remote server by using a web page, some javascript and websockets.

Starting from this, there was the idea to connect this to scratch (what else ?).

The basic roadmap was
– add a html-page to my scratchClient’s web server, with javascript

var addr = "ws://" + window.location.hostname + ":" + window.location.port + 
           "/pendel";
var websocket = new WebSocket( addr );
 
function handleOrientation(event) {
       var x = event.beta%90;
        var y = event.gamma;
        x += 90;
        y += 90;
          try {
                websocket.send(JSON.stringify( { x:x, y:y }));
            }
            catch(err) {
                // console.log( err.message );
            }
    }
    window.addEventListener('deviceorientation', handleOrientation);

– in scratchClient, there is cherrypy used to serve the web pages. WebSocket was a new feature to be added there.

– an adapter needed to be written adapter.websocket.WebsocketXY_Adapter, receiving the messages and converting them to scratch variable updates.

So far the plan.
Websocket implementation in sandbox environment worked well, but as I use ‘routes’ to dispatch the requests it took some time to find the correct setup.
Next finding was that the connection is really performant, and a slow movement of about a second duration provides a hundred messages flowing into scratchClient. This is far above from what scratch is able to handle.

Filtering out messages is starting in the browser. Rounding values to a tenth of a degree and sending values only on change removes quite a lot of values. After some experiments with timers in my android browser I found no viable solution to throttle update rate. Timers seem not to work in this javascript environment. Next step in filtering is in the adapter, taking most current value each 0.05sec and ignoring intermediate values.
Final step of filtering is inside scratch. When using the ‘glide’-move, scratch will ignore intermediate values. When using the ‘goto’-statement, processor load is getting much higher.

When I have seen webSocket working pretty smart, I removed the ajax-updates and webEvents from/to web browser to server. When working on the server side, some legacy code in editing values in browser was rewritten, the svg-generator is smarter now and the underlying event distribution system in scratchClient was replaced by a publish-subscribe pattern.

Installation of scratchClient now needs ‘ws4py’ in addition to cherrypy. See the docs.

Start scratchClient

cd ~/scratchClient
sudo python src/scratchClient.py -c config/config_websocket_pendel.xml -guiRemote

The guiRemote-switch is needed to allow remote browsers connecting to scratchClient.

In a smartphone browser, navigate to your pi’s address. Of course you need a (wireless) network connection between smartphone and raspberry. In my network, the RaspberryPi’s address is 192.168.2.90, most possibly different for your PI. Use ‘ifconfig’ to look it up.

http://192.168.2.90:8080

Navigate to “Smartphone as Sensor”

You should see rectangle with a red/green dot moving around. This is as proposed by the c’t-article.

In scratch, enable remote sensor connections and provide the following script. gotoX and gotoY are sensor values provided by the scratchClient. The xl and yl-Variables are local variables in scratch.

The x and y-values are getting exchanged and the y-value gets inverted to match the coordinates of the smartphone to scratch stage.

And thats it. The sprite moves close to the smartphone movements. There is some small time lag on my PI ModelB (not a pi plus so far), but sufficient good.