RasPiComm – Hardware

Thank you for all the views and responses on my original RasPiComm blogpost!

Here I want to explain the RasPiComm hardware. The software part will follow next week.
At the end of the post you will find the schematics of the RasPiComm version 1 and version 2.

If you are not interested in the RasPiComm hardware, take a look at the original RasPiComm blogpost!

Now, let’s start!

Version 1 vs. Version 2

RasPiComm version 1

RasPiComm version 1 with populated RS-485 driver

As I mentioned in the first blogpost about the RasPiComm, I did two versions of the board. The first version had either one serial port OR an RS-232 port. I used the /dev/ttyAMA0 (TX on GPIO header pin 8 and RX on pin 10. You could either solder the MAX3232 for RS-232 or the MAX3483 for the RS-485 port. But there was another disadvantage: I used the GPIO1 (pin 12 on the GPIO header) for switching between receive and send mode.
Just a short explanation why you need to switch between send and receive mode: Unlike RS-422, RS-485 is an unidirectional bus system. That means that you use the same wires for sending and receiving data, so you cannot send and receive at the same time. Usually you always stay in ‘receive’ mode. If you want to send data you switch to the send mode and return to receive mode immediately after sending your data. The timing is critical here, I will explain that later. There are chips out there which support “auto-direction” from Maxim. I have not yet worked with them, I’ll probably will have a look at them in the future.
Another thing that changed is that version 1 had a SPI header. I removed them simply because the wiring of the SPI tracks would not have been optimal (they are not optimal yet but way better this way).

Changing to RS-485 via SPI

RasPiComm to Rasberry Pi Connector

So the disadvantage of version 1 is obvious: You could either have RS-232 or RS-485, not both. There was another problem. Switching the GPIO line for changing between receive and transmit was suprisingly slow. Not exactly because the GPIO switching is too slow but because it is not so easy to find out when the last byte was transmitted completely to switch back from send mode to receive mode. You can check if the /dev/ttyAMA0 send-buffer is empty using tcdrain(). Sadly this function blocks too long, we lose valuable miliseconds after sending until we can switch to receive mode and receive data. That means that all data that is sent by a RS-485 client before switching back is lost.
To overcome this limitation, and the problem that I can only use either RS-232 or RS-485 I dropped the MAX3483 and used the MAX3140 in version 2. This chip has an SPI-UART and RS-485 controller in one chip.
The interrupt line of the MAX3140 is connected to GPIO0 (pin 11).

The RS-232 connector is driven by a MAX3232, I will probably replace it with another, cheaper version for the production board. Only TX and RX are connected, sadly the Raspberry Pi does not bring both CTS and RTS to the GPIO header, so hardware handshake is not supported. But this is not used often anyways.

I2C Connector
If you look closely at the I2C connector in the schematics you will see that this are actually two I2C connectors. It is a 2×4 header, and unlike all other headers row 1 and row 2 are not identical. I did that for a simple practical reason. I use this header mainly to connect I2C displays. There are two common pin layouts:

  • 5V, GND, SDA and SCL
  • 5V, GND, SCL and SDA

So I did both of them. With that little trick you can connect both types directly to the board using either row 1 or row 2.

All 5 inputs are pulled-down to GND. They are all 3.3V inputs with an 1k resistor to the Raspberry Pi.

Both outputs are open-collector outputs and switched with a BC847 transistor.

Power connector (3.3V, GND, 5V)
The 5V line can be used to supply 5V if you do not use the USB plug or use it as 5V ouput if the Raspberry Pi is connected via USB.
The RasPiComm generates its own 3.3V from 5V, the 3.3V line is connected to this output (200mA combined maximum rating).

RTC with backup battery

RasPiComm bottom

RasPiComm bottom

The backup battery on the bottom side of the PCB is a CR2032 cell. It should power the DS1307 for approximately 10 years. Currently there is a small problem with the battery holder on the bottom – it collides with the S2 socket (DSI). The RasPiComm v2 still can be connected to the Pi, but you cannot push it all the way down (it’s only 1mm). For testing I removed the S2-connector from my Raspberry Pi board. For the production version the PCB will get 5mm wider (did it without changing PCB size!) the battery socket is moved out of the way. It won’t change the footprint of the Raspberry Pi, the 5mm go torwards the video connector. That also means that the battery is slightly moved over the processor. This should not raise any temperature problems, neither for heat dissipation nor for the battery since the operational temperature range for the CR2032 cell is -20 to + 70 degrees Celsius (-4°F to +158°F).

Downloads (Creative Commons Attribution-ShareAlike License)

RasPiComm v1 schematics

RasPiComm v1 schematics

RasPiComm v2 schematics

RasPiComm v2 schematics

7 responses to “RasPiComm – Hardware

  1. Vicary August 7, 2012 at 4:33 pm

    Will all the parts soldered in one, or separated as Adafruit sells their boards?

    • Daniel Amesberger August 7, 2012 at 4:36 pm

      I want to sell them fully soldered, like the Raspberry Pi is.

      • Vicary August 7, 2012 at 6:02 pm

        I am pushing to the limits of the video processing power of my Pi, it really heats up the little board a bit.

        I originally planned a fan which is powered from the 5V pin, by reading your tight design (the 5mm thing) I guess I have to replace your GPIO cap with a higher one to give rooms for the fans. :O

        • Daniel Amesberger August 7, 2012 at 6:30 pm

          Don’t you think a passive heat sink is enough? I do have a infrared camera to check thermal properties of a PCB, if I can reproduce your CPU/GPU load I could check the heat signature of the board with and without heatsink and/or RasPiComm. I wanted to do a blogpost on heat dissipation of the Raspberry Pi anyways.

  2. Vicary August 7, 2012 at 6:10 pm

    Reblogged this on My Raspberry Pi and commented:
    Good News! The all-in-one RasPiComm is getting closer

  3. Pingback: RasPiComm – a Raspberry Pi piggyback board « Daniel Amesberger

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: