dynamic memory allocation _ microchip.pdf

8/16/2019 Dynamic memory allocation _ Microchip.pdf

http://slidepdf.com/reader/full/dynamic-memory-allocation-microchippdf 1/10

24/05/2016 Dynamic memory allocation | Microchip

http://www.microchip.com/forums/m114990.aspx

Mark Thread Unread • Flat Reading Mode ❐

Home » All Forums » [Development Tools] » MPLAB C18 Compiler » Dynamic memory allocation

Join us now! Log in

Prev Thread Next Thread

Dynamic memory allocation

Author Post

0

rbruce67

New Member

Total Posts : 10

Rew ard points : 0

Joined: 1/30/2004

Location: Kansas City, MO

Status: offline

#1

Guest

Page: 1 2 > • Showing page 1 of 2

Esse ntials Only Full Version

Dynamic memory allocation

Is dynamic memory allocation possible in C18? I notice a lack of functions in the *alloc

family, and that suggests "NO". Also, I don't see anything in the C18 manual or the C18

Libraries doc about memory allocation. I'm converting some microprocessor "c" code for

use on the PIC18F, and having dynamic allocation would save a bunch me rewriting time.

Thanks for your help.

Rob Bruce

Senior Engineer

Zeppelinware

www.zeppelinware.com

•

Thursday, September 22, 2005 0:53 PM (permalink)

Compile MPLAB X project by command line MPLAB C18 Student Edition

Build failure & Error message? compilation problem (MDDFS-SD-PIC18 Explorer Board-PIC18F…

how to find the memory profile from compiler compiled files, and… MDD Library PIC18F Error

Help could not find definition of symbol

After MakeoneDeviceE.bat Hardware UART not linking warning when using numbers

23 Replies • Related Threads

RE: Dynamic memory allocation Thursday, September 22, 2005 1:03 AM (permalink)

Forums Posts Page Extras Menu

Enter Search Phrase...

http://www.microchip.com/forums/default.aspx

http://www.microchip.com/forums/Forums

http://www.microchip.com/forums/f499.aspx

http://www.microchip.com/forums/



http://www.microchip.com/forums/rss-m114990.ashx

http://void%280%29/

http://void%28showmsgnum%28114992%29%29/

http://www.microchip.com/forums/Findpost/248515











http://www.zeppelinware.com/

http://www.microchip.com/forums/m114990-p2.aspx


http://void%280%29/


http://www.microchip.com/forums/Profile/22221/

http://www.microchip.com/forums/rss-m114990.ashx

http://www.microchip.com/forums/FindPost/114990?go=next

http://www.microchip.com/forums/FindPost/114990?go=prev


http://www.microchip.com/forums/login

http://www.microchip.com/forums/register





http://www.microchip.com/forums/#

http://www.microchip.com/forums/#




http://www.microchip.com/forums/m114990.aspx 2

0

#2

0

jtemples

Super Member

Total Posts : 9580

Rew ard points : 0

Joined: 2/14/2004

Location: Southern California

Status: offline

#3

0

jtemples

Super Member

Total Posts : 9580

Rew ard points : 0

Joined: 2/14/2004


Status: offline

#4

rbruce67

Just take the time to appreciate that the RAM 'memory' in a Harvard architecture like the

PIC is very different than other systems' RAM memory. In the PIC, the RAM is more like a

very large CPU register file (hence the term 'file register'). You never allocate this RAM for

placing program code, as in other systems. Program memory, when using a PIC18 in

microcontroller mode, is always FLASH memory or 'ROM'-like. Doing a malloc() in flash

makes little sense. The linker also does only static allocation due to very limited internal

RAM that you generally find on a PIC.

Now, if you are talking about external memory bus equipped models, then it's another

story. Perhaps you can implement malloc() and move compiled code around in external

memory, if the code is entirely runtime relocatable. Most C functions are.

•

malloc() has nothing to do with executable code; it is used for dynamic data memory

allocation.

•

It's possible, but you're on your own; malloc() is not provided with the library.

•



Is dynamic memory allocation possible in C18? ❝ ❞



http://%28void%280%29%29/

http://%28void%280%29%29/


http://%28void%280%29%29/

http://%28void%280%29%29/


http://%28void%280%29%29/

http://%28void%280%29%29/











0

New Member

Total Posts : 10

Rew ard points : 0

Joined: 1/30/2004


Status: offline

#5

0

rbruce67

New Member

Total Posts : 10

Rew ard points : 0

Joined: 1/30/2004


Status: offline

#6

0

magio

Super Member

Total Posts : 2164

Rew ard points : 0

Status: offline

#7

jtemples

I have been savoring the Harvard architecture for a while now, with its tasty divided data

and program space, and I believe that I am ready to consume some data memory at last.

The PIC I'm targetting (18F6722) has 3938 Bytes of data RAM, which seems almost

luxurious. Nevertheless, I had hoped to be able to allocate and de-allocate at runtime.

It's kind of looking like no *alloc functionality in C18 libraries.

Rob Bruce

Senior Engineer

Zeppelinware


•

Thanks. At least I'm not looking for something that's not there. If I'm successful in

creating malloc and free, I'll post them for the greater good.

Rob Bruce

Senior Engineer

Zeppelinware


•

malloc() functions as i understand it... requires an OS that will handle the 'free' of it.

You don't have an OS on the PIC, I think i've seen malloc () mentioned on some 'fastreading' on some places where they talk about OSes for PIC18xxx devices...

Embedded Software and Hardware Development

•



ORIGINAL: rbruce67

Thanks. At least I 'm not looking for something that's not there. If I 'm

successful in creating malloc and free, I'll post them for the greater good.

❝

❞



http://%28void%280%29%29/

http://%28void%280%29%29/


http://%28void%280%29%29/

http://%28void%280%29%29/


http://%28void%280%29%29/

http://%28void%280%29%29/

http://www.rdo-labs.com/













0

Super Member

Total Posts : 9580

Rew ard points : 0

Joined: 2/14/2004


Status: offline

#8

0

magio

Super Member

Total Posts : 2164

Rew ard points : 0

Status: offline

All malloc does is give you a pointer to a chunk of memory of the specified size. free()

returns that chunk of memory to the pool so a subsequent call to malloc() can reuse it.

You don't need an OS to do this. The reason it doesn't show up in C compilers for small

micros is that it's generally just not practical to use. When people want it, it's usually

because they're trying to port code from an existing application, not because they need or

want malloc() to solve their problem.

•

Yes, I understand that.

But, lets just go further and for example lets think that we have 50 bytes of RAM, and we

do the following example, where the numbers are decimal

1) Malloc(20) (unsigned char type) (from 0 to 19)

