What do you think about dynamic memory allocation?

I wanted to hear opinions on the subject for HCS12 (at least 12 KBytes RAM chips and bigger). - Is somebody using it on HCS12 chips? - How efficient it is (address space utilization and execution speed)? - In general for embedded application (I understand, this depends on application very much, but anyways): how severe is the fragmenation problem? - What do you think about malloc/free functions of CodeWarrior? I am thinking to use dynamic memory allocation for FreeRTOS port (http://www.freertos.org) in order to allow tasks creation and removal. P.S. Sorry, this cross-posted to gnu-m68hc11. Thank you in advance, Uri

Re: What do you think about dynamic memory allocation?
Re: What do you think about dynamic memory allocation?
Re: What do you think about dynamic memory allocation?
Re: What do you think about dynamic memory allocation?
Re: What do you think about dynamic memory allocation?
Start a New Thread

Uri, I don't recommend using the expanded bus on the HCS12 family. The HCS12 is really designed to be used mainly in Single-Chip applications. Its use of the external bus is not user friendly, and there are several timing (potential negative hold times) that need to overcome in order to form a stable external mode design. You would need a lot of specific experience with the HCS12 bus to resolve these issues in advance. If you like you can read a detailed article on Expanded-Mode use of HCS12 that I wrote, and is available on the Nohau web-site (link below in the signature). As an alternative I would recommend the newer S12X family (MC9S12XDP512) for external mode designs. the S12X external bus is much more user friendly and easy to implement for expanded mode use (no ugly timing in Normal Expanded mode either). It has much less problems in referencing very large RAMs (up to MBytes in size) with the help of the S12X new GPAGE register, or even better using the RPAGE register through the RPAGE window . The S12X also has many other silicon improvements over the HCS12 family, and especially for rapid performance increase: It executes to 40MHz bus-speed (vs 25MHz on HCS12), has an improved instruction set as compared to the HCS12 family, and a new, second co-processor named XGate that executes at 80MHz bus speed and is very efficient in I/O intensive tasks. I saw benchmarks that give the S12X between 2 to 5 times performance increase compared to HCS12, and at about the same or even smaller price vs. HCS12 in a year or two. If you are a small customer you would have a problem in obtaining S12X samples now, as there are currently available only to large customers, mainly automotive. Samples to small customers should become available later this year. Through my experience with the S12X (designing emulator and BDM support for it) I am sure the S12X will create a lot of excitement on the list, once it becomes available to the general market. Hope this helps, Doron Nohau Corporation HC12 In-Circuit Emulators www.nohau.com/emul12pc.html At 11:12 31/01/2005 +0000, you wrote: >I wanted to hear opinions on the subject for HCS12 (at least 12 KBytes >RAM chips and bigger). > - Is somebody using it on HCS12 chips? > - How efficient it is (address space utilization and execution speed)? > - In general for embedded application (I understand, this depends on >application very much, but anyways): how severe is the fragmenation >problem? > - What do you think about malloc/free functions of CodeWarrior? > >I am thinking to use dynamic memory allocation for FreeRTOS port >(http://www.freertos.org) in order to allow tasks creation and removal. > >P.S. Sorry, this cross-posted to gnu-m68hc11. > >Thank you in advance, >Uri

Re: What do you think about dynamic memory allocation?
Start a New Thread

Personally I wouldn't use dynamic memory allocation under 32K of RAM, there is too much memory overhead if you need to allocate a lot of small chunks, and fragmentation is always a worry. However I don't have experience with CodeWarrior's ability to handle fragmentation, I would guess it isn't too bad. To try and reduce fragmentation I allocate new memory in one order and de-allocate the same memory reverse order as much as possible, leaving the least priority chunks of memory for last, or ones that are frequently allocated/freed. This will reduce fragmentation problems. On a smaller processor I would instead use global memories and scratchpad memories and have flags assigned for various states of use for the scratchpads. If you treat scratchpad like a book from a library, then it is easier to manage. Now the overhead is for programming and debugging, but once finished you have a very reliable program with no worries for running out of heap due to fragmentation or over-allocation. You can wrap your memory accesses as; takeOutBook(), isBookTakenOut(), fillBook(), copyBook(), defragmentLibrary(), and returnBook() to make it very easy to use; these routines would handle the flags, and return available memory chunks for use (books). It may take a day or two to write the routines, but it will make much more sense on a small processor. I would use perhaps 10K of RAM in your case as an entire scratchpad area, and then perhaps assign 16 "books" to this area, which would consist of an address of the start of memory, a flag for the state, and a size. When you take out a book, you request a certain amount of memory, and your book handlers would return a structure pointer that has the book description if available or NULL if not, much like malloc(). The next time you try and take out a book, your handler would see if it had enough memory in one contiguous piece and return it, and if not, see if there are a sum of fragments that can fulfill the request. If there are fragments that can, you can then have a de-fragment routine run that sends all memory in use to one end of the scratch area and update the structures (books). The only thing is you have to remember to write routines that deal with the "books" in a way that you always use the memory pointer in the book like it will change because of the de-fragmentation process. Easy unless you try and allocate books in interrupts that alter the pointers while you are in the middle of doing something else. In that case you would need another flag to lock the library to prevent a de-fragment when you cannot allow it. I have written similar things to this that have worked very well for "pseudo - dynamic" memory access. You are just stuck with the maximum number of books you specify, which isn't a big deal unless you get into the 50+ range. There are many ways to deal with this, and I am sure some people have even better ideas, but this may get you started rather than relying on malloc() and free(). Example structs to set up your "books": #define MAX_NUM_BOOKS 16 #define LIBRARY_SIZE 10240 struct myMemoryBook { void *pStartAddress; unsigned int size; char flags; //Set char flags last in case of "padding" } myMemoryBook; struct library { struct myMemoryBook book[MAX_NUM_BOOKS]; char scratch[LIBRARY_SIZE]; char lockedFlag; } library; /* global declaration of the scratchpad */ extern struct library myLibrary; -Mark W _____ From: urk1254 [mailto:] Sent: Monday, January 31, 2005 6:13 AM To: Subject: [68HC12] What do you think about dynamic memory allocation? I wanted to hear opinions on the subject for HCS12 (at least 12 KBytes RAM chips and bigger). - Is somebody using it on HCS12 chips? - How efficient it is (address space utilization and execution speed)? - In general for embedded application (I understand, this depends on application very much, but anyways): how severe is the fragmenation problem? - What do you think about malloc/free functions of CodeWarrior? I am thinking to use dynamic memory allocation for FreeRTOS port (http://www.freertos.org) in order to allow tasks creation and removal. P.S. Sorry, this cross-posted to gnu-m68hc11. Thank you in advance, Uri _____ > Terms of Service.

Re: What do you think about dynamic memory allocation?
Re: What do you think about dynamic memory allocation?
Start a New Thread

In fact, I never have found any benefit of malloc in systems under 32K of ram because C is dynamically allocating local variables on the stack (I use GCC). If I call a function that has a local variable scratch[256] then it only uses that ram while in that function. Big difference from when I was doing Asm on the HC05, and used global variables for everything. --jeffs --- In , "Mark Wyman" <mark@r...> wrote: > Personally I wouldn't use dynamic memory allocation under 32K of RAM, there > is too much memory overhead if you need to allocate a lot of small chunks, > and fragmentation is always a worry. However I don't have experience with ...

Re: What do you think about dynamic memory allocation?
Start a New Thread