Problem with external PROGMEM data.

LeafLabs Garden » Support » Maple IDE Support

Problem with external PROGMEM data.

(5 posts) (3 voices)

Started 3 years ago by RichardE
Latest reply from gbulmer

RichardE
Member

I just got my REV 5 Maple and have it plugged into a Gameduino and am trying to port a program that works fine on an Arduino.

Seem to have hit a snag when referencing data declared as extern. Here's a test program I wrote:

*** File TestCharset.pde ***

#include <GD.h>
#include "RobotRicCharacterSet.h"

#define RAM_CHR_SIZE 4096        // size of character set pixel data RAM
#define RAM_PAL_SIZE 2048        // size of character set palette data RAM

void setup( void ) {
  PROGMEM prog_uchar *ptr;
  // Initialise Gameduino.
  GD.begin();
  // Initialise character set pixel data RAM.
  ptr = RobotRicCharacterSetPixelData;
  // GD.copy( RAM_CHR, ptr, RAM_CHR_SIZE );
  // Initialise character set pixel palette RAM.
  ptr = RobotRicCharacterSetPaletteData;
  // GD.copy( RAM_PAL, ptr, RAM_PAL_SIZE );
}

void loop( void ) {
}

*** File RobotRicCharacterSet.h ***

#include <GD.h>
extern PROGMEM prog_uchar RobotRicCharacterSetPixelData[];
extern PROGMEM prog_uchar RobotRicCharacterSetPaletteData[];

*** File RobotRicCharacterSet.cpp (edited for brevity) ***

#include <GD.h>
PROGMEM prog_uchar RobotRicCharacterSetPixelData[] = {
0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, // Character 0
0x00, 0x00, 0x15, 0x55, 0x1A, 0xAA, 0x1B, 0xFF, 0x1B, 0xFF, 0x1B, 0xEA, 0x1B, 0xE5, 0x1B, 0xE4, // Character 1
0x00, 0x00, 0x55, 0x55, 0xAA, 0xAA, 0xFF, 0xFF, 0xFF, 0xFF, 0xAA, 0xAA, 0x55, 0x55, 0x00, 0x00, // Character 2
0x00, 0x00, 0x55, 0x54, 0xAA, 0xA4, 0xFF, 0xE4, 0xFF, 0xE4, 0xAB, 0xE4, 0x5B, 0xE4, 0x1B, 0xE4, // Character 3

... and so on ...

0xBD, 0x7E, 0xC1, 0x43, 0xC6, 0x93, 0x5A, 0xA5, 0x5A, 0xA5, 0xC6, 0x93, 0xC1, 0x43, 0xBD, 0x7E, // Character 253 (ý)
0xBD, 0x7E, 0xC1, 0x43, 0xC6, 0x93, 0x5A, 0xA5, 0x5A, 0xA5, 0xC6, 0x93, 0xC1, 0x43, 0xBD, 0x7E, // Character 254 (þ)
0x3F, 0xFC, 0xFF, 0xFF, 0xFB, 0xEF, 0xFF, 0xFF, 0xFE, 0xBF, 0xDF, 0xF7, 0xF5, 0x5F, 0x3F, 0xFC, // Character 255 (ÿ)
};
PROGMEM prog_uchar RobotRicCharacterSetPaletteData[] = {
0xFF, 0x7F, 0xE0, 0x03, 0x1F, 0x7C, 0x00, 0x80, // Character 0
0x10, 0x00, 0x1F, 0x00, 0x1F, 0x42, 0x1F, 0x63, // Character 1
0x10, 0x00, 0x1F, 0x00, 0x1F, 0x42, 0x1F, 0x63, // Character 2
0x10, 0x00, 0x1F, 0x00, 0x1F, 0x42, 0x1F, 0x63, // Character 3

... and so on ...

0xFF, 0x7F, 0xE0, 0x03, 0x1F, 0x7C, 0x00, 0x00, // Character 253 (ý)
0xFF, 0x7F, 0xE0, 0x03, 0x1F, 0x7C, 0x00, 0x00, // Character 254 (þ)
0x00, 0x00, 0xE0, 0x03, 0xE0, 0x7F, 0x00, 0x7C, // Character 255 (ÿ)
};

