Searching \ for '[PIC] How do I get to use all the data memory on a' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/memory.htm?key=data
Search entire site for: 'How do I get to use all the data memory on a'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] How do I get to use all the data memory on a'
2005\12\28@015440 by Lee McLaren

flavicon
face
Hi,

I am writing a program in C18 for the 18F1320 and keep running out of
data memory, according to the "Memory Usage Gauge" in MPLAB 7.30 I am
only using 138 out of 256 but every time I try to increase the size of a
serial buffer I get:

Executing: "C:\MCC18\bin\mplink.exe" /l"C:\MCC18\lib"
"C:\mcc18\lkr\18f1320i.lkr" "C:\Data\PIC\PIC_C\CPID2\main.o"
"C:\mcc18\lib\p18f1320.lib" /o"CPID2.cof" /M"CPID2.map"
MPLINK 4.00, Linker
Copyright (c) 2005 Microchip Technology Inc.
Error - section '.udata_main.o' can not fit the section. Section
'.udata_main.o' length=0x0000003c
Errors    : 1


I have checked the map file and can't make a lot of sense out of it but
have include below in case it helps.


MPLINK 4.00, Linker
Linker Error Map File - Created Wed Dec 28 17:51:32 2005

*Warning* - This is only a partial map file due to a link time error.
  Only sections which were allocated prior to the error are shown below.

CODEPAGES:
   Memory      Start        End              Section    Address Size(Bytes)
---------  ---------  ---------            ---------  ---------  ---------
  vectors     0x0000     0x0029           _entry_scn     0x0000     0x0006
                                HIGH_INTERRUPT_VECTOR     0x0008     0x0006
                                LOW_INTERRUPT_VECTOR     0x0018     0x0006

     page     0x002a     0x1e3f               .cinit     0x002a     0x000e
                                        .code_main.o     0x0038     0x0942
                                          _cinit_scn     0x097a     0x009e
                                       .code_uopen.o     0x0a18     0x007a

    debug     0x1e40     0x1fff                                          
   idlocs     0x0000     0x0007                                          
   config     0x0000     0x000d                                          
    devid     0xfffe     0xffff                                          
   eedata     0x0000     0x00ff                                          


SHAREBANKS:

DATABANKS:
   Memory      Start        End              Section    Address Size(Bytes)
---------  ---------  ---------            ---------  ---------  ---------
     gpr0     0x0080     0x00f3               .stack     0x0080     0x003a
   dbgspr     0x00f4     0x00ff                                          


ACCESSBANKS:
   Memory      Start        End              Section    Address Size(Bytes)
---------  ---------  ---------            ---------  ---------  ---------
accessram     0x0000     0x007f                                          
accesssfr     0x0f80     0x0fff        SFR_UNBANKED0     0x0f80     0x0080





Any suggestions?

regards

Lee McLaren

2005\12\28@070134 by Jan-Erik Soderholm

face picon face
Lee McLaren wrote :

> I am writing a program in C18 for the 18F1320 and keep running out
of
> data memory, according to the "Memory Usage Gauge" in MPLAB 7.30 I
am
> only using 138 out of 256 but every time I try to increase
> the size of a serial buffer I get:...

It seems as the C18 stack is "eating" half of your mem :

> SHAREBANKS:
>
> DATABANKS:
>  Memory  Start     End      Section
>  ---------  ------     ---        ---------
>       gpr0  0x0080  0x00f3 .stack  


Maybe try to decrease the stack size (no idea how to do that).

Or, of course, rewrite your app or use a processor with
more RAM...

Jan-Erik.



2005\12\28@165001 by Lee McLaren

flavicon
face
To assist others that may have the same problems I will answer my own post:

Below is what I had to do, it appears that I was not using the
accessram, I did try things like the near and far but they do not work
until you put
"#pragma udata access accessram"

I expect reducing the stack may have helped but I don't know enough to
be sure I am not going to cause other problems.
I have taught myself C over the last few weeks so still have a lot of
holes in my knowledge but are slowly getting there.


regards

Lee McLaren


//variables
//---------------------------------------------------------------------
#pragma udata access accessram
near unsigned char buffer[54];

//---------------------------------------------------------------------
#pragma udata
unsigned char Stop;
unsigned char debounced_state;
unsigned char clock_A;
unsigned char clock_B;
unsigned char DiscReg[1];  // Discrete Inputs     02 10001 R






Jan-Erik Soderholm wrote:
{Quote hidden}

2005\12\29@224338 by kravnus wolf

picon face
The question is why use accessram??? What is it
doing internally? Don't you hate it when
the C compiler does something without your knowledge.

Information hiding at it's finest......

John

--- Lee McLaren <spam_OUTpiclistTakeThisOuTspamlrm.com.au> wrote:

{Quote hidden}

//---------------------------------------------------------------------
> #pragma udata access accessram
> near unsigned char buffer[54];
>
>
//---------------------------------------------------------------------
{Quote hidden}

> --

2005\12\30@073742 by Gerhard Fiedler

picon face
kravnus wolf wrote about Microchip C18:

> The question is why use accessram??? What is it doing internally? Don't
> you hate it when the C compiler does something without your knowledge.

You don't want a compiler that only does what you can understand in a
couple of days :)  One reason I use a compiler is so that I can leverage
the efforts of man-years of development. That can be expected to be a bit
smarter than that, so I expect to have a learning curve until I understand
what the compiler does... with which of course the documentation and
support are supposed to help.

> Information hiding at it's finest......

That would be if the documentation is poor. Is it?

Gerhard

2005\12\30@085140 by olin piclist

face picon face
kravnus wolf wrote:
> The question is why use accessram???

It can be useful to have some variables that can be accessed without regard
to the current bank setting.

> What is it doing internally?

When the accessbank bit is set, the upper 4 RAM address bits are forced to
either all 0 or all 1 depending on the value of the low 8 bits compared to a
threshold.  Normally 0-127 forces 0 and 128-255 forces 1, but some PICs have
more SFRs and the threshold is a little lower.

> Don't you hate it when the C compiler does something without your
> knowledge.

You can't blame the compiler, that's its job.  If you don't like it don't
use it.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

More... (looser matching)
- Last day of these posts
- In 2005 , 2006 only
- Today
- New search...