The message of conflict
Image1.h : Image1 causes a section type conflict
Arial_bold_14.h : Arial_bold_14 causes a section type conflict
Error compiling
The actual error in your code is more difficult. At the moment i can not do more than give you some ideas and keywords.
As far as I know fonts are defined (not declared) in the .h files, which might lead to some problems, when included twice
Font definition make use of the PROGMEM attribute.
GNU C++ is has at least one bug with the PROGMEM sections.
GNU C++ has changed its behaviour with respect to PROGMEM area. The error might depend on the IDE version and the question whether you have installed a parallel gnu compiler suite.
Ideas for a solution:
Using C-Code instead of C++ code sometimes helps
Maybe an additional C++ file for the intro screen might also help
You might consider to use U8glib instead of GLCD (if this is a KS0108 display with 128x64 pixel size). Fonts in U8glib are declared in a different way so that the above mentioned problem "usually" will not appear.
Part of the issue here is the simplistic (poor) font methodology used in GLCD.
(It was inherited from its parent library ks0108). Because the fonts don't have
a separate external declaration, it creates issues when the font header is included more than once.
(like in separate modules) because the data ends up being declared & defined more than once - At some point I will fix this.
(It not as easy as it sounds since there are several font tools out there that create font files that I don't have control over)
But I think part of the issue in this case is also the way u8glib is working around some of the C++ progmem issues.
As Oliver said there are issues with PROGMEM and C++
PROGMEM often issues warnings in C++ when it shouldn't, so there have been attempts at creating
work arounds to suppress the warnings.
Some of these "work arounds" eliminate the warnings but create other issues.
Also, I'm starting to see different libraries attempt different work arounds and that can create problems as well
when used together as the work arounds are potentially incompatible with each other.
For example,
This popular "work around":
#ifdef PROGMEM
#undef PROGMEM
#define PROGMEM __attribute__((section(".text"))) // works on both AVR and ARM
#endif
Will break M2tklib because the two m2_rom pointers that use M2_PROGMEM in utility/m2.h create an
error if this work around done before m2.h is included.
A safer M2_PROGMEM definition would be:
#define PROGMEM __ATTR_PROGMEM__
to avoid any of those PROGMEM work arounds.
Overall, the avr-gcc PROGMEM stuff is a kludge that is quite fragile.
I've wrestled with progmem C++ issues on Arduino for quite some time.
Its a mess because of the different versions of avr-gcc and now all the work arounds
that are being used.
Oliver, we need to sync up off line.
I'm in the process of a major update of the GLCD library.
There are also some issues with the way Paul has defined his PROGMEM compatibility macro
for his teensy3 product that will more than likely affect your stuff as well.
I try to reproduce the problem on my PC, but Image1.h is missing. Can you attach this file also. It isn't needed. He aleady comment out the code that used it. Just comment out the include. and then uncomment the SelectFont()
What is your exact version of the Arduino IDE? I found it failed with 1.0 and 1.0.5
Unfortunately i can't managed to do it.
The lib u8glib was perfect with my ks0108 monitor but i confused with the structure.
I want an intro screen like in photo, and after 5 sec to start my main menou.
In the area image i want to have an image wicth i have in .h format.
Oliver,
It took me quite a while to grasp the u8glib screen update methodology as well.
While it isn't that complicated once you "get it", it wasn't immediately obvious to me
because it was so different and foreign to me.
I wonder if it would make it easier for folks, if you provided a wrapper function or macro
to hide the first/next drawing loop?
Users could pass the macro/function the name of the u8g object and the users drawing function.
The macro/function could take care of the rest.
@Bill:
Indeed i have thought about option, but i took over the concept from the dogm128 lib (which had been the predecessor for u8glib). I know the concept is difficult to understand...
@hydrogen99
You can use gimp and export your bitmap as XBM (monochrome) bitmap. XBM is actually plain c code which can be copyied into your source code (.c or .h). Then use the drawXBMP command.
olikraus: @hydrogen99
You can use gimp and export your bitmap as XBM (monochrome) bitmap. XBM is actually plain c code which can be copyied into your source code (.c or .h). Then use the drawXBMP command.
Oliver
Don't you have to insert some kind of progmem attribute?
olikraus: @hydrogen99
You can use gimp and export your bitmap as XBM (monochrome) bitmap. XBM is actually plain c code which can be copyied into your source code (.c or .h). Then use the drawXBMP command.
Oliver
Don't you have to insert some kind of progmem attribute?
olikraus: @hydrogen99
You can use gimp and export your bitmap as XBM (monochrome) bitmap. XBM is actually plain c code which can be copyied into your source code (.c or .h). Then use the drawXBMP command.
Oliver
Don't you have to insert some kind of progmem attribute?