malloc

CASTalk.com
Discussion of DSP, FPGA, storage and embedded system.

FAQ

Memberlist

Profile

malloc Goto page 1, 2, 3 Next

CASTalk.com Forum Index -> DSP

Author

Message

Simone Winkler
Guest

Posted: Mon Jan 03, 2005 2:14 am Post subject: malloc

Hello, I'm developping code for a C6713 DSP (actually it's the D.SignT-module with the C6713 on it). I'm trying to use malloc() but it doesn't seem to work. In the beginning I always received a null pointer. After a long while of searching my mistake I detected the section in the DSP/BIOS configuration for malloc(). I pointed it to SBSRAM and to SDRAM but both solutions didnt work - in the end I got an error that told me that I tried to read data from memory location ... in L2. The command I use simply says "malloc(1)" - just to try... At the moment I'm using the emulator because I can't run the board at home, but I think this cannot be the problem. Can you help me? Thank you, Simone

Tom Derham
Guest

Posted: Mon Jan 03, 2005 2:30 am Post subject: Re: malloc

Quote:

I'm developping code for a C6713 DSP (actually it's the D.SignT-module
with the C6713 on it).
I'm trying to use malloc() but it doesn't seem to work. In the beginning I
always received a null pointer. After a long while of searching my mistake
I detected the section in the DSP/BIOS configuration for malloc(). I
pointed it to SBSRAM and to SDRAM but both solutions didnt work

Have you created a heap in the MEM section (e.g. SDRAM) where you want the
allocation to take place? You need to enter a valid heap size, set the
memory space to data or code/data, and I think also put the same value in
the linker heap size setting (in Build Options, assuming you're using CCS)

Tom

karol kluska
Guest

Posted: Mon Jan 03, 2005 3:41 am Post subject: Re: malloc

On Sun, 2 Jan 2005 22:14:17 +0100, "Simone Winkler"
<simone.winkler@gmx.at> wrote:

Quote:

I'm developping code for a C6713 DSP (actually it's the D.SignT-module with
the C6713 on it).
I'm trying to use malloc() but it doesn't seem to work. In the beginning I
always received a null pointer. After a long while of searching my mistake I
detected the section in the DSP/BIOS configuration for malloc().

?? as far as I know you are not supposed to use malloc while using
DSP/BIOS - with DSP/BIOS there are some functions MEM_alloc or
something like that to manage memory - you can't use the "ordinary"
malloc!!

but then - what do I know?

Simone Winkler
Guest

Posted: Mon Jan 03, 2005 4:37 am Post subject: Re: malloc

Quote:

As far as I know, malloc uses MEM_alloc with seg_id of 1 (or similar...).
I'm not quite sure!

Thank you,

Simone

Charles Krug
Guest

Posted: Wed Jan 05, 2005 7:16 pm Post subject: Re: malloc

On Sun, 02 Jan 2005 23:41:26 +0100, karol kluska <adres15@op.pl> wrote:

Quote:

On Sun, 2 Jan 2005 22:14:17 +0100, "Simone Winkler"
simone.winkler@gmx.at> wrote:

I'm developping code for a C6713 DSP (actually it's the D.SignT-module with
the C6713 on it).
I'm trying to use malloc() but it doesn't seem to work. In the beginning I
always received a null pointer. After a long while of searching my mistake I
detected the section in the DSP/BIOS configuration for malloc().

?? as far as I know you are not supposed to use malloc while using
DSP/BIOS - with DSP/BIOS there are some functions MEM_alloc or
something like that to manage memory - you can't use the "ordinary"
malloc!!

but then - what do I know?

You can use malloc if your memory configuration supports it. The C
Compiler Reference for the 'c6x family discusses this at some length.

When I was working with TI chips, I tended to avoid malloc, because all
of my data was really static at the end of the day, though occasionally
it was required for other reasons.

See if maybe some "non embedded system" thinking is creeping into your
brain. It's quite a different mindset from general applications
programming.

Jerry Avins
Guest

Posted: Wed Jan 05, 2005 9:41 pm Post subject: Re: malloc

Simone Winkler wrote:

Quote:

Hello,

I'm developping code for a C6713 DSP (actually it's the D.SignT-module with
the C6713 on it).
I'm trying to use malloc() but it doesn't seem to work. In the beginning I
always received a null pointer. After a long while of searching my mistake I
detected the section in the DSP/BIOS configuration for malloc(). I pointed
it to SBSRAM and to SDRAM but both solutions didnt work - in the end I got
an error that told me that I tried to read data from memory location ... in
L2. The command I use simply says "malloc(1)" - just to try...
At the moment I'm using the emulator because I can't run the board at home,
but I think this cannot be the problem.

