Driving an AdaFruit ST7735 TFT display with a netduino

Color Flow

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.

CD4050B - Before hack
CD4050B – Before hack
CD4050B - Before hack
CD4050B – After hack

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.

 

 

 

 

Advertisements

Using a MAX7219/MAX7221 LED display driver with a netduino

LED Matrix Glow

In a previous post, I described how to drive an LED matrix relying on persistence of vision. While beautifully minimalist, this method has drawbacks: it requires 11 digital pins on the netduino and takes constant CPU cycles to refresh the matrix. This can potentially put tough resource constraints on the rest of the application.

This is where a chip like the MAX7219/MAX7221 LED display driver comes in handy: all you need to do is to send it the data that you want to display over SPI and it will drive LEDs without further involvement from the micro controller.

The chip offers 2 display modes: ‘Decode Mode’ is intended to manage 7 segment displays (plus a dot) and another which displays raw bitmaps instead, perfect for controlling an 8×8 LED matrix.

Multiple MAX72xx chips can be daisy-chained together to form larger displays as well.

Being a popular chip, a great deal has been written about the Max7219 and after you familiarize yourself with the datasheet, you should check out this article on the Arduino Playground and come back here when you’re done.

Connecting the MAX72xx to the netduino

Here are the hardware components that you’ll need:

  • 1 Max72xx chip
  • 1 monochrome LED matrix (for example)
  • 1 Logic-level shifter (DigiKey) (optional: see note below)
  • 1 10K resistor minimum
  • 1 100 uF capacitor
  • 1 0.1 uF ceramic capacitor
  • many hookup wires (as short as possible)

Note: The MAX72xx requires 3.5 volt logic levels minimum and because the netduino uses 3.3 volt logic level on its digital output pins, you may need to place a logic-level shifter between the netduino SPI interface and the Max72xx SPI interface. Check out this article if you’re not sure how this works.

While the Max72xx SPI clock can go up to 10 MHz based,  I was unable to get stable communications above 2 MHz when using the MAX7219 with a logic-level shifter. Without the shifter, SPI @ 10 MHz works flawlessly but because this is out of the chip’s specifications, so your mileage may vary.

The following summarizes the connections. It doesn’t matter which pins you choose on the logic-level shifter provided that they’re matching low-level input/high-level output pins.

  • SPI CLK: netduino pin 13 -> Logic-level shifter -> Max72xx pin 13 (CLK)
  • SPI MOSI: netduino pin 11 -> Logic-level shifter -> Max72xx pin 1 (DIN)
  • SPI CS: netduino pin 10 -> Logic-level shifter -> Max72xx pin 12 (LOAD/CS)

Note: the MAX72xx is extremely sensitive to EMI and power fluctuations. So, be sure to:

  • Place the capacitors as close as possible to the V+ and GND pins of the chip
  • Connect both GND pins to ground
  • Use the shortest possible hookup wires

If EMI is an issue, reducing the speed for the SPI bus and/or using shorter hookup wires may help. If you still have EMI issues, the MAX7221 is likely the right alternative.

Connecting the Max72xx to the LED matrix

The LED matrix that I’m using is wired like this:

LED matrix

Connecting it to the MAX72xx is straight forward:

  • The MAX72xx’s SEG pins correspond to the columns of the LED matrix
  • The MAX72xx’s DIG pins correspond to the rows on the LED matrix

Max72xx -> LED matrix Wiring

Using the netduino.helpers Max72xx C# driver

The C# driver attempts to stick to the Max72xx datasheet as closely as possible. It presents properties matching the various registers of the chip and a simple overloaded ‘Display’ method. Be sure to check out the unit tests in the /Samples for usage details.

Max72xx C# Interface

Action shot

Happy hacking!

-Fabien.

Driving an AdaFruit SSD1306 OLED display with a netduino [reloaded]

neduino ssd1306 driver

