Re: Assigning data structures to certain memory locations during porting
From: pieter (pieter_at_gmail.com)
Date: 03/04/05
- Next message: Bob McConnell: "Re: WLAN<->serial converter"
- Previous message: Josias R. P. Langoni: "Re: Comments on RTOSes"
- In reply to: Darin Johnson: "Re: Assigning data structures to certain memory locations during porting"
- Next in thread: Ark: "Re: Assigning data structures to certain memory locations during porting"
- Reply: Ark: "Re: Assigning data structures to certain memory locations during porting"
- Reply: Darin Johnson: "Re: Assigning data structures to certain memory locations during porting"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 3 Mar 2005 18:26:44 -0800
Thank you very much for your response, Darin.
I'm afraid this is still (at least right now) a little over my head. I
wonder if perhaps it would be better to ask for a good resource from
which I could learn this. I purchased a book on Programming Embedded
Systems in C and C++, but that didn't really discuss this area at all.
It does mention that global variables can be added to As I've said, I'm
still very new to embedded programming. I'm more or less trying
treading water if you will. A little background might also help here
(as I understand that I've described my problem rather unclearly). I am
aiming to accomplish this task in C using the gcc compiler. I imagine
the compiler part doesn't really matter too much in this discussion.
Regarding your statement:
"Dynamically allocating and freeing memory is often discouraged in
embedded systems; instead one approach is to try and allocate
everything that will be needed once during startup, and this way
there's no possibility of running ouf of memory later on."
I thought the primary reason for dynamic allocation was to allocate
just the amount of memory you need to store certain entities, such as
arrays or strings whose length is not usually known until run-time? For
example, suppose the algorithm I'm porting is an mpeg encoder. In this
case, the size of the frames and number of frames won't be known until
I begin to examine the stream, right?
Finally, your discussion on memory pools is very interesting. Because
I'm such a novice in this area I'd really like to know more about this.
Any good books, web sites, or documents you can point me to here?
Sincerely,
Pieter
PS: Thanks again for all of this help, Darin. I've been having such a
hard time getting answers for this stuff ...
Darin Johnson wrote:
> "pieter" <pieter@gmail.com> writes:
>
> > Similarly then, I wish to allocate memory for data
> > structure B in the DRAM, and then again dynamically allocate data
> > structure C to Flash Memory. How do I accomplish this?
>
> The simple answer is that you call the routine that someone
> has already written for this purpose! Either someone on your
> team or the RTOS vendor. If that person happens to be you,
> then you get to learn how to pitch your own tent. But your
> question is a bit vague, and there are different answers
> depending upon what you really need.
>
> There are a few issues here. First, if the data is a constant
> (in the Flash or ROM) then there's no need to allocate it except
> at compile/link time. How to do this depends upon your compiler,
> but it probably involves a pragma in C. Otherwise you could
> just assign a constant to the necessary pointer, as in:
> mystruct *foo = (mystruct*)0x4008;
> (or in C++ you can use a "placement new");
>
> If you really need to grab some stuff at run time, then another
> issue is whether or not you need to free the memory. Freeing
> memory complicates things. Dynamically allocating and freeing
> memory is often discouraged in embedded systems; instead one
> approach is to try and allocate everything that will be needed
> once during startup, and this way there's no possibility of
> running ouf of memory later on.
>
> If freeing isn't necessary, then you can have a simple routine
> that just returns the next free area in a particular region.
> For instance:
> char* scratchpad_alloc(uint size)
> {
> last_free += aligned(size);
> if (last_free > scratchpad_max) { error... }
> return (last_free - size);
> }
>
> The common way to have memory that is allocated and freed is to use
> pools. The pool is just a preallocated chunk of memory which is
> subdivided into fix sized blocks. An allocation from the pool
returns
> one of the blocks; every allocation from a pool returns an item of
the
> same size. Freeing the block just adds it back to the pool. This is
> very fast and very simple.
>
> --
> Darin Johnson
> Support your right to own gnus.
- Next message: Bob McConnell: "Re: WLAN<->serial converter"
- Previous message: Josias R. P. Langoni: "Re: Comments on RTOSes"
- In reply to: Darin Johnson: "Re: Assigning data structures to certain memory locations during porting"
- Next in thread: Ark: "Re: Assigning data structures to certain memory locations during porting"
- Reply: Ark: "Re: Assigning data structures to certain memory locations during porting"
- Reply: Darin Johnson: "Re: Assigning data structures to certain memory locations during porting"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|