Can you help me?

Thank you,
Simone

Maybe you can help me to understand how malloc() might be used in an
embedded system. I assume that there is no virtual memory (swapping to
disk) available, and that the routines to be run use fixed-size arrays
and buffers. It is never necessary to allocate memory unless it will
also be de-allocated later. Although I have sometimes needed to use the
same memory space sequentially for different routines, I've never
encountered a situation that prevented me from allocating all the space
I needed at compile time. What would you use malloc() for?

Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

karol kluska
Guest

Posted: Wed Jan 05, 2005 9:48 pm Post subject: Re: malloc

On Wed, 05 Jan 2005 11:41:49 -0500, Jerry Avins <jya@ieee.org> wrote:

Quote:

I've never
encountered a situation that prevented me from allocating all the space
I needed at compile time. What would you use malloc() for?

If man wasn't meant to eat animals, they wouldn't be made out of food.

if it wasn't needed - malloc would not be included in embedded libc
ports - right? ;-)

Jerry Avins
Guest

Posted: Wed Jan 05, 2005 10:12 pm Post subject: Re: malloc

karol kluska wrote:

Quote:

On Wed, 05 Jan 2005 11:41:49 -0500, Jerry Avins <jya@ieee.org> wrote:

I've never
encountered a situation that prevented me from allocating all the space
I needed at compile time. What would you use malloc() for?

If man wasn't meant to eat animals, they wouldn't be made out of food.

if it wasn't needed - malloc would not be included in embedded libc
ports - right? ;-)

Did I seem to imply that malloc() shouldn't be used? If so, I wasn't
clear. I asked how it might be used, i.e., what makes it useful.

Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

karol kluska
Guest

Posted: Wed Jan 05, 2005 10:27 pm Post subject: Re: malloc

On Wed, 05 Jan 2005 12:12:33 -0500, Jerry Avins <jya@ieee.org> wrote:

Quote:

I've never
encountered a situation that prevented me from allocating all the space
I needed at compile time. What would you use malloc() for?

If man wasn't meant to eat animals, they wouldn't be made out of food.

if it wasn't needed - malloc would not be included in embedded libc
ports - right? ;-)

Did I seem to imply that malloc() shouldn't be used? If so, I wasn't
clear. I asked how it might be used, i.e., what makes it useful.

well... I did reply kind of "jokingly" at first... but now - maybe
somebody will make one thing clear for me too...

imagine a cell phone... there is a DSP chip in it that performs voice
encoding/decoding - lets say the phone is using codec A...

there is another cell phone with another DSP chip in it... that one is
using codec B (A and B are different coding methods = different
codecs)

now - imagine a "base station" that the above cell phones are talking
to - that base station has to be able to understand both (or n in
general) coding techniques - it's done by running different software
on the same DSP chip - everything happens "on the fly" - the DSP chip
in the base station is dynamicaly choosing which coding technique to
use - without reseting the chip of course... oh... and let's say there
are only resources to run 1 codec at a time... is there a need for
malloc/delete?

but then - what do I know? I've never done anything with the cell
phones (except using them rarely) or even "wireless technology" in
general...

so - please - all the specialists out there - does the above example
make any sense to you? or is it the other way around? is it the
cell-phone rather than the base station that implements multiple
codecs? or is there just one standard coding method use for the whole
GSM system?

and please excuse me my language problems...

have a nice day everybody...

glen herrmannsfeldt
Guest

Posted: Wed Jan 05, 2005 10:36 pm Post subject: Re: malloc

Jerry Avins wrote:
(snip regarding malloc() and DSP programming)

Quote:

Maybe you can help me to understand how malloc() might be used in an
embedded system. I assume that there is no virtual memory (swapping to
disk) available,

Well, dynamic storage allocation was in use on machines without
virtual memory for many years. OS/360 for one example.

Quote:

and that the routines to be run use fixed-size arrays and buffers.

Now, this is the question. If they are fixed size static allocation
is likely best. (Some non-DSP systems have problems doing large static
allocation, but that is a different question.)

Quote:

It is never necessary to allocate memory unless it will
also be de-allocated later.

It is also nice when you don't know the size initially, and
also don't know the available memory on the machine it will
run on. In that case, it may only be deallocated when the
program is done.

For the DSP case using a C #define so that it can
be recompiled with a machine specific size may also work.

Quote:

