Interface between RaspberyPi & PiBorg

How is the PiBorg controlled from the RaspberryPi? What pins are used on the Pi?

Are there any libraries of code available for the RaspberryPi to drive the PiBorg? If so where can they be found?

piborg's picture

The PiBorg is controlled via the I2C interface exposed on the GPIO port, namely GPIO 0 (SDA) and GPIO 1 (SCL), it will also provide power via the 5V power pin and the Ground pin removing the need for a USB based power supply.
GPIO pins are also used to allow programming of both PICs via the Raspberry Pi, however we are not expecting to provide software for this at release, it is intended to provide this functionality in the future to remove the need for using a separate programmer.
Whilst not all of the pins on the GPIO port are used the provided connector plugs over the entire port, there are however a number of GPIO pins exposed on the PiBorg itself for user access purpose.

GPIO pins used by the PiBorg:

  • 5V
    supplied by PiBorg
  • Ground
    supplied by PiBorg
  • GPIO 0 (SDA)
    used as I2C data for PiBorg communication
  • GPIO 1 (SCL)
    used as I2C clock for PiBorg communication
  • GPIO 25
    used as master clear for PIC 1 (programming port)
  • GPIO 4 (GPCLK0)
    used as master clear for PIC 2 (programming port)
  • GPIO 7 (CE1)
    used as program clock for both PICs
  • GPIO 8 (CE0)
    used as program data for both PICs
  • GPIO 9 (MISO)
    potential alternative communication with PIC 2
  • GPIO 10 (MOSI)
    potential alternative communication with PIC 2
  • GPIO 11 (MCKL)
    potential alternative communication with PIC 2

GPIO pins exposed on PiBorg (free for user use):

  • 3V3
    this is actually from the PiBorg itself
  • 5V
    same supply provided to the Raspberry Pi
  • Ground
    same supply provided to the Raspberry Pi
  • GPIO 14 (TXD)
  • GPIO 15 (RXD)
  • GPIO 17
  • GPIO 18 (PCM_CLK)
  • GPIO 21 (PCM_DOUT)
  • GPIO 22
  • GPIO 23
  • GPIO 24

As for software libraries they are not available yet, we are still testing them and want to make sure they are robust before releasing them.
They will be available from either sourceforge or github closer to release.

Both the software programmed into the PICs and the software libraries/examples for the Raspberry Pi will be open source licensed under the creative commons CC BY-NC-SA, so we will be looking for suggestions, improvements and additions after we have made them available.

Thanks for the details. Does this mean that I can't use the i2c bus for other purposes?
Presumably it's possible for multiple PiBorgs to use the i2c bus (I imagine this is how they are connected) will your software be able to handle non-PiBorg traffic on the i2c bus?

piborg's picture

The I2C mechanism is indeed what we are using to attach multiple PiBorgs to a single Raspberry Pi.

Physical connection to the Raspberry Pi I2C port

On each PiBorg there are two 8p8c connectors for axis-axis daisy chain connection. There are always two of these spare (from the first device in the chain, and the last device in the chain) When there is only one PiBorg, there are still two connectors free.

I2C Protocol

Restrictions apply to adding additional I2C devices

  • The I2C address of the target is not also used by a PiBorg attached to the system
  • Traffic is not too heavy - the more messages sent by other things the less responsive the PiBorgs will be to the library
  • Only one master is on the I2C bus, this will most likely be the Raspberry Pi
  • The slave devices do not hold clock lines low for excessive times
  • The slave devices should adhere to normal multiple slave configurations - e.g. not holding lines high when not being addressed


At this point in time we do not have any mechanism for sending non-PiBorg messages along the I2C bus, however introducing a basic mechanism into the library to allow such messages should not be a problem (and we are happy to code this functionality) providing you adhere to the I2C protocol restrictions above.
If going via the library is not satisfactory then a proper I2C device driver will be required which can deal with multiple processes accessing the bus at the same time, in this case some minor alterations to the library code will be required to make it use the device driver instead of raw register access.
The library will still require a certain amount of time to talk to the PiBorg otherwise control will be inhibited.

Subscribe to Comments for "Interface between RaspberyPi & PiBorg"