Tinkering with Raspberry (and other things)

The “All-Out” Board – Part 3 (a closer look)


I finished testing my All-Out Board today and was very glad that everything from I/O to the level shifting interface connections works as planned. So I decided it is time to get to the more technical stuff. In this post I am going to introduce the board, its features and some basic configuration possibilities. Then we’ll take a look on how to test communications (therefore an Arduino board is needed). And finally I’ll explain some of the electronics that is happening on the board. I am going to split the electronics part as this post is long enough by now…

The board details

So this is a picture of the board. As you can see it is divided into functional blocks:


In the top left is a regulated power supply that is to be connected to an USB power connector. It creates 3.3 Volts and supplies both voltages (5 Volts and 3.3 Volts) to the board. There are two pin headers on the top that are used to configure the power source. That means the board can be run without an external power supply by setting jumpers accordingly. It then is powered directly through the Raspberry Pi’s GPIO pins. For simple experiments like lighting the LEDs or checking if an input is High/Low this is enough.  If there are external sensors connected via the I2C, SPI or RS232 headers, using the external power is better.

The middle left is the RTC with battery (upside down, see my last entry) and some other parts that in fact do the level shifting for the communications ports. Later more on that.

The bottom left is occupied by lots of pin headers for connecting stuff. The 26-pin header on the bottom is where the Raspberry Pi gets connected, obviously. Then you can see (from left to right) headers for the I2C-bus (both for 3.3 V and 5 V devices), the SPI-connector (that is 3.3 V only) and RS232 for 3.3 Volt and 5 Volt. The I2C is a bus communication where you can have multiple devices connected. You can’t do this with RS232.

The complete right half of the board is taken by the buffer circuits and jumper connectors to the left and right of every IC. The connectors are marked with the pin number (as introduced by the wiring-pi library) and the letter “o” for output and “i” for input. So in order to configure pin 2 as output one needs to set two jumpers. One on the raspberry side and one on the “outside”. I positioned the jumper connectors so that the jumpers are horizontally aligned when configured correctly. This gives an additional optical feedback.

The pins 10 to 13 cannot be used together with the SPI connector. To indicate this specialty the chip is positioned more on the right.

On the rightmost side the indicator LEDs and pin headers from the buffered lines are positioned. The LEDs switch on when there is a 3.3 V level (HIGH) on a buffered pin. It does not matter whether the signal is output or input.

Configuration examples

Below is a detailed image showing the power configuration via jumpers:


And this is how the configuration of the input/output lines is done:


In the above picture the pins 0,2 and 3 are configured as output, pin 1 is configured as an input. The (very poorly drawn) blue rectangles show the position of the jumpers. They are aligned between the left and right jumper header, so everything is fine. The buffer circuits are, of course, socketed. This means if I use in/out in the wrong direction it fries the circuit and leaves the Raspberry intact.


The communication is tested with the help of an Arduino board. As always, before connecting anything to the Raspberry PI or to the All-Out Board, I shutdown the Raspberry (sudo shutdown -h now) and disconnected it from power. The following differs dependent on the type of Arduino at hand. If it is a model that is powered by 5 Volt, use the pins marked with “5V” on the All-Out Board. If the Arduino runs on 3.3 Volt, it is connected to the pins marked with “3.3V”. Connecting a 5V Arduino to the wrong pins will damage the board and the Raspberry.


A raspberry Pi without modifications will output system messages on the serial pins. I am going to use this a my test scenario, thus I won’t disable the console logging feature. This is for connecting a serial console instead of monitor and keyboard. You can, in fact, login and work with your Raspberry via a serial connection. The baud rate for the console is by default set to 115200 baud, which is too fast for the Arduino and the software serial emulation. So we are going to change this first:

Two files need to be edited to set another baud rate: /etc/inittab and /boot/cmdline.txt. I always copy the original files first:

sudo cp /etc/inittab /etc/inittab.orig

sudo cp /boot/cmdline.txt /boot/cmdline.txt.orig

Now the files can be edited. In /etc/inittab look for the lines

#Spawn a getty on Raspberry Pi serial line
T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100

and changed to:

#Spawn a getty on Raspberry Pi serial line
T0:23:respawn:/sbin/getty -L ttyAMA0 9600 vt100

Now the second file /boot/cmdline.txt is usually only one line. Changing every occurrence of 115200 to 9600 does the trick. It is now time to shutdown/halt the Raspberry Pi.

As a next step an Arduino is going to be programmed that it just echoes the lines that are transmitted from the serial console. Here is the sketch I uploaded to my Arduino:

