U8glib: Graphics Lib for LCDs and OLEDs

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)

Using

u8g.setContrast(208);

works as it should and sets the contrast. But I have a few questions. From what I’ve read in the datasheet the contrast value is a 6 bit value. I’m guessing the range 0 – 255 is divided down to 0 – 63?

I’ve begun investigating bdf fonts using FontForge. I looks like converting a font then modifying / drawing the bitmap for the size I want might be the best method, but I don’t really understand how point size converts to pixel size. I think I have a lot to learn before I can produce a usable font.

Thanks again for all of your help and support.

works as it should and sets the contrast. But I have a few questions. From what I’ve read in the datasheet the contrast value is a 6 bit value. I’m guessing the range 0 – 255 is divided down to 0 – 63?

I try to keep a range from 0 to 255 for the user interface. I think the actual range is from 0 to 127. It is scaled down in line 106
http://code.google.com/p/u8glib/source/browse/csrc/u8g_dev_uc1701_mini12864.c

I’ve begun investigating bdf fonts using FontForge. I looks like converting a font then modifying / drawing the bitmap for the size I want might be the best method, but I don’t really understand how point size converts to pixel size. I think I have a lot to learn before I can produce a usable font.

The SIZE parameter () of the BDF format defines the PointSize and Resolution of the BDF font. It is ignored by the bdf to u8g converter. The bitmaps are extracted and converted to the internal u8g format without any additional transformation.

Oliver

has anyone ever made a USABLE number font in the size range from 25-30 pixels of height?

all fonts in u8glib in that range have different heights for the numbers 0-9, they are never aligned in height
and the format only has a windows converter which is quite inconvenient -.-

Made some pics of the problem:

the one and five sit one line lower than 3 and 0

the one is one line lower -.-

and here the 7 is one line less high than the 3s and 0

Hi DooMMaster,

I encountered the same issues as you but when I understood a little more about fonts and the conversion process I found this is (in most computer applications) the norm. Fixed width fonts (and perhaps height) don't typically reach a large size. I wanted fixed width and height so I converted and modified my own. It's about 30 pixels high and from memory 28 pixels wide and only includes numbers. My application was for a GPS clock.

Here's a link to a photo with the font: U8glib Custom Fonts GPS Clock | I used FontForge, Fony and b… | Flickr

When I have access to the code I'll update it and paste it here.

For the discussed number fonts, i have used the following conversion process:

  1. Convert (scale+raster) truetype font into a bdf font. Result is a .bdf file. Tool: otf2bdf
  2. Convert .bdf file to a .c file (internal u8glib format). Tool: bdf2u8g

Misalignment already appears in step 1. To fix this, either add information to the original .ttf file or update/fix the intermediate .bdf file. I am always happy to update, fix or add fonts. Just send me the related .bdf or .ttf files.

I have made all bdf file available here:
http://code.google.com/p/u8glib/source/browse/#hg%2Ftools%2Ffont%2Fbuild
So one solution is to download the bdf file and modify this bdf file with some of the existing bdf editors.

Once i receive a bdf (prefered) or ttf, i can offer:

  • Update the release process for u8glib with the new bdf file
  • replace/add the bdf for future releases
  • setup a wiki page with updated or modified bdf files
  • optional: give credits to the contributor

For sure, helping hands are needed here. I know that the converted fonts are not that good. As of now, i do not have anything else.

Thanks in advance,
Oliver

ok… got SERIOUSLY annoyed by the problem :stuck_out_tongue: so I took the fub25 and fixed all the numbers…

It would be nice if you could make them u8glib compatible in format and create a "numbers" version frim it, or at least a restricted.

All Numbers are now aligned on line -1 and have exactly 26 pixels in height… so 25 is the upper line… it is not pretty but a lot pretier than before.

http://uschok.de/~doommaster/fub25.bdf

I will create a Numbers only font now… custom… and simple and clean :slight_smile: will post the file here once it is done

EDIT:
I have also made a numeric font on my own… simple and clean… all numerics are monospaced
http://uschok.de/~doommaster/freedoomr25n.bdf

Feel free to do whatever you want with it… this font is Free in all human and lawful senses.

Many thanks to DooMMasteR for the contributed fixes and the new font.

The font update applies to this font:
http://code.google.com/p/u8glib/wiki/fontgroupfreeuniversal

The new font is described here:
http://code.google.com/p/u8glib/wiki/fontgroupcontributed

I have also added some more fonts from the X11 distribution. Some nice large bitmap fonts are also included:
http://code.google.com/p/u8glib/wiki/fontgroupadobex11

I have attached u8glib version v1.09pre14, which includes all these fonts.

Oliver

u8glib_arduino_v1.09pre14.zip (952 KB)

nice :slight_smile: thx a lot

I will also make another font… in 10px height…maybe even today

EDIT: done
numerics, capitals, degree, math included… 10px high 7-8 wide
http://uschok.de/~doommaster/freedoomr10r.bdf

I'm really stoked you guys are doing this! I took a look and was a little intimidated by the process of making my own font and converting it, as I know almost nothing about fonts. (Also FontForge crashes on my computer.)

Thank you!