M2tklib / glcd splash screen

I’m trying to use an arduino to control the height of my workbench (I have it connected to a motor and can drive it up and down from a handheld remote). I have started to transition over to using a GLCD screen for user input so I can support more than one mode of operation. I’m using the M2tklib to drive menus for the users. As part of this, I thought it would be cool to display a splash screen on startup. So I went to the GLCD examples to see how they do that and tried to copy the way they did it. However, I keep getting section conflict error

here is a stripped down version of the code that produces the same error:

#include <glcd.h>		// inform Arduino IDE that we will use GLCD library
#include "M2tk.h"
#include "utility/m2ghglcd.h"
#include "bitmaps/allBitmaps.h"
#include "fonts/allFonts.h"    

// Fixed pins for IO
#define btnA_pin 8
#define btnB_pin 7
#define btnC_pin 4
#define btnD_pin 2
#define dir_pin 10
#define step_pin 13
#define enable_pin 11

// other constants
#define enable_on LOW
#define enable_off HIGH
#define btn_active LOW
#define btn_inactive HIGH
#define minFreq 50
#define absMaxFreq 2000
#define forward HIGH
#define reverse LOW
#define PULSE_ON_TIME 3000

// general variables
uint8_t uiKeySelectPin = btnB_pin;
uint8_t uiKeyDownPin = btnC_pin;
uint8_t uiKeyUpPin = btnA_pin;
uint8_t uiKeyExitPin = btnD_pin;

boolean btnA;
boolean btnB;
boolean btnC;
boolean btnD;

// Definitions of Main Menu
  M2_LABEL(el_label_MainMenu,NULL,"Main Menu");
  // Construct Various Buttons
  M2_BUTTON(el_manual,"f4","Manual Operation",fn_manual);
  M2_BUTTON(el_gotoHt,"f4","Goto Height",fn_gotoHeight);
  // Construct Main Menu List
  M2_LIST(list_main_menu) = {&el_label_MainMenu,&el_manual,&el_gotoHt,&el_settings};
  M2_ALIGN(el_main_menu, "W64H64", &el_list_main_menu);
M2tk m2(&el_main_menu, m2_es_arduino, m2_eh_4bd, m2_gh_glcd_ffs);

void fn_manual(m2_el_fnarg_p fnarg){}

void fn_gotoHeight(m2_el_fnarg_p fnarg){}

void fn_mainMenu(m2_el_fnarg_p fnarg){}

void fn_settings(m2_el_fnarg_p fnarg){}

