The LCD12864.h library.. anyone got it working on teensy?

Not open for further replies.



I am curious if anyone has gotten this display to work on the teensy?

As far as I can understand, I should be able to use the lcd125864.h to communicate with it, and everything goes swell (no compiling errors etc), but the display only powers backlight and nothing comes on screen (so nothing is getting through)..

I am trying to run it on ++2.0 on the following pins:

static const byte RS = 9;
static const byte RW = 8;
static const byte EN = 5;
static const byte D0 = 10;
static const byte D1 = 11;
static const byte D2 = 12;
static const byte D3 = 13;
static const byte D4 = 14;
static const byte D5 = 15;
static const byte D6 = 16;
static const byte D7 = 17;
static const byte CSEL1 = 19;

I just edited these numbers in the .h file from the library (guess that should be allright?).

The main code is this:

#include <LCD12864.h>
#include <LCDSprite.h>

void setup(){

void loop(){
LCDA.RenderScreenBuffer(2); // lets draw it in the second screen

This code is ment for Arduino, but I guess it should work on the teensy as well ?

Anybody see what I am doing wrong?

Sorry for newbee question :p

The code certainly looks like it ought to work.

If you post a clear photo of your wiring, I'll look to see if anything is obviously wrong.
Here's one other thing to try. It's a long shot, but maybe this code depends on the slowness of Arduino's digitalWrite(). I'm not sure. Bill Perry is really the expert on such matters with these displays. Maybe he'll notice this thread and comment?

You could also use Bill's GLCDv3 or OpenGLCD libraries, which will perform much better.

Teensy has optimized digitalWrite when the inputs are compile-time constants. This library calls a setPins() function. If the compiler doesn't inline, and I suspect it probably won't, this library will probably be terribly slow on any board. But if the compiler is using an inline optimization on that function, then Teensy's digitalWrite optimization might also get used, which could make this library run dramatically faster than the original author intended. I do not believe that will happen, so this idea is something of a long shot.

To absolutely defeat the optimization and give this library really slow performance, you could change the pin definitions from "static const" to "volatile". Like this:

volatile byte RS = 17;
volatile byte RW = 16;
volatile byte EN = 18;
volatile byte D0  = 8;
volatile byte D1  = 9;
volatile byte D2  = 10;
volatile byte D3  = 11;
volatile byte D4  = 4;
volatile byte D5  = 5;
volatile byte D6  = 6;
volatile byte D7  = 7;
volatile byte CSEL1  = 14;

I do not believe this will make any difference (other than make the library run very, very slow when it does work). But if you run out of things to try, it might be worth a quick try.
My thoughts excactly, so..

I've been over the wiring 3 times (Einstein would've been mad), headers soldering x2, the wires themselves (checked for resistance and threw away anything even popping resistance for a ms during connecting :p), i even checked each pin on the teensy (!) even though I allready knew it worked.. The pins are labeled on the backside of the display so there can't be any miss-wiring due to confusion either. :\ Would have been nice to find it being something like that :)

I will keep going from the information above, and come back here after some more testing..
btw; Is it so that the glcd library should work on this lcd?! (if so i could use that to test the display?)

Besides that, anyone got any code to test a displays functions separately? Or ideas on how to do this..
Last edited:
Oh, opps, looks like GLCD doesn't support it. But u8glib might....

I will check that out very soon (good to hear glcd don't work, because I allready tried it, hehe)!

Thanks a bunch for fast respons and taking the time, Paul, I can be a bit exhilarated doing things like this, and forget to show appreciation :) Much obliged! ;D

Still no luck, with any libraries or suggestions above.

I will come back to this project in a few days, but now I got two new teensy's in the mail, so you have to forgive me, but I have to get header pins on them and test it out a bit (my first 3.1). The other is a 2.0 I am gonna use for a organ pedal midi board I promised some friends, so that has first priority right now :) I will use both USB MIDI and MIDI and also attach a IR receiver to map to midi.

The code is testet and finished, so basically just the finish and mounting left. I have ordered a couple of other displays as well, so this project will not be left dead ;) Be back soon!
I just realized that I have taken for granted that RS (register select) = D/I since that was the only label on my display not being corresponding to wiring details and D/I did not appear on the display pin-out and visa versa, hence I just came to accept this RS = D/I statement to be true..

Also there are some other minor differences, BLK = K, BLA = A, CSA = CS1 etc, but this must be obvious, right?

Could someone please confirm this to me? :)

Not open for further replies.