LeafLabs Garden » User Favorites: RichardE

LeafLabs Garden » User Favorites: RichardE 4436 A place to share, learn, and grow... en-US Fri, 22 Jan 2016 00:22:04 +0000 http://bbpress.org/?v=1.0.2 <![CDATA[Search]]> q http://forums.leaflabs.com/search.php mbolivar on "Strange errors when using `new` to allocate a pointer." http://forums.leaflabs.com/topic.php?id=161#post-12075 Fri, 27 Jul 2012 18:17:54 +0000 mbolivar 12075@http://forums.leaflabs.com/ You're absolutely right. Strange; I swear this was working for v0.0.12; we used it in the Maple Native guitar effects demo. In any case, this was fixed in <a href="https://github.com/leaflabs/libmaple/commit/c4e08477202d31149510262a1fd52a09e3e71337">libmaple c4e0847</a> by adding an abort() implementation. You can either take that approach, or just use your workaround. The fix will be part of the next release. Sorry for the mistake. shark2600 on "Strange errors when using `new` to allocate a pointer." http://forums.leaflabs.com/topic.php?id=161#post-12074 Fri, 27 Jul 2012 17:17:17 +0000 shark2600 12074@http://forums.leaflabs.com/ No, a 'new' will create the same error. Try a simple piece of code, with 'new' operator, say creating a pointer of integer. You will see the same undefined reference error mbolivar on "Strange errors when using `new` to allocate a pointer." http://forums.leaflabs.com/topic.php?id=161#post-12071 Fri, 27 Jul 2012 16:40:49 +0000 mbolivar 12071@http://forums.leaflabs.com/ Thanks for the report. I've never tested the STL classes, so it's good to know you got vector working. Just guessing, but it sounds like the issue isn't with new/delete, but that the std::vector constructor or destructor is calling those routines, which we don't provide by default. shark2600 on "Strange errors when using `new` to allocate a pointer." http://forums.leaflabs.com/topic.php?id=161#post-12019 Thu, 26 Jul 2012 01:32:08 +0000 shark2600 12019@http://forums.leaflabs.com/ Hi mbolivar, I'm using v0.0.12, the 'new' and 'delete' operators still not working. I have to put dummy _exit, _kill and _getpid() in syscalls.c to get them work, any suggestion? FYI: I added the following to \maple-ide-0.0.12-windowsxp32\hardware\leaflabs\cores\maple\syscalls.c to get new and delete work. The reason why I need this is I need stl::vector and so on support in my project. Thanks /* * getpid -- only one process, so just return 1. */ #define __MYPID 1 int _getpid() { return __MYPID; } /* * kill -- go out via exit... */ int _kill(int pid, int sig) { return -1; } int _exit(int val) { return (-1); } mbolivar on "Strange errors when using `new` to allocate a pointer." http://forums.leaflabs.com/topic.php?id=161#post-10497 Sat, 05 May 2012 23:28:29 +0000 mbolivar 10497@http://forums.leaflabs.com/ RichardE: Dynamic memory should work as of v0.0.12. Can you present a program that doesn't work as expected? Edit: Fix typo. Also see: <a href="http://leaflabs.com/docs/faq.html#how-can-i-use-malloc-new" rel="nofollow">http://leaflabs.com/docs/faq.html#how-can-i-use-malloc-new</a> RichardE on "Strange errors when using `new` to allocate a pointer." http://forums.leaflabs.com/topic.php?id=161#post-10301 Sat, 21 Apr 2012 14:04:23 +0000 RichardE 10301@http://forums.leaflabs.com/ I take your point. It is hard to do and there are certainly dangers of memory leaks, but I still think that beyond a certain minimum RAM size dynamic memory allocation is important and becomes less important as the RAM size increases. The program I am working on at the moment is an example. You could argue that this is not an embedded program at all. I started on the Arduino with a Gameduino shield (truly awesome shield which works fine with the Maple - buy one even if you have no intention of writing games) and started writing a clone of the Robotron arcade game. It went very well. Every level has a number of enemies that can be of a number of different types. All enemies are implemented as classes derived from a common base class (EnemyObject). At the start of every level you read counts for the number of enemies of each type and then dynamically allocate memory for each enemy. When the level ends you delete all the enemies freeing up memory so the next level can re-use it. Eventually, even sticking as much as possible in program memory, RAM started to get a bit tight (Arduino only has 2K) so I bought a Maple and started porting the code. Then I realised there was no dynamic memory allocation. The simplest way around this is to declare arrays containing all the enemies you will need, for all levels but this is staggeringly wasteful. Suppose you are allowed a maximum number of 10 enemies of a particular type on each level. Then you need 10 arrays with 10 of enemy type A, 10 of enemy type B, 10 of enemy type C and so on. These are occupying RAM all the time, even when no enemies of a particular type appear in a level so you are bound to run out of memory sooner rather than later. Eventually I got around this by allocating memory on the stack. Each level is a class with a PlayLevel method. The PlayLevel method creates a lot of enemy arrays as *local* variables and then calls a method in a base class that runs around the game loop until the level ends, passing these enemy arrays to the method. When the level ends and PlayLevel finishes all the array vanish as they are local variables. It works, but it is rather cumbersome and in the end I had to write a C# program to generate the source code for each level. It would be so much easier if I could allocate memory dynamically. gbulmer on "Problem with external PROGMEM data." http://forums.leaflabs.com/topic.php?id=1481#post-9820 Sun, 18 Mar 2012 15:58:56 +0000 gbulmer 9820@http://forums.leaflabs.com/ 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. <blockquote>is __FLASH__ the only way to put data in program memory? </blockquote> Under the covers, there are several types of memory segment, or section, which get stored in Flash. If you look at the definition: <code>#define __FLASH__ __attr_flash</code> which leads to <code>#define __attr_flash __attribute__((section (".USER_FLASH")))</code> You can see one, but there is also <code>.text</code> which contains all of the program code, usually <code>.ro_data</code>, 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. <blockquote>If you declare data as const will that not do it? </blockquote> In general <code>const</code> 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, <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. 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). (Full disclosure: I am not a member of leafLabs staff) gbulmer on "Strange errors when using `new` to allocate a pointer." http://forums.leaflabs.com/topic.php?id=161#post-9817 Sun, 18 Mar 2012 15:19:38 +0000 gbulmer 9817@http://forums.leaflabs.com/ RichardE - It is quite unusual for embedded programs to use dynamic memory. I strongly agree dynamic allocation and garbage collection are very useful and valuable features, but I don't agree that it is more important when RAM is scarce. The main problems are: 1. It is extremely hard to test a program of even moderate complexity, and know that under all circumstances it will not run out of memory and break. Dynamic allocation makes this worse than simple static allocation and stack frames. This is a 'show stopper' for some developers. 2. Having managed memory can consume quite a lot of RAM in various overheads or fragmentation. This waste can be in the form of management overhead (which is needed to be able to manage memory), 'internal' fragmentation, and 'external' fragmentation. Typically the smallest block that can be managed is some minimum-size because it needs to have a pointer to other blocks (4 bytes), and extra management typically the size of the block. The size must be held somewhere, so the correct size of block can always be recovered by free. Maybe we limit this to a 2 bytes. So say 6 bytes are used in every block of memory for management. Not too bad if user-objects are large, but very bad if user-objects are small. The block might need to be aligned for the worst case data type (maybe an 8 byte double), which may make it impossible to use blocks smaller than 8 bytes. To make things easier to manage, it is common to allocate memory in multiples of minimum-size. So if the whole block isn't full, the space is wasted. If the minimum block size were 8-bytes, then, on average 4 bytes would be wasted. That is 'internal' fragmentation - there is unused space, but you can't give it to the user's program because it can't be managed. As blocks are freed, and then reallocated in random patterns, free space will appear between the other blocks which are in use. In languages like Java or Python, this can be solved, because the Java/Python VM could move the used blocks around to collect together the unused space. Normally in C or C++, those used blocks can't be moved. So there may be enough total free space to satisfy a new request, but because it is fragmented by in-use blocks, the request can't be satisfied. That type of wasted space is often called external fragmentation. Summary: 1. It is hard to test programs and know memory fragmentation will not cause them to fail 2. Memory management and garbage collection have overhead, and can't always make good use of RAM dues to fragmentation. HTH RichardE on "Strange errors when using `new` to allocate a pointer." http://forums.leaflabs.com/topic.php?id=161#post-9134 Sat, 17 Mar 2012 06:13:22 +0000 RichardE 9134@http://forums.leaflabs.com/ Arduino 1.0 does now support dynamic memory allocation. You could argue that dynamic memory allocation is more important than ever on a device with limited memory. It means you can re-use the memory more easily at different points in your program. Without it your variables waste memory even when not being used. Slightly disappointed this isn't supported. RichardE on "Problem with external PROGMEM data." http://forums.leaflabs.com/topic.php?id=1481#post-9116 Sat, 17 Mar 2012 06:01:26 +0000 RichardE 9116@http://forums.leaflabs.com/ 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 : <pre><code>#define PROGMEM const</code></pre> and I assumed that put all data declared as PROGMEM in flash. manitou on "Problem with external PROGMEM data." http://forums.leaflabs.com/topic.php?id=1481#post-9101 Sat, 17 Mar 2012 05:49:02 +0000 manitou 9101@http://forums.leaflabs.com/ You probably have enough RAM to get rid of PROGMEM ... but here's the info from the FAQ <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> Lots of earlier discussions on forum regarding PROGRMEM ... RichardE on "Problem with external PROGMEM data." http://forums.leaflabs.com/topic.php?id=1481#post-9077 Sat, 17 Mar 2012 05:33:10 +0000 RichardE 9077@http://forums.leaflabs.com/ Update: If I wrap the character set data up as static members of a class like this: <pre><code>/* * 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 */</code></pre> then I don't get the errors. Weird. RichardE on "Problem with external PROGMEM data." http://forums.leaflabs.com/topic.php?id=1481#post-9059 Sat, 17 Mar 2012 05:21:19 +0000 RichardE 9059@http://forums.leaflabs.com/ 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 *** <pre><code>#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 ) { }</code></pre> *** File RobotRicCharacterSet.h *** <pre><code>#include <GD.h> extern PROGMEM prog_uchar RobotRicCharacterSetPixelData[]; extern PROGMEM prog_uchar RobotRicCharacterSetPaletteData[];</code></pre> *** File RobotRicCharacterSet.cpp (edited for brevity) *** <pre><code>#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 (ÿ) };</code></pre> 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 : <a href="http://excamera.com/files/Gameduino_m.zip" rel="nofollow">http://excamera.com/files/Gameduino_m.zip</a> 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. poslathian on "Strange errors when using `new` to allocate a pointer." http://forums.leaflabs.com/topic.php?id=161#post-1077 Tue, 07 Sep 2010 15:54:48 +0000 poslathian 1077@http://forums.leaflabs.com/ For some odd reason the "new" and "delete" keywords are highlighted in arduino/maple ide. We will fix this! Amir Hadzic on "Strange errors when using `new` to allocate a pointer." http://forums.leaflabs.com/topic.php?id=161#post-1057 Tue, 07 Sep 2010 04:16:00 +0000 Amir Hadzic 1057@http://forums.leaflabs.com/ You'r right, I don't need it really. I just thought it might be a bug :-)