[SOLVED] PROGMEM conflict with GLCD library ks0108 (v3 RC2)

Hi all,

I’m facing some problems with the KS0108 library in its v3 RC2 version.

I want to store a 2D String table inside the FLASH for freeing some precious RAM KB …
But, when i try to compile, it shows some errors related to this message :

<PATH TO FILE>/SystemFont5x7.h:48: error: System5x7 causes a section type conflict

If i disable the line GLCD.SelectFont(SystemFont5x7);, it compiles fine.
I even tried to move this line to another part of my code : SAME PROBLEM … :frowning:

What is a “section type conflict” ?
How can i find a workaround to bypass this problem ?

Thanks !

This is my analyses on my own code. The problem is (probably) a combination of several issues: 1) A bug in avr-g++: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34734 2) The fact that GLCD places the definition of the font in the .h file 3) Some other variables in your code, which are also defined with PROGMEM

Does point 3) apply to your code also? If this is the case, try separating the PROGMEM definitions into two different files.

For example place the following code into a new file.

#include "glcd.h"
#include "fonts/SystemFont5x7.h"

void setSystemFont(void)
{
  GLCD.SelectFont(SystemFont5x7);
}

Do not include SystemFont5x7.h into your other files. Just make a call to setSystemFont() to set the system font. At least, this has worked with my code.

Good luck, Oliver

Can you boil this down to a very small sketch that demonstrates the problem? I'd like to track this down and see if it can be squashed out once and for all.

I've read some recent discussion on this that while it is related to the C++ progmem issue it may be due to not using "const" when using PROGMEM or sometimes using it and sometimes not.

So there may be a way to work around or avoid this problem.

If you can get me a very small example sketch that fails, I'll see if I can find a solution.

-- bill

The following code produces the error on my machine with Arduino-0022 IDE:

#include <glcd.h>
#include "fonts/SystemFont5x7.h"

int b PROGMEM;

void setup() {
 GLCD.SelectFont(System5x7);
}

void loop() {
}

Simkard, maybe you could also provide some code which demonstrates the error.

Oliver

olikraus:
The following code produces the error on my machine with Arduino-0022 IDE:

#include <glcd.h>

#include “fonts/SystemFont5x7.h”

int b PROGMEM;

void setup() {
GLCD.SelectFont(System5x7);
}

void loop() {
}




Simkard, maybe you could also provide some code which demonstrates the error.

Oliver

This code is fine for showing the famous error “error: System5x7 causes a section type conflict”

After opening this file, it stores the font inside the FLASH by a PROGMEM command.
Here is a part of the file :

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

#ifndef SYSTEM5x7_H
#define SYSTEM5x7_H

#define SYSTEM5x7_WIDTH 5
#define SYSTEM5x7_HEIGHT 7

/*
 * added to allow fontname to match header file name. 
 * as well as keep the old name for backward compability
 */

#define SystemFont5x7 System5x7