2) Malloc(15) (from 20 to 34)

3) Free(first block) (from 0 to 19). Then we have ocuppied from 20 to 34

4) Malloc(21) Sould give an error message although we have . This procedure should rise a

malloc() error, because of 'lack of contigous memory'. This could be accomplished if

'somehow' the malloc function or some 'depuration process' relocates the 2nd malloc

block. Then we could have a 'handler table' that will now point the 2nd block to the new

position!, so we'll have memory freem from 15 to 50 .

This kind of 'depuration process' could be done very fast as an OS process without the

need of changing our code or the pointer specified on the code. The pointer could 'point'

to the 'index' on the handlers table instead of the fixed area in memory.

There's is were i think that something more important than just a function malloc should

be there in order to make the malloc function really powerful.

Is just a "morning" thought. I hope i made the concept clear.

RE: Dynamic memory allocation Thursday, September 22, 2005 5:14 PM (permalink)

ORIGINAL: jtemples

All malloc does is give you a pointer to a chunk of memory of the specified size. free() returns that chunk of memory to the pool so a subsequent call to

malloc() can reuse it. You don't need an OS to do this. The reason it doesn't

show up in C compilers for small micros is that it's generally just not

practical to use. When people want it, it's usually because they're trying to

port code from an existing application, not because they need or want

malloc() to solve their problem.

❝

❞

http://%28void%280%29%29/

http://%28void%280%29%29/


http://%28void%280%29%29/

http://%28void%280%29%29/







#9

0

Guest

#10

0

magio

Super Member

Total Posts : 2164

Rew ard points : 0

Status: offline


•

It is tempting to have memory allocation available when you're writing/porting a OS kernel,

for example.

But the cost of implementing dynamic memory allocation (even by a OS kernel) goes

beyond that. The memory resource descriptor table takes space, and if you need to

manage memory block ownership you need a task owner descriptor in that table, and

maybe a task current resource list. When you have plenty of resources, this is relative

straightforward, but with low RAM, the cost can be unacceptable.

The garbage collector approach (like you described) requires another thing: the OS needs

to either translate pointers to actual addresses on-the-fly, by using relative indirection

with 'base address' visible by the OS, or the tasks need to have a callback to update the