I ported adapted the Arduino driver written by Limor Fried for the SSD1306 monochrome OLED display to the netduino last week back in January.

At the time, I could not figure out why I was unable to communicate with the display over hardware SPI and had resorted to bit banging data, which was quite slow as you can see:

Last night, I revisited the driver and figured out the issue I had in January. I overhauled the code which now works properly @ 40 MHz using hardware SPI.

Here’s a video of the new driver in action:

Connecting the display to the netduino

SSD1306 VDD ->netduino 3.3 volts power

SSD1306 VBAT ->netduino 3.3 volts power

SSD1306 CS -> netduino D10 (or other Dx pin)

SSD1306 RESET -> netduino D9 (or other Dx pin)

SSD1306 D/C -> netduino D8 (or other Dx pin)

SSD1306 CLK -> netduino D13

SSD1306 DAT -> netduino D11

The driver and the sample code is located at http://netduinohelpers.codeplex.com/

Happy hacking!

Post edited on June 1st 2011.

Connecting an analog joystick to a netduino


Atari Joystick by Derek Erdman

The netduino project that I’m currently working on requires an analog thumb joystick for user input. Such parts can be scavenged from game console controllers (PS/2 or Xbox 360 for instance)  or can be bought from Sparkfun and Ada Fruit among others.

The joystick that I used in this article is Sparkfun’s and the datasheet for it is located here.

This 2-axis analog joystick is composed of two 10K potentiometers and features a push-button. Sounds like a piece of cake to work with, right? Well, it is but the devil is in the details as usual: each potentiometer is spring-loaded so that the joystick can return to the center when released.

If the springs aren’t perfectly balanced or with wear and tear, they will cause constant fluctuations in the readings even when the joystick is at rest. Even worse, the joystick might start drifting in one direction all the time!

For that reason, it’s important to calibrate an analog joystick at least once before using it so that the driver reading the potentiometer can compensate for the fluctuations.

The AnalogJoystick netduino driver that I wrote (see the links at the bottom of the post) does this automatically when an analog joystick instance is created by taking a bunch of sample readings and tracking the min / max values of the fluctuations, later using these are the ‘center’ area of the joystick. The caveat here is that the joystick must not be touched during that process. Fortunately, it only takes a fraction of a second to perform this calibration.

Connecting the joystick to the netduino

  • We’ll need to connect the potentiometer of the joystick to the analog pins on the netduino. I used the 3.3 volt power rail. Using analog pins first requires connecting the AREF pin of the netduino to the 3.3 volt power rail. Using the 5 volt power rail would work too, as long as the joystick and AREF are connected in a voltage divider configuration (v3.3 is the max on the netduino’s analog pins).
  • Designate one of the potentiometer as the X axis and the other as the Y axis. It does not matter which one is which.
  • Designate an analog pin on the netduino for the X axis (say GPIO_PIN_A0) and another one for the Y axis (say GPIO_PIN_A1).

Notice in the schematics that each potentiometer has 3 pins:

Connect them as follows:

  • Pot. pin # 1: netduino GND rail
  • Pot. pin #2: a netduino analog pin (GPIO_PIN_A0 / GPIO_PIN_A1 in this example)
  • Pot. pin #3: netduino v3.3 power rail

The switch can be connected to any given digital pin on the netduino. Lady Ada has a fantastic tutorial on how to do it properly so I won’t elaborate on the subject 🙂

The only thing that I will mention here is that I wrote an interrupt-driven  PushButton driver which will call back a user-defined method when needed, which is way more efficient than polling the digital input.

That’s it!

Action shot

You can see a video of the analog joystick used for moving a sprite on an LED matrix, building upon my previous posts discussing connecting an SD card to a netduino and driving an 8×8 LED matrix using persistence of vision:

Netduino analog joystick driver and test code

The analog joystick test code can be downloaded here.

Happy hacking!

The Atari Joystick artwork was used with permission from Derek Erdman. Thanks man! 🙂