chipKIT® Development Platform

Inspired by Arduino™

U8glib: Graphics Lib for LCDs and OLEDs

Created Tue, 02 Oct 2012 20:17:18 +0000 by olikraus

olikraus

Tue, 02 Oct 2012 20:17:18 +0000

Hello All

The Ardunio graphics library U8glib for monochrome and graylevel displays now also supports the ChipKit environment. [url]http://code.google.com/p/u8glib/[/url]

U8glib is intended to replace my old dogm128 library.

  • U8glib supports much more displays with lot of different controllers
  • U8glib includes much more and much bigger fonts
  • U8glib has more graphics primitives

Limitations to the PIC32/ChipKit port: All EA displays are working (so U8glib can replace the dogm128 lib), but i was not yet able to make ChipKit work with my OLEDs. Maybe this is due to the different logic levels of the ChipKit board. Until now i did not had time to figure out the problem.

Feedback is always wellcome.

Oliver

helpme

Sun, 16 Dec 2012 19:58:50 +0000

I moved from the Arduino Uno R3 to the ChipKit Uno32, U8g library using SPI with 128x64 LCD using ST7920 controller working fine in Arduino, no response at all on ChipKit. ST7920 Operation voltage 2.7V to 5.5V. I checked and rechecked the electrical connections, so I do not suspect them.

Thanks in advance,

Fred

olikraus

Wed, 19 Dec 2012 06:38:04 +0000

Hi

Can you post the code or example, which is not working? Which version of u8glib do you use?

Oliver

helpme

Thu, 20 Dec 2012 03:48:29 +0000

greetings Oliver,

I extended the menu example on the Arduino UNO R3 until I started running out of memory. On the Arduino everything seems to work as expected. On the ChipKit UNO32 the display turns on, i.e. backlight, but nothing else. I tried using pin 13, the LED attached pin, for each of the signalling line and the LED flickered as expected, but nothing on the display.

I just tried this using the HelloWorld example and same effect. The only change to the sketch is uncommenting the constructor. U8GLIB_ST7920_128X64 u8g(2,7,6, U8G_PIN_NONE);

The version of U8glib is 1.08

Would you happen to have a simple sketch that just tests the connection and reports the success / failure?

Thanks,

Fred

olikraus

Fri, 21 Dec 2012 18:18:07 +0000

Hi Fred

You are right. There was a bug (indeed two bugs) with the ST7920 low level driver. It is now fixed in the attached version (pre17). Here is a picture of my prototyping environment, where the ChipKit Uno32 drives the NHD ST7920 Display.

Can you please confirm, that the attached version works with your setup? Thanks a lot.

Oliver

helpme

Sat, 22 Dec 2012 03:21:22 +0000

Greetings Oliver,

Nope, still no reaction from the LCD display.

Is there anything that needs to be changed on the ST7920/LCD to indicated that 3.3V is being used instead of 5V. I do not see anything in the data sheet.

I get the impression from reading the data sheet that in serial mode there is not any feedback, i.e., the ChipKit has no way to tell if the ST7930/LCD is actually there.

Thanks for the help,

Fred

olikraus

Sat, 22 Dec 2012 08:02:50 +0000

Hi

Here is my setup: The display module is powered from 5V Digital pins are directly connected to the ChipKit Module Only SCK, MOSI and CS are connected. Indeed information only goes from the ChipKit Board to the display U8glib does not know which display is connected. There is no feedback.

Are you able to measure activity at your pins?

Oliver

olikraus

Sat, 22 Dec 2012 13:09:39 +0000

I did a download of the attached u8glib release from above. I can confirm that the attached u8glib release works with pins 2 to 11 and 13 (including your pins).

Maybe you can post a picture of your setup.

@Admins: I do not receive e-mails for this thread

Oliver

helpme

Sat, 22 Dec 2012 23:46:38 +0000

Thanks Oliver,