pointers when the garbage collector moves blocks. This has an impact on performance as

well as on architecture.

There is a minimal approach to malloc, that can be implemented in an OS but does not

require it, that describes the memory pool as a bitmap in which the basic memory

allocation (int or long) is a bit in the bitmap. The malloc() and free() refer to the bitmap to

flag a allocated/free memory unit. This can be easily implemented in PIC18Fs.

Although for a multitasking system *alloc() functions are desirable, sometimes it make

sense just to analyse your code and use fixed allocation to preserve management

resources and increase performance.

The only scenario when I see the need for it is when you have tasks being

loaded/unloaded dynamically.

< Message edited by j_doin -- Sep. 22, 2005 9:15:51 AM >

•

Now i see your point.

Nice explanation on the subject.

And its true, is a design for tasks being loaded and unloaded, and I agree is not the

'common use' of a PIC.

By the enjoyed the complex that things can become if we go 'further'

[8|]




http://%28void%280%29%29/

http://%28void%280%29%29/


http://%28void%280%29%29/

http://%28void%280%29%29/





http://void%280%29/






#11

0

Guest

#12

0

whsiung

Super Member

Total Posts : 1461

Rew ard points : 0

Joined: 11/8/2003

Location: Malaysia

Status: offline #13

Guest

•

That's interesting. And you are writing the OS kernel?

I'd like to hear your results / approaches to task management.

•

Hi,

Not sure if this's what you want: Dynamic Memory Allocation for the MPLAB C18 C

Compiler.

Best regards,

WH Tan

•





http://%28void%280%29%29/

http://%28void%280%29%29/


http://%28void%280%29%29/

http://%28void%280%29%29/


http://ww1.microchip.com/downloads/en/AppNotes/00914a.pdf


http://void%280%29/




http://void%280%29/






0

#14

0

magio

Super Member

Total Posts : 2164

Rew ard points : 0

Status: offline

Dynamically loadable/discardable tasks have another memory allocation issue: internal RAM

footprint of task variables and data objects. You have to handle variable space allocation

conflicts and inter-process shared data areas. You have also to guarantee the compiler

generates fully address-independent relocatable code, else you will have to patch opcodes

for longjumps and jumptables.

Is your application written for an external memory PIC? I'm preparing to port my

microkernel to a external memory architecture using the 18F8722. I have implemented it in

the iAPX'486 architecture with full *alloc() and task load support, including dynamic OS

memory compaction. But in a intel segmented protected mode architecture this is so much

simpler.

I would like to have task load/unload in the system (to allow external mass storage to

have 'PIC .EXE programs'), and task memory allocation is one critical issue.

But I have not decided yet if dynamic memory makes sense in the PIC architecture. I'm

tending to a static memory allocation, with the tasks being compiled as objects and having

a standard COFF file in the disk. The OS can have a 'linker snapshot' in memory and read

the COFF for the task being loaded in memory. Then the memory allocation needs simply

be extracted from the COFF and the loader 'patches' the relocatable objects in the binary

loading process at external RAM. The advantages are the simplicity of the programmer's

model, that remains essentially the same for internal RAM data allocation. If the 'runtime

linker' is ever implemented correctly, it would be funny to have a task internal variables

addresses being updated directly in the opcode fields on-the-fly by the OS. System global

and shared variables update would require a quite sofisticated linker, and certainly take

longer. Since almost always the system would be used for realtime response, this is not

trivial. So, a degree of internal memory allocation granularity is inevitable. This is all still in

the research phase, and I didn't look abroad at other PIC OSes to see how they handle

task loading/unloading.

The *alloc() functions in this external memory makes sense, and is very simple to

implement, and pointer access is natural for external memory RAM (which I believed will be

treated as rom by C18).

•

No, im not writing an OS kernel. I just find the subject fascinating but now i just don't

have the enough spare time that such a work requires.



ORIGINAL: j_doin

That's interesting. And you are writing the OS kernel?

I'd like to hear your results / approaches to task management.

❝

❞

http://%28void%280%29%29/

http://%28void%280%29%29/


http://%28void%280%29%29/

http://%28void%280%29%29/







#15

0

Guest

#16

0

magio

Super Member

Total Posts : 2164

Rew ard points : 0

Status: offline

#17

0

Guest

#18

•

Ok. Maybe in the next 4 months I have something implemented, if I find time to spend on

this. When some concrete results come up, I may post at the forum.

•

It will be quite intereseting.

Even more if its 'open source' or at least 'free'.

