Friday, July 6, 2012

Adding a FTDI chip to a Raspberry Pi

Over the past month of owning my Pi, one lacking feature bothered me. I had worked with a beaglebone for a few months beforehand and had gotten used to the easy, single cable development system on the beaglebone, so I decided to give my Pi a FTDI connection over the included micro USB port. The concept was simple and despite being a pain to solder, was pretty simple to implement.


For this hack, we only need a few of the pins on the FT232RL. We need TXD, RXD, AGND, GND, VCC, VCCIO, 3V3OUT, and TEST. You can start out by shorting the TEST and AGND pins, and the VCC and RESET# pins. After this, run a small piece of wire from 3V3OUT to VCCIO, and a small piece of wire from the GND next to VCC to AGND/TEST. The VCCIO pin takes in the voltage supply for the RXD and TXD pins, and since the Pi is 3v3, we need to tie it to the 3V3OUT pin voltage source. A problem that took some reading to figure out is that TEST needs to be pulled to ground in order for the device to enumerate correctly, or else the device will connect, but quickly disconnect with error messages about improper IDs.

After you have done all the bridging and shorting, the hardest part begins, attaching the ~30AWG wire to the FTDI chip. If your up to making a incredibly discreet breakout board and have it fit on the Pi, you'll likely save yourself some time, but due to time and money constraints, this works. You need to connect wires to TXD, RXD, GND/AGND/TEST jumper, VCC, USBDM, and USBDP (USB plus and minus). The latter two are what we will be connecting directly to the onboard usb header.



The next step is attaching everything to the Pi. Once you have finished soldering everything and are sure that you want to continue, you can superglue or epoxy your FTDI chip right onto the Raspberry Pi. For this step, solder the VCC wire to TP1 and the GND wire to TP2 for ease, as we do not want to crowd the usb header. After that, attach the RXD wire to the TX pin on the pin header, and vice versa for TXD and RX. After all those, it's time to attach the USB wires to the header.

 As you can see in the photo and the schematic above, the second pin to the left is D-, so solder the USBDM wire, and to the center/third pin solder the USBDP pin. After all this you should now be able to attach your RasPi, type "screen /dev/ttyUSB0 115200" and see your boot commands. If you haven't set your Pi up to have a serial tty, it's time to set that up now.




In order to see boot messages over serial, your cmdline.txt should look similar to this:


And in your /etc/inittab file, change the line that should read similar to:
1:2345:respawn:/sbin/getty 38400 tty1
and change it to:
1:2345:respawn:/sbin/getty 115200 ttyAMA0

After that, you should be able to do single cable development on your Pi. Good Luck!

Links:
Raspberry Pi Schematics
FT232RL Datasheet



12 comments:

  1. Do you think it would be a good idea for future RaspberryPi (e.g. RPi2) boards to include a FTDI chip on board to easily access the serial console? (I would imagine you connect to it using the microusb power input, which in the current version is doing nothing.).

    The reason I think it would be awesome to do it that way, is the same reason as you said above, it makes barebone development a single cable affair.

    Plus for school classrooms, I think students can appreciate just carrying one usb cable and a RPi2 for low level coding.

    ReplyDelete
  2. Yes, I do think that is should be included, though I can see that they wanted to keep part costs down and the FTDI chip is not one of the cheapest, but it think it would help in the long run, as the price added when produced in bulk would be about the cost of another cable.

    ReplyDelete
  3. Adding to the above. Instead of using embedded FTDI chip for RPi2, maybe we should do it like the 'arudino UNO' and use a atmega chip instead. This means with the right cable, you can turn the microusb 'power input' port, into an advance usb keyboard, mouse, that is directly hooked into a very powerful processor.

    ReplyDelete
    Replies
    1. It would be interesting to do thing like that, but it seems that the price of the atmegaU chip would be more than that of the FTDI, but it would be cool if the could add either and still keep the price under $40.

      Delete
    2. I think the Arduino folks switched to the ATMega from the FTDI to save cost. The FTDI is more expensive than it should be.

      At Digi-Key:
      FT232RL: $2.60 @ 3000 Pcs.
      ATMega8U2: $2.07 @ 1 Pcs.

      Delete
    3. yes I agree. It's because the ATMega8U2 is smaller and easier to manufacture than a PDIP package (Means you can ship more of these tiny chips than the average arduino chip)

      So Matthew Skolaut, it may actually be cheaper to use a atmegaU chip, rather than an FTDI chip.

      (Plus you get extra GPIOs from the microelectronics, which may be useful in certain circumstances, requiring real time control).

      Delete
  4. The new FTDI X-series is cheaper and smaller, could be a better otpion for that mood :)

    ReplyDelete
    Replies
    1. Yes, the X-series would be better, smaller package and less expensive, I sadly didn't know about them until after my build :/

      Delete
  5. This is a really great hack. Have you had any issues with your USB ports not being able to source enough current to run the RasPi? I was under the impression that this was not recommended.

    ReplyDelete
    Replies
    1. No problems, the FT232RL doesn't take up more than 15ma of current, so it's not going to make much of a difference if your Pi's on max power, and if it's not connected to data, it's power draw in ~100ua, so it won't suck power from a dumb power source.

      Delete
  6. I wonder if it would be possible to emulate a USB port on a couple of the GPIO pins. There are a number of Arduino libraries, for example, that implement USB serial entirely in software (e.g. V-USB for AVR). Perhaps something similar could be done with a daemon in user space on the Raspberry Pi?

    ReplyDelete
    Replies
    1. While an interesting possibility, this would require a relatively complex setup of drivers and daemons to do software usb emulation. If anything, it would be better to look into the possibility that the broadcom SOC supports USB device in addition to host mode, and possibly do something similar to that done by the beaglebone.

      Delete