Your second to last post provided the last key nugget of information. It works with a 5V power supply and 3.3V logic.
When I tested your updates the first time I used a 3.3V supply. I poured over the ST7920 data sheet and did not see anything suggesting that 5V power supply is a requirement.

A side question: What are your thoughts on implementing the DISPLAY ON/OFF command, ST7920 Display Control instruction? For my application, more than 90% of the time no one will be looking at the display, albeit the rest of the functionality will function.

Thanks again,

Fred

olikraus

Sun, 23 Dec 2012 06:49:47 +0000

Hi Fred

Glad to hear that you display now works.

Currently there are no plans to implement DISPLAY ON/OFF commands in u8glib. In the past this has been discussed sometimes with the following result: Backlight is a major current source, so usually one would like to switch off the backlight also. So ideas include to use a power mosfet between 5V and the power-supply pin of the display module. The gate of the mosfet is controlled by the controller: The display module can be completly disconnected from the power supply. This method usually seems to be prefered over the DISPLAY OFF command.

But having a DISPLAY OFF command is anyway a nice idea. If you think, that this is usefull for you, feel free to add an enhancement request on the u8glib google page.

Oliver

helpme

Sat, 29 Dec 2012 02:58:09 +0000

Greetings Oliver,

It seems as though I might have found a bug, with I2C enabled the u8g.firstPage method hangs.

With the JP6 and JP8 jumpers set to use pins A4 and A5 as analog pins, everything works fine except the external RTC, (not surprising since it uses I2C on A4/A5).

Just after changing JP6 and JP8 to indicate that A4 and A5 should be used for I2C and reapplying power the display and the external RTC seem to work fine until I use the joystick, (analog pins A1,A2,A3), to set the time on the external RTC. Upon setting the time on the RTC the updates to the LCD are garbled. After doing any/all the following, (reset,redownloading,removing and returning power), will not get the LCD to display anything. The strategically placed Serial.println calls have narrowed the culprit to the first u8g.firstPage method call never returning. Now after changing JP6 and JP8 to indicate pins A4 and A5 should be used as analog pins and reapplying power, everything works fine again except the external RTC.
As there is no algorithmic dependance on the time value in my code, (i.e., loop counters, array indexes, etc), I do not suspect that. Besides the code that deals with the time value does not get invoked due to the firstPage hanging.

Any ideas?

Thanks in advance,

Fred

olikraus

Sun, 30 Dec 2012 08:45:36 +0000

Hi Fred

Unfortunately , I2C is not supported on the ChipKit Board. See also here: [url]http://code.google.com/p/u8glib/wiki/device[/url]

Oliver

helpme

Sun, 30 Dec 2012 17:12:27 +0000

Oliver,

Sorry that I was not explicit, as this was a continuation of the previous posts, but ... The device LCD device being used is: U8GLIB_ST7920_128X64 u8g(2, 7, 6, U8G_PIN_NONE,5); and is supported and working when either (pins A4/A5 are assigned to analog pins and either read or write I2C to the RTC is performed) or (pins A4/A5 are assigned to I2C and not using I2C for setting the time in the external RTC).

Once I2C is used to set the time on the external RTC (with pins A4/A5 assigned to I2C) the use of the LCD gets corrupted. As far as I can tell these two functionalities should be completely separate.

What conditions would cause firstPage to hang? Is it waiting for hardware to respond?

Thanks,

Fred

olikraus

Sun, 30 Dec 2012 18:04:33 +0000

Hi Fred

Ok, you use the GLCD (SW SPI) with an RTC (I2C). What i understood from you posts: No lines are shared. I fully agree, the RTC should not influence the GLCD. But i have no idea why this might happen. Maybe a software issue.

Oliver

Pogij

Fri, 03 Oct 2014 21:00:17 +0000

Hi

I'm just wondering, does anybody else have the problem with u8glib on newest stable version of mpide (release 20140821)? Version 20140316 works fine but when I try to compile project with the newest version it just prints errors:

mpide-0023-linux64-20140821/hardware/pic32/compiler/pic32-tools/bin/../lib/gcc/pic32mx/4.5.2/../../../../pic32mx/bin/ld: address 0xa0006fcc of MasterProject.cpp.elf section .sbss' is not within region kseg1_data_mem' mpide-0023-linux64-20140821/hardware/pic32/compiler/pic32-tools/bin/../lib/gcc/pic32mx/4.5.2/../../../../pic32mx/bin/ld: MasterProject.cpp.elf section .bss' will not fit in region kseg1_data_mem' mpide-0023-linux64-20140821/hardware/pic32/compiler/pic32-tools/bin/../lib/gcc/pic32mx/4.5.2/../../../../pic32mx/bin/ld: address 0xa0006fcc of MasterProject.cpp.elf section .sbss' is not within region kseg1_data_mem' mpide-0023-linux64-20140821/hardware/pic32/compiler/pic32-tools/bin/../lib/gcc/pic32mx/4.5.2/crtbegin.o: Link Error: Could not allocate section .sdata, size = 4 bytes, attributes = data near keep

And those errors are followed by series of link errors.

Thanks

majenko

Fri, 03 Oct 2014 21:22:33 +0000

They are saying you have run out of memory.

Pogij

Thu, 09 Oct 2014 16:20:44 +0000

Ok. So is there any way I can fix that?

majenko

Thu, 09 Oct 2014 20:29:49 +0000

Don't use as much memory? Without seeing your code it's impossible to know how much memory you're using.

Do you have any big arrays in your code?

guymc

Fri, 10 Oct 2014 20:20:40 +0000

Here is one way to understand your memory usage:

Get back to a situation where the link succeeds, such as by removing one large array. Doesn't really matter if that action breaks functionality, you're just collecting data at this point. Once you have a successful link, you can examine the map file to get a detailed look at how much memory is used by the various data structures. Then you can see exactly how memory is being allocated, and look for somewhere to trim. This could be an iterative process, while you try a few things to see what will work best.

Unfortunately, MPIDE does not currently generate a link map file by default. (Will be addressed in the next release, most likely.) In the meantime, you can enable map files like this:

  1. Open the file platforms.txt, found here: <mpide install dir>/hardware/pic32/

  2. Find the line (near the top) that looks like this:

pic32.recipe.c.combine.pattern={0}{1}::{2}::{3}{4}::-o::{5}{6}.elf::{7}::{8}::-L{9}::-lm::-T::{10}/{11}::-T{12}/{13}

  1. Append the linker option to create a map file (::-Wl,-M="Sketch.map"):

pic32.recipe.c.combine.pattern={0}{1}::{2}::{3}{4}::-o::{5}{6}.elf::{7}::{8}::-L{9}::-lm::-T::{10}/{11}::-T{12}/{13}::-Wl,-M="Sketch.map"

This will cause a link map file to be created on every build, and deposited in the same directory as the MPIDE executable. You will probably have to quite MPIDE and re-start for this change to take effect.

If you're not familiar with link map files, expect to spend some time learning about them. The pic32 toolchain in MPIDE uses the GNU linker, so you could do a web search for some help. For example, you could look in chapter 8.4.5 of this document:

http://ww1.microchip.com/downloads/en/DeviceDoc/51833A.pdf

Hope this helps!

Pogij

Sat, 11 Oct 2014 19:23:28 +0000

Well compiling fails even in very simple programs like this:

#include <U8glib.h>

U8GLIB_KS0108_128 u8g(26, 27, 28, 29, 30, 31, 32, 33, 39, 35, 34, 37, 36);

