loadCustomCharacter but not unload!

Hi guys,
I just found a glitch in the lcd functions.
My robot code basically does:

void load_custom_characters()
{
	OrangutanLCD::loadCustomCharacter(levels+0,0); // no offset, e.g. one bar
	OrangutanLCD::loadCustomCharacter(levels+1,1); // two bars
	OrangutanLCD::loadCustomCharacter(levels+2,2); // etc...
	OrangutanLCD::loadCustomCharacter(levels+3,3);
	OrangutanLCD::loadCustomCharacter(levels+4,4);
	OrangutanLCD::loadCustomCharacter(levels+5,5);
	OrangutanLCD::loadCustomCharacter(levels+6,6);
	lcd.clear(); // the LCD must be cleared for the characters to take effect
}

then to print the display bar chart:

display_readings(const unsigned int *calibrated_values)

the problem is then when I print some values from my algorithms lets say:

	simple.a=100;
	  lcd.gotoXY(0,0);
	  OrangutanLCD::print("Min:");
	  lcd.gotoXY(4,0);
	  OrangutanLCD::print(simple.a);

I get random chars popping up.
How can I unload the custom characters from the EEPROM?
Should I put to to zero the custom characters in the prog mem space?

const  PROGMEM char levels[]= {
	0b00000,
	0b00000,
	0b00000,
	0b00000,
	0b00000,
	0b00000,
	0b00000,
	0b11111,
	0b11111,
	0b11111,
	0b11111,
	0b11111,
	0b11111,
	0b11111
};

UPDATES:
I probably found where the error is, I’m doing a simple test program and uploading so others can try to reproduce the bug I’m having.

Cheers.

oky here how to test it:
[ul]
untar the library
make
cd learning/lcdprint
make
make program
[/ul]

In particular check the function:

void calibrate()
{

	//controller.emittersOn();
	long elapsed_ms;

	/*! This values are measured from Paolo's Playground:
		must be changed if you use a custom one  */
	OrangutanAnalog::setMode(MODE_8_BIT);  
	//! FIX ME: remove the offset when you have a proper screw
	unsigned int trim_pwr=OrangutanAnalog::readTrimpot() -100;
	//! Wait in case the ADC is still taking measure
	while(OrangutanAnalog::isConverting());

	//position the robot to run forward
	OrangutanTime::reset();
	OrangutanMotors::setSpeeds(trim_pwr, trim_pwr);
	cal_start_time=OrangutanTime::ms();
	//run the robot for 3 seconds: enough to scan the food blob
	unsigned int nsamples=3000/20;
	for(unsigned int counter=0;counter<nsamples;counter++){
		//controller.calibrateLineSensors();
		OrangutanTime::delayMilliseconds(20);
	}
	//controller.calibrateFoodSignals();
	OrangutanMotors::setSpeeds(0,0);
	OrangutanBuzzer::playFrequency(440, 500, 15); /* beep a tone */
	while (OrangutanBuzzer::isPlaying());
	lcd.clear();
	simple.a=101;
	simple.b=602;
	while(!buttons.isPressed(BUTTON_B))
	{
	  lcd.gotoXY(0,0);
	  lcd.print("Min:");
	  lcd.gotoXY(4,0);
	  lcd.print(simple.a);
	  lcd.gotoXY(0,1);
	  lcd.print("Max:");
	  lcd.gotoXY(5,1);
	  lcd.print(simple.b);

	}
	buttons.waitForRelease(BUTTON_B);
	//increase a little bit the bias so the robot is faster
	//controller.bias=0;
}

The class is soo simple:


#ifndef TestClass_h
#define TestClass_h


class TestClass
{
  private:
    unsigned int x;
    unsigned int y;
    unsigned int z;

  public:
    unsigned int a;
    unsigned int b;
    unsigned int c;
    TestClass();
};


#endif

On the lcd it prints something like:

I really can’t see what I did wrong, it could be some object allocation/ pointer issues?
For instance even with the most simple basic program like:


#include <pololu/OrangutanLCD.h>
#include <pololu/OrangutanLEDs.h>
#include <pololu/OrangutanPushbuttons.h>
#include <pololu/OrangutanTime.h>
#include <pololu/TestClass.h>
#include <string.h>

// This include file allows data to be stored in program space.  The
// ATmega168 has 16k of program space compared to 1k of RAM, so large
// pieces of static data should be stored in program space.
#include <avr/pgmspace.h>

	//Pololu3pi //controller(0.01,0.501);
	OrangutanLCD lcd;
	TestClass simple;


	OrangutanPushbuttons buttons;
	//last function call time
	unsigned long cal_start_time;
	// Introductory messages.  The "" identifier causes the data to
	// go into program space.

int main()
{
	//controller.init();
	//load_custom_characters(); // load the custom characters
	// This is the "main loop" - it will run forever.
	while(1)
	{
		lcd.clear();
	simple.a=101;
	simple.b=602;
	while(!buttons.isPressed(BUTTON_B))
	{
	  lcd.gotoXY(0,0);
	  lcd.print("Min:");
	  lcd.gotoXY(4,0);
	  lcd.print(simple.a);
	  lcd.gotoXY(0,1);
	  lcd.print("Max:");
	  lcd.gotoXY(4,1);
	  lcd.print(simple.b);

	}
	buttons.waitForRelease(BUTTON_B);
	}
}

Gives me the same output!
mylib.tar.gz (137 KB)

ARghhh I found the problem, it’s the avr-gcc4.3.0 that doesn’t compile properly the c++ classes.
With previous versions works perfectly!
I should stop using latest versions!

Hello.

I’m glad you were able to figure it out and make the rest of us aware of the bug!

- Ben

Hi epokh,
I tried to figure out what you were doing, but I couldn’t easily compile your program. Your instructions for compiling it don’t work, since TestClass.h is not installed in the system include directory on my computer - it looks like you are expecting me to first install your modified version of the Pololu library. Since you thought that the instructions would work, I suspect that you are having problems because you have two or more different versions of TestClass installed on your system at the same time. For example, you might be using an old version of the .h file with a new version of the compiled TestClass code. This could lead to all kinds of problems, which seems much more likely than a bug in gcc.

The idea with the Pololu library is that you should install it, then write your own code in a separate directory. If you can try doing it this way, you can provide a much simpler example, and that will make it much easier for people to help you debug it! Anyway, as far as we know, the Pololu AVR library works on the most recent versions of gcc. We’d love to take a look if you can simplify your code to something much easier to deal with.

-Paul

O yes you are right, I will post a very simple test case.
I still can’t believe why in the gcc4.3 the same code (delete copy and paste) not working and in the gcc4.2 is working perfectly .