Meeting: Connecting things to the Raspberry Pi

You can watch the video on YouTube via this link.

Report by Peter Richmond

June’s meeting saw Ian Stanley talk about his experience of connecting things to a Raspberry Pi using the GPIO header on the board. Along with the bare-bones of a serial port, this header contains a couple of other standard interfaces and some general purpose pins which can be used to directly control custom hardware.

Simple IO

Ian had previously used a lot of serial devices in conjunction with RISC OS, and when the Pi came out he had been waiting for a RISC OS-specific serial driver for the Pi so that he could modify his existing programs to connect the numerous devices that he already had. His boards are all self-made, and start off with a ‘master’ board to which other boards are connected via a multi-way ribbon cable.

Certain pins in the GPIO header are allocated for the I2C (or IIC) bus: a very simple serial interface which was included on the Archimedes and later Acorn systems and could be accessed by podules. A large number of different devices can be connected to the I2C bus, as it’s a common way to communicate between different ICs in a circuit. One common example is a ‘bus expander’; using one of the readily available Raspberry Pi ‘expander’ boards, which take advantage of one of these ICs, will give you another sixteen GPIO pins available for various uses – either as inputs or outputs.

You can write your own BASIC programs to access the hardware using GPIO SWI calls, which can read data and write to outputs. The first thing that Ian showed us were some LEDs being driven not by serial port, but by the standard GPIO pins. The software he wrote can set the state of various pins, using those SWIs which can read and write values to these pins and control whether they are used as inputs or outputs.

Next, a stepper motor and a servo were connected to the Pi. The stepper motor was a four phase variety, which needed four GPIO pins to control its movement along with a 12 volt power supply. This was then controlled via a program on the Pi: either running in steps or making it oscillate between two limits.

Serial connections

Ian found the serial driver module while he was looking through the ROOL website. The module allows you to set the baud rate and format of start and stop bits, then write data to the PI’s UART. The receive and transmit signals from the UART come out to two more dedicated pins on the GPIO header, but the voltages are only 0V and 3.3V (for ‘low’ and ‘high’) like the rest of the port’s signals. ‘Real’ RS232 serial ports require signals of around −5V and +5V (or more), so an IC called a serial line driver is required to shift the levels around and prevent the attached hardware from destroying the Pi. The total cost of all the parts to get the full serial port working is less than ten pounds, but does involve some lightweight soldering.

The first thing that was connected to this RS232 interface was a microcontroller – the program used on the Pi identified the type of controller, which also had GPIO and analogue ports on-board. It then allows you to read the GPIO pins on the micro-controller, just as the pins on the Pi can be read directly. The pins can also be written to as outputs, and on Ian’s demo this changed the state of the associated LEDs.

The baud rates available from the Pi’s serial chip allow 31.25kHz signals to be generated, which is 1MHz divided by 32 and just happens to be the rate at which the Musical Instrument Digital Interface (or MIDI) operates. An interface was then connected to the serial port which gave one in, one ‘thru’ and two MIDI out ports. The transmit pin goes through a circuit which gives an opto-isolated input, which is used in order to avoid ground loops and the driver chip is a standard TTL chip. Again just a few cheap chips allow the MIDI interfaces to be built.

The MIDI output was connected to a MIDI sound module, which we had wired up to our PA system. A BASIC program was then loaded which set the board up to the correct baud rate and data format. Reference was then made to the Acorn MIDI manual which gave details of choosing a MIDI ‘channel’, an instrument within that channel, a note to be played, and the volume of that note. This is enough to get some sounds out of a MIDI module, which we then heard.

There are, however many more options for control of the sound via MIDI. Ian played us some music from a non-multi-tasking BASIC program that he had written, before having a more detailed look at the format used for MIDI files, which included things like time signature, the sound associated with each MIDI track, and so on.

Sound and light

We then looked at DMX, which is a similar type of control system to MIDI except that it deals primarily with theatrical lighting and control. It’s a 250k baud signal comprising eight bits with two stop bits and no parity; again, 250kHz is 4MHz divided by 16. The format is a ‘break’ signal for one byte to start the sequence, followed by a gap of a byte before you start transmitting the data – which can be up to 512 bytes.

The bytes originally indicated lamp brightness, meaning that it was possible to control up to 512 lights from one controller: you don’t have to send all that, however, because the break signal says that you’re going to start again. With modern lighting, the data can be used for many other things beside brightness: for example, controlling stepper motors to move and direct the beam of light, adjust mirrors, change the beam’s colour with filters and even place shadow masks into the beam to create different shapes where the light falls.

Now that ‘normal’ lamp ‘bulbs’ are being replaced by multi-colour LED arrays, multiple bytes can be used to control the brightness of different colour groups within a luminaire – even allowing colour mixing from red, green and blue LEDs. These days, DMX also has many other theatrical uses beyond lighting: such as controlling smoke machines and other special effects, timing the ringing of on-stage telephones, and much more besides.

Ian used GPIO pin 4 to start the sequence by controlling the break signal, along with a balanced line driver to drive the DMX data lines: these are a twisted pair set-up, very similar to Econet. Ian had this interface wired up to a much more modest set of four lights about 30 feet away. He mentioned that for some reason, the current Pi driver didn’t work in this particular instance, so he showed that the idea worked via a different interface. DMX lights usually have a set of dip switches to set which bytes they will be listening for from the 512, while control boxes and lighting desks usually have a set of dip switches (or a software interface) to select which range of lights are to be controlled.

There are also MIDI to DMX devices available, so that in a MIDI music file you can not only include music instructions but also which lights are to change to what, and when – all in time to the music!

Remote control

Ian then left the serial interface behind and looked another method of control that most of us wouldn’t have really thought of: the internet! He had a server which was running under a Microchip microcontroller: an 18F67. The whole setup included network and power, along with a built in network port and GPIOs, plus serial and analogue ports and a 1MHz EEPROM to hold programs.

Ian then went to a web browser and connected to the controller – unfortunately the interface was very Javascript-driven, which really makes it a non-starter for use with NetSurf. He went to embedded commands, and we could see values of switches, potentiometers and temperature changing. GPIO ‘things’ can be remotely controlled by a network!

The embedded commands can be put into a web page and read remote values. You can also connect to it using Telnet and values will be read, as before. The same set of values can be also be read via the serial port, and it can also be used to send DMX data – so you could switch on the lights in your house via the internet. The Microchip controller cost less than £40 in total.

A universal interface

Ian rounded off his talk with a look at USB, which of course is another serial protocol. The first program that Ian looked at was written in the Netherlands by Paul Reuvers of X-Aample Technology, and can display activity on various USB devices. Clicking on USB Info’s status window and requesting More... information should show all the connected devices. Ian had a powered hub and two internal hubs within the Pi, as well as a mouse, keyboard and the built-in network port.

Ian then connected a Velleman K8055 I/O board via USB: the screen then changed to show a USB device on USB 7. Double-clicking on it revealed that it was taking power from USB and appeared as a Human Interface Device (or HID). It had two ‘endpoints’ (one in and one out), whereas a mouse only has one endpoint since it is only sending information back to the computer.

The endpoints appear as buffers in the Pi, so you can connect to them and put data into them. A program written by Dave Higton was then loaded, which allows you to monitor activity on outputs and inputs for the Pi via the Velleman board. The Pi ‘polls’ the other end to read data, as it is the ‘master’ – the microprocessor on the board never transmits data by itself.

Using USB Info you can find out the manufacturer of the product, as well as finding out (in the case of the Velleman board) that you need to send out eight bytes of data for it to respond. Ian then ran a BASIC program whereby the device and endpoint number had to be ‘opened’ for use, and then controlled some LED lights by this combination.

To run the Velleman board you have to run a specific program to drive it. If you look at the details of a device, a mouse appears as an HID, but in the subset appears as a mouse, without a manufacturer. This means all mice will work, since they don’t need anything specific to any manufacturer – the same applies for keyboards.

Ian then wired up a USB to MIDI device, and mentioned that he had found that they all had a common format. Its classed as an audio device, but has a sub-class of a MIDI streaming device. Ian had then looked at the USB MIDI spec of his device in order to write a driver, and in his case he had a device that could drive multiple MIDI outputs. His particular device needed four bytes in order for it to work. Again Ian ran one of his own BASIC programs and then played a note on his sound module via USB, followed by a musical piece using a number of instruments.

The programs that Ian had written were made using the late Ray Favre’s Dr Wimp libraries, which are included with the Raspberry Pi. There are various examples and tutorials, and a template application is provided which is awaiting ‘procedures’ to be filled in to do things such as draw screens, transmit data and in the last case, play MIDI. This made it easy to make the programs multitask on the desktop.