void setup() { if (u8g.getMode() == U8G_MODE_R3G3B2) { u8g.setColorIndex(255); // white } else if (u8g.getMode() == U8G_MODE_GRAY2BIT) { u8g.setColorIndex(3); // max intensity } else if ( u8g.getMode() == U8G_MODE_BW ) { u8g.setColorIndex(1); // pixel on } }

void draw(void) {
u8g.setFont(u8g_font_helvR08); u8g.drawLine( 0, 49, 128, 49); u8g.drawStr( 4, 60, "Test"); u8g.drawLine(0, 33, 128, 33); }

void loop() { u8g.firstPage(); do { draw(); } while(u8g.nextPage()); }

Thanks guymc. Will try that.

larams67

Fri, 17 Oct 2014 18:31:39 +0000

I also get numerous errors when trying to compile. I've tried all kinds of solutions and scoured the net for answers but found nothing so far.

Here is a small sample of the errors. I get a whole page worth.

[color=#FF8000]F:/AAA/Chipkit/mpide-0023-windows-20140821/hardware/pic32/compiler/pic32-tools/bin/../lib/gcc/pic32mx/4.5.2/../../../../pic32mx/bin/ld.exe: address 0xa0006a4c of HelloWorld.cpp.elf section .sbss' is not within region kseg1_data_mem' F:/AAA/Chipkit/mpide-0023-windows-20140821/hardware/pic32/compiler/pic32-tools/bin/../lib/gcc/pic32mx/4.5.2/../../../../pic32mx/bin/ld.exe: HelloWorld.cpp.elf section .bss' will not fit in region kseg1_data_mem' F:/AAA/Chipkit/mpide-0023-windows-20140821/hardware/pic32/compiler/pic32-tools/bin/../lib/gcc/pic32mx/4.5.2/../../../../pic32mx/bin/ld.exe: address 0xa0006a4c of HelloWorld.cpp.elf section .sbss' is not within region kseg1_data_mem' F:/AAA/Chipkit/mpide-0023-windows-20140821/hardware/pic32/compiler/pic32-tools/bin/../lib/gcc/pic32mx/4.5.2\crtbegin.o: Link Error: Could not allocate section .sdata, size = 4 bytes, attributes = data near keep U8glib\utility\u8g_dev_ssd1351_128x128.c.o: Link Error: Could not allocate section .bss.u8g_dev_ssd1351_128x128_4x_byte_buf.u8g_dev_ssd1351_128x128_4x_byte_buf, size = 4096 bytes, attributes = bss lib_a-impure.o: Link Error: Could not allocate section .data.impure_data.impure_data, size = 1048 bytes, attributes = data lib_a-mallocr.o: Link Error: Could not allocate section .data._malloc_av._malloc_av, size = 1032 bytes, attributes = data WSystem.c.o: Link Error: Could not allocate section .sdata._isr_primary_install._isr_primary_install, size = 180 bytes, attributes = data keep lib_a-mallocr.o: Link Error: Could not allocate section .bss.__malloc_current_mallinfo.__malloc_current_mallinfo, size = 40 bytes, attributes = bss F:/AAA/Chipkit/mpide-0023-windows-20140821/hardware/pic32/compiler/pic32-tools/bin/../lib/gcc/pic32mx/4.5.2\crtbegin.o: Link Error: Could not allocate section .bss, size = 32 bytes, attributes = bss wiring.c.o: Link Error: Could not allocate section .sdata.gCoreTimerInfo.gCoreTimerInfo, size = 24 bytes, attributes = data keep sbrk.o: Link Error: Could not allocate section .bss.mem.1180.mem, size = 24 bytes, attributes = bss U8glib\utility\chessengine.c.o: Link Error: Could not allocate section .sdata.mnu_list.mnu_list, size = 16 bytes, attributes = data keep [/color]

GastonLagaffe

Mon, 17 Nov 2014 15:13:17 +0000

Salut, I get the same error with the linker - any hope this can be fixed?

Ciao, Mathias

GastonLagaffe

Wed, 19 Nov 2014 09:10:56 +0000

Salut,

any improvements here? I get the same error in the linker when I compile the demo sketch using MPIDE. Using UECIDE, the sketch compiles, so it is not a software error.

Ciao, Mathias