#include "Wire.h"

SoftwareSerial piSerial(10, 11); // RX, TX

void setup()
// Open serial communications and wait for port to open:
Serial.println("Ready to receive data");

void loop() // run over and over
if (piSerial.available())
if (Serial.available())

This simply reads from the RX/TX lines we defined (Pin 10 and 11) and writes this to its own serial console. After transmitting this code, the Arduino needs to be powered off prior to connecting it to the Raspberry.
Making the connections (I am not good at drawing, so this must suffice):

Arduino   ----   All-Out-Board
 Pin 10 ---------- RS232 TX
 Pin 11 ---------- RS232 RX
  GND   ---------- RS232 GND

Care must be taken if it is an 3.3V or 5V Arduino! If one changes the pin numbers in the Arduino sketch one needs, of course, change the wiring, too.
After the connections are made I connected the All-Out-Board to the Raspberry and powered on the Arduino first. In the Arduino IDE the Serial Console is started and set to 9600 baud. Powering the Raspberry on gave this output on the serial console:


So this is the proof that serial communication is working. And as I connected the RX/TX lines to the 5V pins, it shows that the level shifter also is working.

As a last step the modifications made to the Raspberry’s console baud rate need to be undone. As I have backup files I just move the original file back into place:

sudo mv /etc/inittab.orig /etc/inittab

sudo cp /boot/cmdline.txt.orig /boot/cmdline.txt


As there is a RTC on the board I was able to test general I2C communications by just repeating the steps from my RTC post. But I wanted to see whether level shifting also works on the I2C header. So again, I used my Arduino to do so.

I used the following sketch on the Arduino:


#define SLAVE_ADDRESS 0x06
int number = 0;
int state = 0;

void setup() {
    pinMode(13, OUTPUT);
    Serial.begin(9600);         // start serial for output
    // initialize i2c as slave

    // define callbacks for i2c communication

    Serial.println("Ready for I2C testing.!");

void loop() {

// callback for received data
void receiveData(int byteCount)

        number =;
        Serial.print("data received: ");

// callback for sending data
void sendData()

On the Raspberry Pi the following Python code waits for a number input, sends it to the Arduino and then calls the Arduino (hence “slave”) to send something.

import smbus, time
import os, sys, termios, fcntl  # needed for getChar()-function

bus = smbus.SMBus(1)    # user (0) for Version 1 Pi
addr = 0x06             # listen on this i2c address - compare arduino sketch

def writeValue(value):
  bus.write_byte(addr, value)
  return -1

def readValue():
  val = bus.read_byte(addr)
  return val

def getChar():
  fd = sys.stdin.fileno()
  oldterm = termios.tcgetattr(fd)
  newattr = termios.tcgetattr(fd)
  newattr[3] = newattr[3] & ~termios.ICANON & ~termios.ECHO
  termios.tcsetattr(fd, termios.TCSANOW, newattr)

  oldflags = fcntl.fcntl(fd, fcntl.F_GETFL)
  fcntl.fcntl(fd, fcntl.F_SETFL, oldflags | os.O_NONBLOCK)

    while 1:
        c =
      except IOError: pass
      except KeyboardInterrupt: break
    termios.tcsetattr(fd, termios.TCSAFLUSH, oldterm)
    fcntl.fcntl(fd, fcntl.F_SETFL, oldflags)
    return c

  while True:
    print "Type a key"
    inp = getChar()
    print "Sent ", inp, " to Arduino. Now wait 1 second"
    print "Done Waiting. Reading..."
    rcv = readValue()
    print "Received ", rcv, " from Arduino. Now waiting 1 second"
except KeyboardInterrupt:
  pass  # cleaning up

So as I have defined 0x06 as the address for my Arduino I2C device, when connecting it and running i2cdetect it should display:

pi@rspdev1 ~/Workplace/Python/GPIO $ sudo i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00: -- -- -- 06 -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- UU -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
pi@rspdev1 ~/Workplace/Python/GPIO $

And there it was.  The “UU” on position 0x68 it the real-time clock. “UU” means that detection was skipped because the device is in use. Now it was time to send some bytes forth and back. And that worked, too:


Some of the electronics stuff is explained in part 4.


3 thoughts on “The “All-Out” Board – Part 3 (a closer look)

  1. I really like reading about the progress you make on your project 🙂

    • Thank you. Actually I ordered two 433MHz transceivers with the parts for the board. So there is definitely more to come if my time allows.

  2. Pingback: The “All-Out” Board – part 4 (Electronics) | MyRaspberryAndMe