May be you could recruit some 'volunteers' here to help you on the task.


•

It certainly would be nice. The plan is to make it available as open source.

Probably the kernel will be coded entirely in assembly, or the largest part of it. My

implementation on the '486 is written entirely in Microsoft MASM, using protected mode.

But it is very well documented, so it hopefully will be not a trouble to rewrite.

About the co-writing, well it's exciting. I am certainly open to make this a collaborative

effort. With so many nice interfacing coming to the PIC18, like USB and Ethernet, a very

tight OS could be nice.

My basic design goal is to retain a user-transparent programming environment, so the

user may write tasks that are oblivious of other tasks, and maybe of the operating system

also. But the power of a multitasking environment comes when you use the OS for

intertask communication like messaging, semaphores and signals.

I've not delved deep into it yet, but I think that C18 can provide the structure to integrate

the OS with the programming model.




http://%28void%280%29%29/

http://%28void%280%29%29/


http://%28void%280%29%29/

http://%28void%280%29%29/


http://%28void%280%29%29/

http://%28void%280%29%29/





http://void%280%29/




http://void%280%29/






© 2016 APG vNext Commercial Version 4.5

0

magio

Super Member

Total Posts : 2164

Rew ard points : 0

Status: offline

#19

0

Guest

#20

•

Nice thing :)

Let us know about the project. Some of use could 'help' with some lines or at least with

the 'debugging' of it.


•

As soon as I have something, I post here ;-)

Page: 1 2 > • Showing page 1 of 2



Home » All Forums » [Development Tools] » MPLAB C18 Compiler » Dynamic memory allocation

Jump to: - - - - MPLAB C18 Com piler

http://void%28jumpmenu%28%24get%28%22forumjumpmenu%22%29%29%29/





http://%28void%280%29%29/

http://%28void%280%29%29/


http://%28void%280%29%29/

http://%28void%280%29%29/






http://void%280%29/



http://www.aspplayground.net/




htt // i hi /f / 114990 10

©Copyright 1998-2014 Microchip Technology Inc. A ll rights reserv

Shanghai ICP Recordal No.09049

Latest Posts Active Posts All FAQs

External interrupt 1 select pin RB1 (RPI33)

How to shut down web server in harmony,…

Preload/Period registers for PIC18F timer …

FFT of sine function using PIC32MX795F…

Is upgrading from v3.26 to v3.30 a bad id…

#pragma config BORV setting on PIC24F …

XC8 Disassembly File Weirdness

How to Fix Bug in Installed File "MPASMW…

Solved: Bug in Harmony corrupts USB MS…

1.37 XC8, PIC18F8722 "could not find spa

FFT of sine function using PIC32MX795F…

Is upgrading from v3.26 to v3.30 a bad id…

#pragma config BORV setting on PIC24F …

How to Fix Bug in Installed File "MPASMW…

MPLAB X v3.30 Still Not usable after a De…

MPLABX include file issue

UART Read Issue

RN52 firmware update

MPLAB-X 3.30 and Dual Partition Issues

Recommendations for PIC and RTOS for …

Can two RN2483 (or RN2903) modems co…

Why is RN2903 dropping packets - only a…

LoRaWAN looks great, but I don't want to …

Missing Forum - CAN

MPLAB X v3.25 installer fails on Windows …

Running MPLAB X in the U.S. English loca…

XC32 V1.40 and persistent and or cohere…

Legacy Peripheral Libraries

MPLAB X v2.XX: MacOSX 10.7 and above…

ICD0083: Debug: Unable to enter debug …

Products Applications Design Support Training Sample & Buy About Us Contact Us Legal

Investors Careers

http://www.microchip.com/careers/

http://www.microchip.com/investors/

http://www.microchip.com/legal/

http://www.microchip.com/contactus/

http://www.microchip.com/aboutus/

http://www.microchipdirect.com/

http://www.microchip.com/training/

http://www.microchip.com/designsupport/

http://www.microchip.com/application/

http://www.microchip.com/products/































http://www.microchip.com/forums/FAQ

http://www.microchip.com/forums/Active

http://www.microchip.com/forums/RecentPosts

http://www.miibeian.gov.cn/

http://www.microchip.com/legal/

http://www.microchip.com/rss/

http://www.youtube.com/user/MicrochipTechnology

http://twitter.com/MicrochipTech

http://www.linkedin.com/

http://www.facebook.com/pages/Microchip-Technology-Inc/20320981741

dynamic memory allocation _ microchip.pdf

Documents