Like so many others, we found a nice 1.8″ TFT display in China, and we decided to make a breakout for it. Instead of just breaking out the pins, and perhaps adding the micro SD card holder, we equipped our version with an USB enabled microcontroller and a few buttons for GUI projects.

This display is based on the ST7735R controller and is capable of driving 160×128 RGB pixels with a color depth of 18 bits (262.144 colors) maximum. This great little display has all the circuitry required to drive it onboard, and runs from a single 3.3 volt power supply. It also uses a serial protocol, so only a few pins are needed to interface it.

It has also some drawbacks. It doesn’t have a character generator like the trusty old HD77480, so the font needs to be stored in the microcontroller which takes up lots of space. Another drawback is that the display only takes raw image data and not indexed data. Every pixel takes at least 16 bits, which makes the total transfer about 40k for each screen.

Besides the lovely TFT this board features the following things:

  • Micro SD card holder
  • Footprint designed to fit into a 5 1/4 drive bay cover
  • MiniUSB connector
  • USB connection is solderable (for internal PC use)
  • Unused pins are broken out (digital I/O and analog input)
  • Broken out pins are PPS (PeripheralPinSelect) capable
  • 3V3 and GND broken out
  • Buttons are broken out
  • PIC18F26J50 uC

This is the backside of the board, still covered in flux after a midnight soldering session. It took us a couple of revisions to get is to this stage. Perhaps you remember this post? That was revision 2 or 3 of this board, and we got it finally right this time (though C8 should be further away from the uSD ). Ah well, lets move to the fun part, the schematic.


This is a fairly basic PIC18FJ (USB) support circuit we describe in the PIC18FJ quickstart on our wiki.

The display and micro SD connection are straightforward, and are connected to the PIC SPI pins.  Both get a separate /CS (chip select) pin. The display also gets a pin for RS, and /RESET. The backlight is switched on and off through a transistor.

Four buttons are added for interfacing: plus, minus, ok and back. We found this to be the minimum for a decent decent menu system.


While graphic LCDs are cool, there’s still a ton of support for old character LCD. To bridge that gap, the firmware emulates the classic character-based Matrix Orbital serial protocol. Using the USB interface, this display supports PC programs that display news, email notices, and system stats on character LCDs, such as LCDproc (Linux) and LCDsmartie (Windows).

Some the TFT graphic display has a lot of features (like color!) that old character LCDs lack, we extended the Matrix Orbital command set. New custom commands change the text color and display a picture stored on the uSD card.

As always comments and suggestions are very welcome on this new prototype design.

Grab the latest design files from our SVN.

Join the Conversation


  1. Ouch! Surely this board was just begging for a PIC24. Surely the extra cost would be measured only on a few digits on the right of the decimal point ($0.20) and the extra performance for graphics would be worth many more times that. If a PIC24FJ64GB002 was used then it could be placed with a PIC24FJ64GB502 when they are released thus saving on the cost of the crystal.

    1. The PIC24FJ64GB002 can already be used without crystal. It’s (typical) 0.25% trimmed internal crystal is good enough for USB.
      And I agree, a beefy microcontroller with maybe a bit more I/O (QFP44) would make it an universal USB, A/D/SPI/I2C LCD display board.

      1. Yes, it can do LOW SPEED USB and still be in spec. It cannot do FULL SPEED and be in spec because “typical” is not guaranteed and the tolerance is up to 2%.

        If the GB002 was good enough for FULL SPEED microchip would not be releasing new USB PICs with clock recovery.

    2. The performance would be almost the same as both chips can only do +-15MHz SPI :D

      I have the same TFT hooked up to a pic24e64mc202 and the performance is approx the same.

      1. And both PICs can only do 12MHz USB yet the real world performance of the PIC24 is at least 3X better than the PIC18.

        If anyone wanted to do streaming video over USB what sort of frame rate do you think they will get with a PIC18? For the sake of $0.20 initially and later a small cost savings why would you go with 18-20 frames/second when you could have 50-60 with a PIC24?

        Now for non streaming real time color graphics what will be the real bottleneck?

        15MHz SPI rate / 40K = 375 frames/second. Surely you do not think that the SPI rate will be the bottleneck here.

        To even get 10 frames/second with the PIC18 each pixel would have to be calculated with just 30 machine instruction cycles and that does not include any I/O considerations.

        You can do the calculations yourself but I have no doubt that the PIC24 will be good for at least 3x better graphics performance.

        If someone wants even better performance they could easily swap out the PIC24 for a PIC32MX220F128. Pin for pin compatible and with pretty much the same peripherals

        Anyway it is your baby and I’m sure it will be a popular board in any case.

  2. These things are fairly easy to develop with compared to VGA/TFT,

    unfortunately games looks lousy on a 1.8″ screen why cant we get 12″, 15″ or 20″ versions?

    (Soldering 20,000+ tri-colour LEDs is a bit out of my league!)

  3. looks good! might i suggest changing the orientation or location of the SD card as once a screw i put in the mounting hole it could be very difficult to remove the card. looking at it, either rotating it or moving it backwards (left of screen) would be ok.

    1. it uses a hinged mechanisme for the sd card, in contrary to the one we used on the webplatform which ejects the card. The card is placed on top and the ‘door’ is closed.

    1. We have the most experience with PIC and the development chain is already setup for them. Also we know what a particular chip is capable of and (some of) the quirks of them. Moving over to AVR (or any other uC) will set us right to the start of a learning curve and we need to first learn the uC, setup the development chain. Valuable time will be spent on things we already know on the PIC platform. Valuable time we can use on other things like developing firmware or routing boards.

      Also I think PIC has some really nice features in silicon, nicer development chain and better documentation. ALthough my experience with AVR is very limited and the last time I looked at it is many years ago, so it may have improved over time.

      This is not mend to start an AVR vs PIC war..

      1. Yeah, what he said. I’d like just to add, that the functionality/pricing of AVRs and PICs is nearly identical, and moving to AVRs from PICs makes no sense if the PICs do everything we need them to do.. If/when we hit a performance wall we will most likely move to ARM cortex development

  4. Ok great..the problem is I have 0 experience or knowledge of PIC. Could you point to some really good PIC tutorials…

Leave a comment

Your email address will not be published. Required fields are marked *

Notify me of followup comments via e-mail. You can also subscribe without commenting.