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?
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
Drivers
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.
piborg
Thu, 07/12/2012 - 10:10
Permalink
Interface between RaspberyPi & PiBorg
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:
supplied by PiBorg
supplied by PiBorg
used as I2C data for PiBorg communication
used as I2C clock for PiBorg communication
used as master clear for PIC 1 (programming port)
used as master clear for PIC 2 (programming port)
used as program clock for both PICs
used as program data for both PICs
potential alternative communication with PIC 2
potential alternative communication with PIC 2
potential alternative communication with PIC 2
GPIO pins exposed on PiBorg (free for user use):
this is actually from the PiBorg itself
same supply provided to the Raspberry Pi
same supply provided to the Raspberry Pi
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.
dsnowdon
Thu, 07/12/2012 - 11:13
Permalink
Thanks for the details. Does
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
Thu, 07/12/2012 - 12:08
Permalink
Shared I2C
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
Drivers
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.