As it stands the test program compiles OK. If I uncomment the lines calling GD.copy I get the message :

<BUILD>/TestCharset.cpp:19: undefined reference to `RobotRicCharacterSetPixelData'
<BUILD>/TestCharset.cpp:19: undefined reference to `RobotRicCharacterSetPaletteData'

What's going on? How come it can find them when I don't call GD.copy but it cannot when I do?

Note: GD.h is James Bowman's work from here : http://excamera.com/files/Gameduino_m.zip

The only clue I have is that the second parameter to copy is declared as prog_uchar *src rather than PROGMEM prog_uchar *src but I would not expect it to generate this error.

Any help appreciated.

Posted 3 years ago #

RichardE
Member

Update: If I wrap the character set data up as static members of a class like this:

/*
 * SOURCE FILE : RobotRicCharacterSet.h
 *
 * Contains character set data for RobotRic game.
 *
 */

#ifndef RobotRicCharacterSetIncluded

  #define RobotRicCharacterSetIncluded

  #include <GD.h>

  class RobotRicCharacterSet {

  public :

    static PROGMEM prog_uchar PixelData[];
    static PROGMEM prog_uchar PaletteData[];

  };

#endif

/* END of RobotRicCharacterSet.h */

then I don't get the errors. Weird.

Posted 3 years ago #

manitou
Member

You probably have enough RAM to get rid of PROGMEM ... but here's the info from the FAQ
http://leaflabs.com/docs/arm-gcc.html#arm-gcc-attribute-flash
Lots of earlier discussions on forum regarding PROGRMEM ...

Posted 3 years ago #
RichardE
Member
I thought about using __FLASH__ and I may do it that way later. I just wanted (as far as possible) to keep the code the same as the Arduino version for now.

Incidentally, is __FLASH__ the only way to put data in program memory? If you declare data as const will that not do it? The GD.h file has this line in it :
```
#define PROGMEM const
```
and I assumed that put all data declared as PROGMEM in flash.
Posted 3 years ago #
gbulmer
Moderator

RichardE - you can define a macro which converts PROGMEN to nothing, so you can keep some level of source code compatibility with Arduino. But as I wrote elsewhere, you will be losing a lot of benefits of using a Maple.

You might want to create two macros, one to be used as a storage class of the data you want to store in Flash, and the other as the storage qualifier of pointers. Then you could move back and forth between Arduino and Maple more easily. The data storage class for Maple could be __FLASH__, and the qualifier on pointers would be empty. The data storage class and pointer qualifier for Arduino would be PROGMEM.

is __FLASH__ the only way to put data in program memory?

Under the covers, there are several types of memory segment, or section, which get stored in Flash. If you look at the definition:
#define __FLASH__ __attr_flash
which leads to
#define __attr_flash __attribute__((section (".USER_FLASH")))
You can see one, but there is also .text which contains all of the program code, usually .ro_data, etc.

The link scripts, startup code, and running program make assumptions about each one. I'd recommend using __FLASH__ for now because the support is in place. But you could go look at the stuff inside the Maple IDE.

If you declare data as const will that not do it?

In general const does not guarantee that values are stored in Flash.
I think a combination of compiler flags and linker scripts will do it for processors like ARM, where there is a single address space. By default, const is interpreted by the compiler as an instruction to it to check that code doesn't try to change a value, and a hint which may allow it to optimise generated code more effectively.

Further, on the Arduino's AVR processor, the compiler can't attempt to put 'const' in flash because (as I explained elsewhere) the instructions which read data from program memory are different from the ones that read data from RAM. So to put const into Flash on an AVR processor could be a disaster because pointers to it couldn't be handed to functions which would be expecting to get data from data memory (RAM).

(Full disclosure: I am not a member of leafLabs staff)

Posted 3 years ago #

RSS feed for this topic

Reply

You must log in to post.