void setup() {
  GLCD.Init();   // initialise the library
  GLCD.DrawBitmap(ArduinoIcon64x32, 32,0); //draw the bitmap at the given x,y position
  pinMode(step_pin, OUTPUT);
  pinMode(dir_pin, OUTPUT);
  m2.setPin(M2_KEY_SELECT, uiKeySelectPin);
  m2.setPin(M2_KEY_NEXT, uiKeyDownPin);
  m2.setPin(M2_KEY_PREV, uiKeyUpPin);
  m2.setPin(M2_KEY_EXIT, uiKeyExitPin);
void loop() {
  btnA = digitalRead(btnA_pin);
  btnB = digitalRead(btnB_pin);
  btnC = digitalRead(btnC_pin);
  btnD = digitalRead(btnD_pin);


the part where the code is bombing is in the setup function where it tries to read ArduinoIcon64x32. I have no idea how to fix it and cant figure out why it is erroring. Any help would be appreciated

What is the actual error message and how is ArduinoIcon64x32 defined? Is ArduinoIcon64x32 defined in the header file or is it just declared in the header. One solution could be to put the definition of ArduinoIcon64x32 into a .c file (NOT a c++ file!). Then just put the declaration into the .h file. This might work better.


The actual error is:

C:\Users\Dirk\Documents\Arduino\libraries\glcd/bitmaps/ArduinoIcon64x32.h:25: error: ArduinoIcon64x32 causes a section type conflict

ArduinoIcon64x32 is defined in ArduinoIcon64x32 .h It is part of the standard glcd library and it works in their example fine, but not in this. I think there is some conflict between the M2tklib library and the GLCD library. there isn’t a c or cpp file. the glcd library reads the image as a character array through PROGMEM

here’s the code:

//    A header datafile for glcd bitmap created with bmp2glcd by S.Varjo 
//    The glcd bitmap data contained in this file is in a format
//    suitable for use by the Arduino GLCD lib.
//    It contains embedded width and height format information.
//    Ardino bitmap format support added by Bill Perry
//           (bperrybap@opensource.billsworld.billandterrie.com)
// 64x32 Arduino Icon.
// This icon keeps the same "flavor" as the original Ardino Icon
// but has been modified to fit on lcd displays that are only 32 pixels high
// and has be limited to only 64 pixes wide.
// Created 2009-12-12 by Bill Perry  (bperrybap@opensource.billsworld.billandterrie.com)

#ifndef _ArduinoIcon64x32_H 
#define _ArduinoIcon64x32_H 

#include <inttypes.h>
#include <avr/pgmspace.h>

static unsigned char ArduinoIcon64x32[] PROGMEM ={
64,	// bitmap width  (arduino glcdlib format)
32,	// bitmap height (arduino glcdlib format)
0x00, 0x00, 0xc0, 0x20, 0x10, 0x08, 0xc8, 0x88, 0x08, 0x08, 0x10, 0x20, 0xc0, 0x00, 0x00, 0x00, 
0x00, 0x00, 0x00, 0x00, 0x00, 0xc0, 0xf0, 0xf8, 0xf8, 0xf8, 0xf0, 0xc0, 0x00, 0x00, 0x00, 0x40, 
0x70, 0x0c, 0x30, 0xc0, 0x00, 0xc0, 0x30, 0x0c, 0x30, 0xc0, 0x00, 0xc0, 0x30, 0x08, 0x88, 0x48, 
0x28, 0x28, 0xf8, 0x20, 0x20, 0x40, 0x80, 0x40, 0x20, 0x10, 0x20, 0x98, 0x18, 0xc0, 0xc0, 0x00, 

0x00, 0x07, 0x18, 0x20, 0x40, 0x80, 0x9f, 0x8f, 0x87, 0x82, 0x40, 0x20, 0x18, 0x07, 0x00, 0x00, 
0x00, 0x00, 0x80, 0xf0, 0xfe, 0xff, 0xff, 0x1f, 0x03, 0x1f, 0xff, 0xff, 0xfc, 0xf0, 0x80, 0x00, 
0x00, 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x1c, 0x63, 0x80, 0x46, 
0x4a, 0x52, 0xe3, 0x52, 0x4a, 0x46, 0x80, 0x63, 0x1c, 0x02, 0x01, 0x00, 0x01, 0x00, 0x00, 0x00, 

0x00, 0xc0, 0x30, 0x08, 0x04, 0xe2, 0x22, 0x22, 0x22, 0xe2, 0x04, 0x08, 0x30, 0xc0, 0x00, 0x00, 
0xe0, 0xfc, 0xff, 0xff, 0x7f, 0x7f, 0x78, 0x78, 0x78, 0x78, 0x78, 0x7f, 0x7f, 0xff, 0xff, 0xfc, 
0xe0, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 
0x02, 0x02, 0xff, 0x02, 0x02, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 

0x00, 0x01, 0x06, 0x08, 0x10, 0x23, 0x22, 0x22, 0x22, 0x23, 0x10, 0x08, 0x06, 0x01, 0x18, 0x3f, 
0x3f, 0x3f, 0x0f, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x0f, 0x3f, 
0x3f, 0x3f, 0x18, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x02, 
0x0a, 0x0a, 0x2b, 0x0a, 0x0a, 0x02, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 

#endif  //define _ArduinoIcon64x32_H

This problem is caused by several things that all come together at the same time.
The main issues are that the progmem kludge used by avr-gcc to store data in flash
that comes with AVR libC along with const section typing don’t work for C++.

There are several hacks out there to work around it.
This mainly occurs when const and non const data are used for progmem data
initialization declarations.

C was not designed to support multiple address spaces.
The avr chip unlike other risk architectures out there does not have the
ability to directly read data stored in flash. The progmem stuff was a kludge
work around this h/w limitation. Unfortunately, with the version of the C compiler that is shipped
with Arduino, there are issues with the progmem kludge when used with const vs non const data
in C++.
(Oliver, just using a C file instead of a C++ file to initalize the data doesn’t always solve the issue,
since it can potentially create some new issues - it isn’t that easy in this case)

It is a pain to deal with since it requires 100% of all the code used in a sketch to use and
declare & initalize progmem data the same way.
Compounding to the problem, is that the examples shown on the Arduino PROGMEM
web page are not correct, and several of the core code modules are also not properly
using progmem as well.
When this issues shows up, it requires modifying code to make everything match.

First the bad news: I no longer support the GLCDv3 library so that library
is not likely to get any updates.

Now the good news: I have created a openGLCD library that is a superset replacement.
openGLCD is licensed GPL v3.

It includes many new API functions, full documentation, many new examples,
and example sketches for every API function.

Probably most important to you is that
openGLCD includes a transparent work around that solves this progmem problem.

The easiest way resolve this is probably to switch from GLCDv3 to openGLCD
assuming you are not building a closed source product/project, which is probably the case
since m2tklib seems be GPL v3 as well.

The only other issue will be that currently M2tklib doesn’t directly support openGLCD.
(A few of the functions take slightly different parameters which will cause things to not line up properly)
While the changes to M2tklib are very minimal to work with openGLCD,
openGLCD includes a GLCDv3 compatibility mode that can be used.

In order to “trick” M2tklib into using openGLCD instead of GLCDv3,
a glcd.h compatibilty header must be created down in the openGLCD directory,
and the glcd library will have be uninstalled.
You can read more about it in the openGLCD documentation in the Sketch Migration section
under Migration from GLCDv3

It involves creating glcd.h header with this in it:

#include <openGLCD.h>		// inform Arduino IDE that we will use openGLCD library
#include <include/openGLCD_GLCDv3.h>	// inform openGLCD we will use GLCDv3 mode

For now there is a header under the openGLCD directory called glcd.h.compat
that can be renamed glcd.h

I just tried it with the latest 1.11 M2tklib library and it seems to be working.

A word of caution when using GLCDv3 compatibilty mode, is that the
documentation and API examples, that come with openGLCD will be for openGLCD API parameters
and will no longer be correct for the same calls made when the code is operating in GLCDv3 mode.
The GLCDv3 documentation will have to be consulted for the proper API parameters.
It can get confusing.

maybe we can sync up on adding support for openGLCD?

— bill

maybe we can sync up on adding support for openGLCD?

I have put this task into the next milestone for m2tklib.


Thanks all for your great explanations. I will try to get things working on compatibility mode for now.

Any idea as to when M2tklib will be updated to support openGLCD?

Cool!!! it worked and it was super easy!!! Now I can do other stuff like put a battery charge symbol and a plug symbol in the screen!

Cool!!! it worked and it was super easy!!! Now I can do other stuff like put a battery charge symbol and a plug symbol in the screen!

Did you update m2tklib to support openGLCD in GLCDv3 mode?

Right now, i am working on a native port to openGLCD.



Cool!!! it worked and it was super easy!!! Now I can do other stuff like put a battery charge symbol and a plug symbol in the screen!

Did you update m2tklib to support openGLCD in GLCDv3 mode?

If you create a glcd.h down in the openGLCD directory that turns on compatibility mode,
there are no changes requires to m2tklib.
I’m assuming that is what was done.

The IDE does not care where headers live since it looks “everywhere”.
i.e. if you include <glcd.h> and the IDE finds it in the libraries/openGLCD directory
then libraries/openGLCD is added to the include path and the library
is compiled and linked in.

That is how you “trick” existing GLCDv3 code into running on openGLCD
with no changes.

— bill

Well, yes, i already noticed that the “compatibility mode” really works nicely.

However i spent some hours to create a native port to openGLCD for M2tklib. Not all examples are converted, but i hope that the most basic things are covered by the included examples.

There are some small differences between the GLCDv3 and the openGLCD port for M2tklib:

  1. m2.setFont is now required (in the GLCDv3 port it did depend on the graphics handler)
  2. There are only two graphics handler, i suggest to use: m2_gh_openglcd_ffs. See the example files
  3. The name of the include file has changed to #include “m2ghopenglcd.h”


m2tklib_arduino_openglcd_1.12pre2.zip (189 KB)

I will try this out. It doesn't look like it will take much to get it going.

I haven't run into any issues using compatibility mode yet, but I haven't needed to do much of anything besides displaying bitmaps yet.


Can I make a suggestion that you add a bitmap image handler to your public functions? I noticed that your x-y formatting is different than the GLCD formatting. Yours goes from the bottom left, and his goes from the top left... no big deal to figure out, but it would be nice to have a consistent coordinate system.

It is true, that openGLCD and M2tklib differ in their coordinate systems, but how can a bitmap handler solve this? Is there a specific problem at the moment?


It's not really the coordinate system is it? I thought they all ( u8glib, m2tklib, GLCDv3, and openGLCD ) used 0,0 as the upper left corner of the physical display?

Maybe the anchor positioning point of the glyphs & images is different?

--- bill

Indeed, the origin (0,0) of M2tklib is buttom left of the display.


Hello, I decided to try GLCD (openGLCD) on my project, because u8glib was running really slow and also, memory consume was way higher than with openGLCD. So, I tested openGLCD sample program, which worked ok (all bitmaps and everything showing ok with 23 fps). Now I connected openGLCD with m2tklib with GLCDV3 compatibility mode and I can't display my generated bitmaps, which I created with included java application. Bitmaps are not displaying - only blank spaces. I also have to mention, that I had to change definitions in glcd_types.h from this:

#define GLCDFONTDECL(_n) const uint8_t _n[]

to this:

#define GLCDFONTDECL(_n) const char PROGMEMGLCD _n[]

because of type missmatch in m2tklib for XBM objects (they are expecting char*, not unsigned char*). For example, my definition of a button looks like this:


and my ikona_ok is defined in ikona_ok.h in bitmaps folder of openGLCD and m2tklib recognize it and compiles ok, but then no bitmap is displayed on glcd. Can you tell me, how did you managed to display bitmaps with m2tklib and openGLCD. I just can't..

I can't understand what issues you are experiencing.

You mention issues with bitmaps but then show changing a non AVR processor font define used for font data - not bitmaps. And then talk about bitmaps and as well as XBM bitmaps.

In openGLCD there are two different types of bitmap data. XBM and then a proprietary internal format which stores data differently than XBM format.

The GLCDFONTDECL is a define used by openGLCD fonts so I'm not sure how that affects u8glib XBM bitmaps.

I'm not sure which tool you are using to create bitmaps. The one supplied with openGLCD does not create XBM bitmap files.

If you could provide more details about what the issues are and your environment, I'll take a look and see if I can figure out what the problem is. Things like what IDE versions, processor type, what tool you are using to create the bitmaps, and more details about the type issues you are having.

--- bill

bmandl, On closer reading. I just realized that you are hijacking a thread that is over a year old. It would better if you started your own thread for your issues, rather than clutter up this thread with a different discussion topic.

--- bill