http://forums.leaflabs.com/topic.php?id=1481 A place to share, learn, and grow... en-US Fri, 22 Jan 2016 00:16:28 +0000 http://bbpress.org/?v=1.0.2 q http://forums.leaflabs.com/search.php http://forums.leaflabs.com/topic.php?id=1481#post-9820 Sun, 18 Mar 2012 15:58:56 +0000 gbulmer 9820@http://forums.leaflabs.com/ <p>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.</p> <p>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.</p> <blockquote><p>is __FLASH__ the only way to put data in program memory?</p> </blockquote> <p>Under the covers, there are several types of memory segment, or section, which get stored in Flash. If you look at the definition:<br /> <code>#define __FLASH__ __attr_flash</code><br /> which leads to<br /> <code>#define __attr_flash __attribute__((section (&quot;.USER_FLASH&quot;)))</code><br /> You can see one, but there is also <code>.text</code> which contains all of the program code, usually <code>.ro_data</code>, etc. </p> <p>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.</p> <blockquote><p>If you declare data as const will that not do it?</p> </blockquote> <p>In general <code>const</code> does not <strong>guarantee</strong> that values are stored in Flash.<br /> 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, <code>const</code> 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.</p> <p>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 <code>const</code> 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).</p> <p>(Full disclosure: I am not a member of leafLabs staff) </p> http://forums.leaflabs.com/topic.php?id=1481#post-9116 Sat, 17 Mar 2012 06:01:26 +0000 RichardE 9116@http://forums.leaflabs.com/ <p>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.</p> <p>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 :</p> <pre><code>#define PROGMEM const</code></pre> <p>and I assumed that put all data declared as PROGMEM in flash. </p> http://forums.leaflabs.com/topic.php?id=1481#post-9101 Sat, 17 Mar 2012 05:49:02 +0000 manitou 9101@http://forums.leaflabs.com/ <p>You probably have enough RAM to get rid of PROGMEM ... but here's the info from the FAQ<br /> <a href="http://leaflabs.com/docs/arm-gcc.html#arm-gcc-attribute-flash" rel="nofollow">http://leaflabs.com/docs/arm-gcc.html#arm-gcc-attribute-flash</a><br /> Lots of earlier discussions on forum regarding PROGRMEM ... </p> http://forums.leaflabs.com/topic.php?id=1481#post-9077 Sat, 17 Mar 2012 05:33:10 +0000 RichardE 9077@http://forums.leaflabs.com/ <p>Update: If I wrap the character set data up as static members of a class like this:</p> <pre><code>/* * SOURCE FILE : RobotRicCharacterSet.h * * Contains character set data for RobotRic game. * */ #ifndef RobotRicCharacterSetIncluded #define RobotRicCharacterSetIncluded #include &lt;GD.h&gt; class RobotRicCharacterSet { public : static PROGMEM prog_uchar PixelData[]; static PROGMEM prog_uchar PaletteData[]; }; #endif /* END of RobotRicCharacterSet.h */</code></pre> <p>then I don't get the errors. Weird. </p> http://forums.leaflabs.com/topic.php?id=1481#post-9059 Sat, 17 Mar 2012 05:21:19 +0000 RichardE 9059@http://forums.leaflabs.com/ <p>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.</p> <p>Seem to have hit a snag when referencing data declared as extern. Here's a test program I wrote:</p> <p>*** File TestCharset.pde ***<br /> <pre><code>#include &lt;GD.h&gt; #include &quot;RobotRicCharacterSet.h&quot; #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 ) { }</code></pre> <p>*** File RobotRicCharacterSet.h ***<br /> <pre><code>#include &lt;GD.h&gt; extern PROGMEM prog_uchar RobotRicCharacterSetPixelData[]; extern PROGMEM prog_uchar RobotRicCharacterSetPaletteData[];</code></pre> <p>*** File RobotRicCharacterSet.cpp (edited for brevity) ***<br /> <pre><code>#include &lt;GD.h&gt; 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 (ÿ) };</code></pre> <p>As it stands the test program compiles OK. If I uncomment the lines calling GD.copy I get the message :</p> <p>&lt;BUILD&gt;/TestCharset.cpp:19: undefined reference to `RobotRicCharacterSetPixelData'<br /> &lt;BUILD&gt;/TestCharset.cpp:19: undefined reference to `RobotRicCharacterSetPaletteData'</p> <p>What's going on? How come it can find them when I don't call GD.copy but it cannot when I do?</p> <p>Note: GD.h is James Bowman's work from here : <a href="http://excamera.com/files/Gameduino_m.zip" rel="nofollow">http://excamera.com/files/Gameduino_m.zip</a></p> <p>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.</p> <p>Any help appreciated. </p>