AdaFruit recently released a sweet little TFT display that I was dying to hook up to a netduino: the display features a resolution of 128*160 pixels, is capable of showing 18-bit colors and has a microSD card reader on the back of the breakout board. As usual, Limor wrote a nicely detailed Arduino tutorial showing how to connect the display and how to write sketches to drive it.

The Arduino driver relies on the ability of the Atmega168/368 to toggle digital lines extremely fast, which does not work well on the netduino due to the latency introduced by the .Net Micro Framework: even when configured to use hardware SPI, the Arduino driver constantly toggles a data/command output line, rspin below, which would be unbearably slow on the netduino if the same method were applied.

You can see an example of this in the drawPixel function:

 
void ST7735::drawPixel(uint8_t x, uint8_t y,uint16_t color) {

  if ((x >= width) || (y >= height)) return;

  setAddrWindow(x,y,x+1,y+1);

  // setup for data

  *portOutputRegister(rsport) |= rspin;

  *portOutputRegister(csport) &= ~ cspin;

  spiwrite(color >> 8);

  spiwrite(color);

  *portOutputRegister(csport) |= cspin;

}

Driving the ST7735 on the netduino

The  netduino has one advantage over the Arduino: it has plenty of RAM. So, instead of toggling I/O lines slowly all the time and using next to zero RAM, the netduino driver allocates a 40K buffer corresponding to the resolution of the display in 12-bit depth colors (16 bits per pixel) and leaves the ST7735 in ‘data’ mode upon initialization.

Drawing always happens on the internal buffer first. Then, whenever the actual display needs refreshing, the display I/O operations are performed using hardware SPI, blasting the entire 40K buffer. It may sound crazy but using this method on the netduino is faster than refreshing a single pixel while toggling an I/O line!

Take a look at the following netduino code to see how this works, compared to the Arduino driver drawPixel funtion above:

private void Initialize() {

<...>

DataCommand.Write(Command);
Write((byte)LcdCommand.DISPON);
Thread.Sleep(50);

DataCommand.Write(Command);
Write((byte)LcdCommand.NORON);  // normal display on
Thread.Sleep(10);

SetAddressWindow(0, 0, Width - 1, Height - 1);

DataCommand.Write(Data);
}

private void SetPixel(int x, int y, ushort color) {

if ((x < 0) || (x >= Width) || (y < 0) || (y >= Height)) return;
var index = ((y * Width) + x) * sizeof(ushort);
SpiBuffer[index] = (byte) (color >> 8);
SpiBuffer[++index] = (byte)(color);
}

 
public void Refresh() {
Spi.Write(SpiBuffer);
}

The caveat is that allocating a 40K buffer on the netduino does not leave room for much object allocation afterwards. In fact, memory is so tight that OutOfMemory exceptions will be common if not careful and planning your application accordingly.

Before going any further, let’s look at the display in action on the netduino. Please forgive the quality of the video as the camera on my phone doesn’t do justice to the display.

Pretty zippy, huh?

Some hacking required…

As I was trying to get the ST7735 display to work with the netduino, I discovered that the display would stop communicating when configuring SPI to run @ 10 MHz or above.

This is a huge issue for a couple reasons: the speed of the SPI bus determines the display frame rate on the netduino and secondly, mounting a microSD card on the netduino configures SPI to run @ 10 MHz minimum. No matter what. This meant that I could either use the display or the microSD card but never together, preventing scenarios such as loading pictures from the microSD card for display for instance.

Based on previous experience, I began suspecting that the CD4050B logic level-shifter on the ST7735 breakout board was the root cause of the issue and decided to take it out of the equation altogether by shorting out its pins so that it would no longer convert signals. Since the netduino works at a 3.3v logic level, there was no risk of damaging the display driver.

Sure enough, eliminating the logic-level shifter allowed me to initialize SPI @ 40MHz on the netduino as well as using the the microSD card reader without any issues.

Connecting the AdaFruit ST7735 display to the netduino

• netduino GND -> ST7735 GND
• netduino Vcc (3.3v or 5.0v) -> ST7735 Vcc
• netduino D8 (or other Dx pin) -> ST7735 RESET
• netduino D7 (or other Dx pin) -> ST7735 D/C
• netduino D10 -> ST7735 CARD_CS
• netduino D9 (or other Dx pin) ->ST7735 TFT_CS
• netduino D11 -> ST7735 MOSI
• netduino D13 -> ST7735 SCK
• netduino D12 -> ST7735 MISO

Note that the ST7735 LITE pin can be connected to netduino Vcc (3.3v or 5.0v) or any of the netduino’s PWM pins if you’d like to control the intensity of the display’s back light.

As always, you can find the code as part of the netduino.helpers library.

Conclusion

The AdaFruit ST7735 TFT is a fast, bright and convenient all-in-one display and microSD reader:

Using it on the netduino is sub-optimal for the time being due to the memory requirements involved in making the display work at a decent frame rate but, if used carefully, it is possible to achieve very cool results with it right now. Keep in mind that the memory requirement will eventually go away once the netduino starts supporting native ARM code with .Net Micro Framework 4.2, letting applications toggle I/O lines super fast.

Finally, my only wish is for AdaFruit Industries to consider producing versions of their products without built-in logic level-shifters as they can negatively impact some micro controllers such as the netduino.

Happy hacking!

Color Flow image courtesy of Bartelme Design

 

Update on 08/23/2011: here’s the same hack applied to the stand-alone version on the adafruit microSD card reader, this time with a 10K resistor between Vcc and Gnd to ensure that the electrical behavior of the chip remains stable.