U8glib: Graphics Lib for LCDs and OLEDs

Thanks so much for your help, Oliver. I wouldn't expect my shield to be available until after December 2012, so no rush on a release.

I used the constructor as "U8GLIB_NHD_C12864 u8g(13, 11, 10, 9, 8);" and connected the LCD reset pin to Arduino pin 8. Works just fine, but I will use the circuit you mention.

rdeweerd:
I'm using the library for the DFRobot ST7920 128 X 64 LCD and it works without a problem, both in serial as in parallel mode. But the weird thing is, is that the parallel mode is a bit slower. In SW serial I got a refresh rate of 6 to 7 frames per sec and in 8bit it goes down to 4 to 5.

Is this normal behavior or am I doing something wrong?

I have improved speed for the parallel mode by 30%. This fix will be available with the next regular release. Please send PM for a beta release including this fix.

Oliver

Hello,

I'm using u8glib for an LCD screen I pulled out of an old Dell LTO tape backup library. It turned out to be a LC7981 chipset at 240x128. I was able to modify the library files for the screen, based on some other mods I found already in the files and all is well. (U8GLIB_LC7981_240X128)

I have a question about fonts - I'd like to create my own font, both for a custom look and to save some memory by omitting characters I know I won't need. Can you post some info for how to create/add custom fonts? I've been looking at u8g_font_data.c and it looks like they're just a big bitmap with some parameters indicating the boundaries of each character, but I can't seem to get my head around the array structure.

It will soon be a super deluxe HVAC controller:

Thanks!

Hi

Nice work. Glad to see that u8glib is usefull for you.

The U8glib font format not only contains the bitmat data but also a lot of glyph information for precise font rendering (mainly used for my other lib m2tklib). Some information available in the fonts are described here: Google Code Archive - Long-term storage for Google Code Project Hosting..
The U8glib font format also tries to crop the bitmap data to save as much ROM as possible. All the glyph metric calculation, the bitmap reduction and the font encoding is done by an external program: Google Code Archive - Long-term storage for Google Code Project Hosting.. Simply compile the c-file with a unix or windows c-compiler (or send me a PM if you need the executable).

bdf2u8g requires a font in the bdf format: Glyph Bitmap Distribution Format - Wikipedia

On the internet several fonts are available as bdf files, see for example here: freedesktop.org git repository browser

But it is also possible to convert truetype fonts (ttf) to bdf: I have used http://sofia.nmsu.edu/~mleisher/Software/otf2bdf/ and http://fontforge.org/. I am sure there are more tools (google has some 100.000 hits for "ttf bdf").

Oliver

Cool, thanks! I'll see if I can get anywhere with this. I have little knowledge of how fonts work, so this may be more than I have patience to do. :wink:

U8glib is a really nice library, BTW - pretty easy to use and modify. I was a little intimidated at first, but dug into the files and figured out how to create a new constructor. I have two other LCDs I've pulled out of old equipment that I'm going to try and get working. One is a little 5 x 2 character out of a Dell server (it's the little status/diag LCD). I haven't figured out what chip is on it yet. The other came from a Quantum tape library and I believe is a ST7565 128 x 64 chip-on-glass type. Both have ribbon cables so I need to get breakout boards to use them.

Anyway, thanks for your help and the LCD library!

Thank you Oliver for your wonderfull work!

I tested the DFRobot st7920 witch has an spi module attatched to take care of contrast etc. and it works fine in arduino environment.
I would like to use it in pure C but the constructor requires an A0 connection,while the arduino library does not.

How could i resolve this?

Thanks again!

Hi

The st7920 does not require an A0 line. Instead it has a very special low level protocol. Unfortunately i have not yet ported the Arduino version of the low level driver: Google Code Archive - Long-term storage for Google Code Project Hosting.

I have put this as issue 85 on the u8glib issue list.

Thanks, Oliver

Thanks for the reply..
Ill will use the arduino library then,no problem!

Hi

I have added support for the st7920 with avr to u8glib:

The test environment includes my NHD 192x32 display with ST7920 controller (upper right, the bright light from upper left makes the contrast a little bit weak). Lower left is an unused EA 132x32 display. Lower right the ATMEGA 328 with green power LED. Upper left the AVR programmer.

A beta release with support for st7920 for avr is avilable on request.

Oliver

Hi

I have released version 1.08 of u8glib. The new release has been optimized for speed and includes support for some more OLED chips. See details here: Google Code Archive - Long-term storage for Google Code Project Hosting..

This release also has a new COM interface for I2C/TWI based displays. The first supported I2C display is the Seeedstudio 96x96 OLED.

Thanks to all testers of the beta releases!

Oliver

Oliver,
I've looked but can't seem to locate any information on the bitmap pixel format.
i.e. things like is it LSB to MSB, 8 bit vs 16 bit, vertical vs horizontal encoding etc...
Is it universal in that it works on any glcd or is the bitmap format just a raw image
for the given glcd so each glcd has a different pixel format?
Have I missed this somewhere?

--- bill

Hi Bill

The drawBitmap procedure expects a byte array, which is printed from left to right, MSB on the left. The drawXBM also expects a fixed format, but i can't remember the bit orientation.

The fact that each display might have a different byte orientations forces U8glib to perform a bitmap translation step from the high level command to the native display byte orientation. Indeed this is one of the most time consuming steps in U8glib. Unfortunately i do not know how to avoid this. There is not common memory layout for the displays. Each chip has an individual memory setup. Everytime I add a new chip, I am surprised to see another new memory layout :roll_eyes:

Because i anyway had to add such a bitmap translation, it was not a big task to add the 90 degree rotation for the display orientation. Indeed this is something what i got almost for free (with respect to computation time): I just had to exchange the bitmap translation procedures, when such a different display orientation is requested.

For one of the newly added OLEDs I had to implement a completly new memory layout:

  • I noticed that the new memory layout reduces speed (of course only for this display)
  • So i decided to work on an overall speed optimization.
  • All of the u8glib code was ported to my desktop so that i can apply "gprof" to it.
  • I did a lot of gprof tests with the code to identify those procedures where most of the computation time is lost
  • This all lead to several improvements, including one, where i had to restructure parts of the high level/low
    level communication.
  • Depending on the high level comands, speed is now improved by up to 30%, but still, GLCD is much faster.
  • After spending many many hours on speed and performance analysis this summer, i know that there is not much room for further improvements.

U8glib offers flexibility and trades this for speed.

The good news is, that u8glib still is faster than many existing libraries (except GLCD). :wink:

Oliver

First off the U8glib is fantastic. I’ve used it successfully with several displays. For me with my limited programming skills this library just lets me use displays and get on with my projects. Thank you Oliver.

On to my problem, I have a new LCD module with a UC1701 controller in it that I’m struggling to make work properly with U8glib. Looking at the “Supported Devices” table it’s not supported, but from my testing it almost is because it uses a UC1701 controller. Here’s what little I know about it:

Labelled: “Open Jumper, 12864”
Size: 47 x 38 x 4mm
Supply Voltage: VCC 4.5 to 5.5V (built-in booster circuit, no negative voltage required)
Controller: UC1701, Based on: 12864
Display: 128x64
Interface: SPI

Deal Extreme link to product I purchased.
Mini12864 Blue Backlight Dots Graphic LCD Display Module - Red - Free shipping - DealExtreme"

I’m using Ardunio v1.0.1 IDE, Arduino Uno R3 and U8glib v1.08 with the U8gLogo example sketch, I’ve added two lines:

u8g.setContrast(0);  // in the setup
u8g.drawFrame(0, 0, 127, 63); // in the picture loop, helps determine screen edges / locations

Here’s what I’ve tried:

U8GLIB_DOGS102 u8g(13, 11, 10, 9); // expects 102x64 display mine is 128x64

  • Image is about 5 pixels to the left, the right edge has random garbage pixels as expected due to 102 vs. 128 pixel width
  • As listed in the “Supported Devices” table no contrast adjustment, screen is barely visible almost impossible to photograph

U8GLIB_DOGM128 u8g(13, 11, 10, 9);

  • Again as listed in the “Supported Devices” table no contrast adjustment, screen is barely visible almost impossible to photograph
  • Image is again about 5 pixels to the left and the right edge has random garbage pixels
  • This is the closest I got the display to working

U8GLIB_DOGM132 u8g(13, 11, 10, 9); // expects 132x32 display some errors expected

  • Contrast works without fault (0 seems to be the best value for my display), “Supported Devices” table might need updating
  • Image is again about 5 pixels to the left but this time the right edge has no garbage pixels (perhaps something is cleared?)
  • Only the top half of the image is drawn, as expected due to 32 vs. 64 pixel height

Note: I had to power cycle the display between testing as it seems to retain the display memory from previous programs.

Here’s some photos of the display using U8GLIB_DOGM132:
Imgur

Would it be possible to support this device? I’m happy to perform any testing and provide photos for galleries (I’m a better photographer than programmer).

Corrections to version numbers made.

Hi

I am always happy to support new displays with u8glib.

This is my usual procedure for adding new devices:

  1. Select a u8glib device which almost works
  2. Rename this device to the new display
  3. Fix display problems (garbage, display shift etc)
    4 Fix contrast issues

What is your impression? Which u8glib device would be a good starting point for the "Mini12864"?

One of your pics shows a perfect u8glogo: Mini12864 Blue Backlight Dots Graphic LCD Display Module –… | Flickr
But you did not mention the u8glib device.

Additionally i wonder about the version number v12.
Official download is here: Google Code Archive - Long-term storage for Google Code Project Hosting.
Latest version of u8glib is 1.08

All in all, there are good pictures and existing u8glib devices mostly work, so it should not be a big problem
to fix issues with your display.

Oliver

I'm sorry I've stuffed up some of the information I've presented. I'm attempting to correct it now. v12 is very wrong sorry about that.

The older flickr photos were using v1.04 and "U8GLIB_DOGM128 u8g(13, 11, 10, 9);". I modified this to add contrast from another device (I think U8GLIB_DOGM132 but cannot remember). The photo of it working perfectly was after I messed around with the reset pin and resting the Arduino. It was not easily repeatable. Leaving me to believe perhaps timing was involved in the problem.

The current flickr photos use the newer v1.08 U8glib. It's my opinion the U8GLIB_DOGM132 device would be a good starting point as it has the contrast code and only two minor issues.

Hi

I have attached a version of u8glib with support for the MINI12864:

U8GLIB_MINI12864 u8g(13, 11, 10, 9);                    // SPI Com: SCK = 13, MOSI = 11, CS = 10, A0 = 9

It has been derived from the DOGM132 with adjusted dimensions.

Please let me know if this is ok or if some other adjustments are required.

Oliver

u8glib_arduino_v1.09pre8.zip (692 KB)

Thank you Oliver!

I will test this out and post photos of the result as soon as I can.

The device U8GLIB_MINI12864 is close. Thank you. The image is still shifted five pixels to the left, with the far right edge filled with garbage pixels. Contrast is set and works but seems to be fixed.

I’ve attempted to read the source code and the datasheets registers and I must admit I don’t understand what I’m looking at. For what it’s worth I think this is the datasheet for the controller http://www.lcd-module.de/eng/pdf/zubehoer/uc1701.pdf

However I did experiment with the u8g_dev_uc1701_mini12864.c file. I messed with this line

  0x0a1,		/* ADC set to reverse. Was a0 now a1 */

I found if I change this value from “a0” to “a1” the image is reversed but does not have pixels shifted.

I also played with this device:

U8GLIB_LM6059 u8g(13, 11, 10, 9);                    // SPI Com: SCK = 13, MOSI = 11, CS = 10, A0 = 9

It does not have contrast adjustment (image is almost impossible to view) and has the top and bottom of the image swapped, but again the pixels are not shifted.

I will post photos shortly.

More progress. It works as it should if I use:

Line 51:  0x0a0,		/* ADC set to reverse */
Line 52:  0x0c8,		/* common output mode */
Line 60:  0x027,          /* contrast value, EA default: 0x01f */

"c8" Flips the screen 180 and so far appears to work without fault. I'm guessing this is the proper or intended orientation. The contrast value just makes the screen a little easier to read. Note I also returned ADC to "a0".

I feel a little stupid. I’ve just re-read some of this the messages in this thread and I must have missed at least page 4. It’s the same typical types of issues. I feel I should have experimented more before asking for help.

Here's the photos:
Imgur
Imgur

It would be nice to be able to control the contrast within the main program but I'm unsure how to do this.

My next change is fonts like koyaanisqatsi posted. I’d like to be able to draw my own as bitmaps and then convert to fonts. I can draw fonts no problem (I have very small and very large fonts in mine for a specific project) but I’m lost on converting them. I need fixed height and widths and some only numbers.

Updated with more info

Hi

I have applied your setting to the attached pre-release. I also added code for contrast setting. Hopefully everything works as expected. Feedback would be great. Thanks for supporting u8glib so far (Karma given...).

Fonts: If your font is available as .ttf or .bdf, then a conversion is no problem. Tools like fontforge are able to export .bdf
The tool otf2bdf can convert ttf into bdf.
To convert bdf to the internal font format, you need bdf2u8g:
http://code.google.com/p/u8glib/source/browse/tools/font/bdf2u8g/bdf2u8g.c
It compiles on windows and unix.

Oliver

u8glib_arduino_v1.09pre9.zip (692 KB)