static uint8_t System5x7[] PROGMEM = {
    0x0, 0x0, // size of zero indicates fixed width font, actual length is width * height
    0x05, // width
    0x07, // height
    0x20, // first char
    0x7f, // char count
    
    // Fixed width; char width table not used !!!!
    
    // font data
    0x00, 0x00, 0x00, 0x00, 0x00,// (space)
	0x00, 0x00, 0x5F, 0x00, 0x00,// !
	0x00, 0x07, 0x00, 0x07, 0x00,// "
	0x14, 0x7F, 0x14, 0x7F, 0x14,// #
	...

olikraus:
The following code produces the error on my machine with Arduino-0022 IDE:

#include <glcd.h>

#include “fonts/SystemFont5x7.h”

int b PROGMEM;

void setup() {
GLCD.SelectFont(System5x7);
}

void loop() {
}




Simkard, maybe you could also provide some code which demonstrates the error.

Oliver

Ok, this is a very good example and it does create the error.
However, I somewhat question the validity of the code.

For example, does it really make sense to have a variable in PROGMEM that is not initialized?

If I change the code so something like this:

#include <glcd.h>
#include "fonts/SystemFont5x7.h"

int b PROGMEM = 1;

void setup() {
 GLCD.SelectFont(System5x7);
}

void loop() {
}

It compiles just fine.

Is there another example that demonstrates this problem?

— bill

int b PROGMEM = 1;

It compiles just fine.

Correct. I have more useful examples, however, I use a modified PROGMEM attribute which does not apply to the original problem. Maybe simkard can post his code.

Oliver

Well … i do initialize the variable in PROGMEM.

My code looks like this :

STRUCT_MENU LCD_MENU_TREE [] PROGMEM = {
  // each entry defined as {<MENU LEVEL>, <MENU #>, <SUBMENU LEVEL>, <MENU TEXT>, <(0)FUNCTION /OR/ (1)VALUES>, <FUNCTION #>}
  // MAIN MENU TEXT
  {0, 1, 1, "Main Menu", false, 0},
  // 1st LEVEL MENUs
  {1, 1, 11, "Configuration", false, 0},
  {1, 2, 12, "Tests", false, 0},
  {1, 3, 0, "About ...", false, 101},
  ...

Even if i delimit the array by entering something inside the [ x ], it ends the same way when compiling the code.

One last thing, my struct “STRUCT_MENU” looks like this :

struct STRUCT_MENU {
  byte MENU_LEVEL;
  byte MENU_REF;
  byte SUBMENU_LEVEL;
  String MENU_TEXT;
  boolean FUNCTION_OR_VALUES;
  int FUNCTION_REF;
};

Is that helps for getting rid of the conflict problem ?

I've got some precisions about the initiation of the problem.

It seems that when the line "GLCD.SelectFont(SystemFont5x7);" is somewhere inside the code, the problem shows on every table based on a struct containing a String field.

I know that the SystemFont5x7 file contained inside the GLCD v3 RC2 stores the font inside the FLASH with a PROGMEM too. Like i said earlier, the values are defined like this (uint8_t values table) :

static uint8_t System5x7[] PROGMEM = {
    0x0, 0x0, // size of zero indicates fixed width font, actual length is width * height
    0x05, // width
    0x07, // height
    0x20, // first char
    0x7f, // char count
    
    // Fixed width; char width table not used !!!!
    
    // font data
    0x00, 0x00, 0x00, 0x00, 0x00,// (space)
    0x00, 0x00, 0x5F, 0x00, 0x00,// !
    0x00, 0x07, 0x00, 0x07, 0x00,// "
    ...

I just don't know why there could be a section conflict ? Is it because values tables are not delimited and then came to cross each others ?

Found it !

I had to replace in my struct the "String" to "char xxxxx[20]". It seems that PROGMEM doesn't like it.

But now, i'm facing another problem : my menu lines on my LCD doesn't show at all. During the read of the char values, something must go wrong because the graphics of the menu shows but no text is being displayed.

Have you considered to use m2tklib? http://code.google.com/p/m2tklib/ I have solved all PROGMEM problems with GLCDv3 for m2tklib and it also creates reliable and working menues :) .

Oliver

In fact, i needed to build my own because i have to deal with some functionnalties that are not presents in the m2tklib.

I hope i will be able to release some lib some day with my menu.

Hmm interessting remark. What kind of functionality do you need? What is missing in m2tklib?

Oliver

simkard: Found it !

I had to replace in my struct the "String" to "char xxxxx[20]". It seems that PROGMEM doesn't like it.

But now, i'm facing another problem : my menu lines on my LCD doesn't show at all. During the read of the char values, something must go wrong because the graphics of the menu shows but no text is being displayed.

simkard, It is impossible for me to assist you or be able to fix any potential issues in the GLCD library without some way of replicating the problems. Small example sketches that demonstrate the problem are the best way to resolve issues.

With respect to the issue mentioned above, (not seeing your text characters displayed), without seeing any code, I can only speculate. So perhaps this will help: Keep in mind that because the AVR is harvard architecture and the way avr-gcc is implemented, it is impossible to tell which address space a pointer is pointing to. I.e. a pointer can be a pointer to RAM, FLASH, or EEPROM, and there is no way to know which. Because of that, there are different API calls in the GLCD library to deal with this.

So for RAM based strings you might call Puts("string") while in FLASH you would call Puts_P(PSTR("string");

So if you have declared your text strings in flash using PROGMEM, you cannot call Puts(), DrawString() or Printf() to display them.

Again, without seeing any code, it is impossible to know what is happening.

--- bill

olikraus: Hmm interessting remark. What kind of functionality do you need? What is missing in m2tklib?

Oliver

Ok, sorry for being late, but i hope a video would mean more than words : http://youtu.be/qXGr6GbFyqQ

Have a nice watch ;) :grin:

Wow, great work. Good video.

In fact, i needed to build my own because i have to deal with some functionnalties that are not presents in the m2tklib.

I still believe that all this could be done with m2tklib. I played a little bit around with m2tklib: Obviously it looks different, but should provide same functionality.

Anyway, I see that you wrote an amazing piece of software. I know it is hard to deal with menus, PROGMEM issues and complex data structures at the same time. What i have seen from your posts: It will also be easy for the user to create such a menu. And I am also glad to see that more and more people work on menu systems for the Arduino environment.

Oliver