Although I have sometimes needed to use the
same memory space sequentially for different routines, I've never
encountered a situation that prevented me from allocating all the space
I needed at compile time. What would you use malloc() for?

In the old Fortran days EQUIVALENCE was used to give more than one
name to the same (statically allocate) storage. That allowed one
to conserve memory without making it too ugly. As many Fortran
systems only did static allocation, one would declare arrays large
enough for the largest case.

If the target is a dedicated device with a known amount of storage,
and always performing the same function I have to agree that static
allocation should be fine. To use memory sequentially for different
routines when the size for each is not known at compile time
it can still be useful to have malloc().

The original K&R C book (and maybe the second edition) have as an
example a malloc() that uses a static array to allocate from.

-- glen

Jerry Avins
Guest

Posted: Wed Jan 05, 2005 11:03 pm Post subject: Re: malloc

karol kluska wrote:

...

Quote:

imagine a cell phone... there is a DSP chip in it that performs voice
encoding/decoding - lets say the phone is using codec A...

there is another cell phone with another DSP chip in it... that one is
using codec B (A and B are different coding methods = different
codecs)

now - imagine a "base station" that the above cell phones are talking
to - that base station has to be able to understand both (or n in
general) coding techniques - it's done by running different software
on the same DSP chip - everything happens "on the fly" - the DSP chip
in the base station is dynamicaly choosing which coding technique to
use - without reseting the chip of course... oh... and let's say there
are only resources to run 1 codec at a time... is there a need for
malloc/delete?

...

How would you use it? Presumably, when you release memory holding the
code for one codec, you have to bring in the software for the other.
Where might that come from? Let's assume that we transfer it from slow
ROM to fast RAM. Why is allocate/deallocate needed? Why not just
overwrite the old codec code?

Anyway, in a base station, wouldn't it make sense to just provide enough
memory for the whole job? The change-over time from codec to codec
probably wouldn't be acceptable.

Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

Jerry Avins
Guest

Posted: Wed Jan 05, 2005 11:17 pm Post subject: Re: malloc

glen herrmannsfeldt wrote:

Quote:

Jerry Avins wrote:
(snip regarding malloc() and DSP programming)

Maybe you can help me to understand how malloc() might be used in an
embedded system. I assume that there is no virtual memory (swapping to
disk) available,

Well, dynamic storage allocation was in use on machines without
virtual memory for many years. OS/360 for one example.

and that the routines to be run use fixed-size arrays and buffers.

Now, this is the question. If they are fixed size static allocation
is likely best. (Some non-DSP systems have problems doing large static
allocation, but that is a different question.)

It is never necessary to allocate memory unless it will
also be de-allocated later.

It is also nice when you don't know the size initially, and
also don't know the available memory on the machine it will
run on. In that case, it may only be deallocated when the
program is done.

For the DSP case using a C #define so that it can
be recompiled with a machine specific size may also work.

Although I have sometimes needed to use the
same memory space sequentially for different routines, I've never
encountered a situation that prevented me from allocating all the space
I needed at compile time. What would you use malloc() for?

In the old Fortran days EQUIVALENCE was used to give more than one
name to the same (statically allocate) storage. That allowed one
to conserve memory without making it too ugly. As many Fortran
systems only did static allocation, one would declare arrays large
enough for the largest case.

If the target is a dedicated device with a known amount of storage,
and always performing the same function I have to agree that static
allocation should be fine. To use memory sequentially for different
routines when the size for each is not known at compile time
it can still be useful to have malloc().

The original K&R C book (and maybe the second edition) have as an
example a malloc() that uses a static array to allocate from.

Glen,

I know how to use malloc(). I'm one of those uptight programmers who
even checks to be sure it succeeds instead of simply assuming it. I have
made liberal use of EQUIVALENCE statements not only to conserve storage,
but to do sneaky type conversion. In C, I use UNIONs the same way.

My question was about using malloc() in code for embedded systems with
no off-line storage and all other resources known at coding time. The
only reasons I can think of are not complementary. If there are good
reasons, I'd like to know them.

Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

Tim Wescott
Guest

Posted: Wed Jan 05, 2005 11:46 pm Post subject: Re: malloc

Jerry Avins wrote:

Quote:

Simone Winkler wrote:

Hello,

I'm developping code for a C6713 DSP (actually it's the D.SignT-module with
the C6713 on it).
I'm trying to use malloc() but it doesn't seem to work. In the beginning I
always received a null pointer. After a long while of searching my mistake I
detected the section in the DSP/BIOS configuration for malloc(). I pointed
it to SBSRAM and to SDRAM but both solutions didnt work - in the end I got
an error that told me that I tried to read data from memory location ... in
L2. The command I use simply says "malloc(1)" - just to try...
At the moment I'm using the emulator because I can't run the board at home,
but I think this cannot be the problem.

Can you help me?

Thank you,
Simone

Maybe you can help me to understand how malloc() might be used in an
embedded system. I assume that there is no virtual memory (swapping to
disk) available, and that the routines to be run use fixed-size arrays
and buffers. It is never necessary to allocate memory unless it will
also be de-allocated later. Although I have sometimes needed to use the
same memory space sequentially for different routines, I've never
encountered a situation that prevented me from allocating all the space
I needed at compile time. What would you use malloc() for?

Jerry

I have written library code for embedded systems that use malloc(). The
ground rules we operated under was that you could use malloc() at
startup to get necessary memory, but that you _never_ used free(). The
rational for using malloc() was because insisting on knowing array sizes
and whatnot would make the code significantly less reusable, with a
correlary that it would have been significantly harder to use one piece
of code to control two or more identical things (some of my motor
controller code happily controls three motors of two dissimilar types
out of the same set of C++ code, with user-added wrappers).

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Tim Wescott
Guest

Posted: Thu Jan 06, 2005 12:06 am Post subject: Re: malloc

karol kluska wrote:

Quote:

Did I seem to imply that malloc() shouldn't be used? If so, I wasn't
clear. I asked how it might be used, i.e., what makes it useful.

-- snip --

and please excuse me my language problems...

Sorry, you cannot be excused where you have not sinned. Were I able to
speak your native language better than you speak English, _then_ I could
get on your case.

Quote:

have a nice day everybody...

Allocating memory in a deeply embedded system carries the danger that
you may run out of memory. This is a very manageable problem, so
allocating memory doesn't cause that much pain. Deallocating memory out
of a heap, however, leaves you with a fragmented heap. It is painfully
common in systems without garbage collection to have heaps fragment and
the system fail.

There are a number of more or less valid methods for dealing with this.
You can not do it at all, forcing yourself into only using fixed-size
buffers and possibly circular buffers, but this may not work.

The safest way to actually use some form of dynamic allocation is to use
a pool of fixed-size buffers and allocate out of that. When you do this
your pool can be as fragmented as can be, but if there's a free buffer
you'll be able to get it. The down side is that you have to write your
code to cope with the buffer size, so data that comes in unpredictable
lengths will either consume unnecessary buffer space or will have to be
daisy-chained together (and the chains deallocated gracefully).

The next safest way that I know of is to use multiple heaps, separated
by priority or by the sizes of the chunks. I view this method with deep
suspicion, and have not used it.

The last method, that I _have_ used with success, is to only use a heap
in a context where there will be somebody standing by to cycle power.
In this case I've used it for a service interface to handle sending
multiple streams to one terminal. The heap is used, and can fragment,
but if it does the worst that will happen is that a service guy or an
engineer will utter a mild oath before hitting reset.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

glen herrmannsfeldt
Guest

Posted: Thu Jan 06, 2005 2:08 am Post subject: Re: malloc

Jerry Avins wrote:

Quote:

glen herrmannsfeldt wrote:

(snip)

Quote:

I know how to use malloc(). I'm one of those uptight programmers who
even checks to be sure it succeeds instead of simply assuming it. I have
made liberal use of EQUIVALENCE statements not only to conserve storage,
but to do sneaky type conversion. In C, I use UNIONs the same way.

My question was about using malloc() in code for embedded systems with
no off-line storage and all other resources known at coding time. The
only reasons I can think of are not complementary. If there are good
reasons, I'd like to know them.

I tried not to disagree too much. I think there are uses, but
the reasons are weak. One doesn't require virtual memory,
and conserving memory is probably more important for real memory.

Consider a laser printer, a nice dedicated system that does the same
thing all day long. Many printers allow one to add additional RAM.
At power up it determines the available RAM and allocates it
accordingly. Once allocated it might never be free()d. The code
will be more readable calling a routine called malloc() (or any other
name one would like). It could be done other ways, but the code
would be much less readable.

Postscript does do dynamic allocation. A routine called malloc() may
or may not be a good way to do it in a Postscript (or compatible)
printer.

For the most part, I agree with you, but I think there are some exceptions.

-- glen

	CASTalk.com Forum Index -> DSP	All times are GMT Goto page 1, 2, 3 Next
Page 1 of 3

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum