Searching \ for '[PIC] Defining large memory tables in relocatable' 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=table
Search entire site for: 'Defining large memory tables in relocatable'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Defining large memory tables in relocatable '
2010\04\08@201302 by Josh Koffman

face picon face
Hi all. I'm currently using relocatable code, and I'm working on an
18f2520. The data memory (GPRs) is divided into 256 byte banks.

I need to define a large area of memory for a buffer. It needs to be
greater than 256 bytes, and it needs to be contiguous so I can use the
FSR on it. In absolute mode you could do something like:

CBLOCK 0x100
  Buffer: d'300'
ENDC

However, I want to use relocatable mode. If I try to "RES" longer than
a bank, it complains. Is the only solution to do two separate defines
like this:

Bank1 udata 0x100
BufferPartA     res     0xFF

Bank2 udata 0x200
BufferPartA     res     0x2C

Or is there something I'm missing?

Thanks!

Josh
--
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
       -Douglas Adams

2010\04\08@204323 by Isaac Marino Bavaresco

flavicon
face
Em 8/4/2010 21:13, Josh Koffman escreveu:
{Quote hidden}

Create a modified linker-script with a bank the size you want, by
linking some 256-byte banks

For instance, change:

DATABANK   NAME=gpr0       START=0x80              END=0xFF
DATABANK   NAME=gpr1       START=0x100             END=0x1FF
DATABANK   NAME=gpr2       START=0x200             END=0x2FF
DATABANK   NAME=gpr3       START=0x300             END=0x3FF
DATABANK   NAME=gpr4       START=0x400             END=0x4FF
DATABANK   NAME=gpr5       START=0x500             END=0x5FF
DATABANK   NAME=gpr6       START=0x600             END=0x6FF
DATABANK   NAME=gpr7       START=0x700             END=0x7FF
DATABANK   NAME=gpr8       START=0x800             END=0x8FF
DATABANK   NAME=gpr9       START=0x900             END=0x9FF
DATABANK   NAME=gpr10      START=0xA00             END=0xAFF
DATABANK   NAME=gpr11      START=0xB00             END=0xBFF
DATABANK   NAME=gpr12      START=0xC00             END=0xCFF
DATABANK   NAME=gpr13      START=0xD00             END=0xDFF

To:

DATABANK   NAME=gpr0       START=0x80              END=0xFF
DATABANK   NAME=gpr1_8   START=0x100              END=0x8FF
DATABANK   NAME=gpr9       START=0x900             END=0x9FF
DATABANK   NAME=gpr10      START=0xA00             END=0xAFF
DATABANK   NAME=gpr11      START=0xB00             END=0xBFF
DATABANK   NAME=gpr12      START=0xC00             END=0xCFF
DATABANK   NAME=gpr13      START=0xD00             END=0xDFF
// Add this:
SECTION        NAME=DATA1_8    RAM=gpr1_8


Now you have a data bank that is 0x800 (2K) bytes long.

In you "ASM" file, use:

DATA1_8    udata

Buffer    res    .2048    ; Please use "radix decimal", this "dot
number" thing is horrible.


Best regards,

Isaac

__________________________________________________
Fale com seus amigos  de graça com o novo Yahoo! Messenger
http://br.messenger.yahoo.com/

2010\04\09@083204 by Olin Lathrop

face picon face
Josh Koffman wrote:
> I need to define a large area of memory for a buffer. It needs to be
> greater than 256 bytes, and it needs to be contiguous so I can use the
> FSR on it.

Go to the linker file and merge just enough banks to fit your large buffer,
then use RES normally in the code.  For example, here is a normal linker
file snippet:

 DATABANK NAME=bank4 START=0x400 END=0x4FF //register bank 4
 DATABANK NAME=bank5 START=0x500 END=0x5FF //register bank 5

 SECTION NAME=.BANK4 RAM=bank4 //to put registers in bank 4
 SECTION NAME=.BANK5 RAM=bank5 //to put registers in bank 5

Change that to make one large memory region:

 DATABANK NAME=big START=0x400 END=0x5FF //banks 4,5 together

The gotcha is that if you ever shrink the buffer to fit in a whole bank,
then a section could straddle the bank boundary.  Unfortunately there is no
automated way to catch this.  It would be nice if there was something like
RESB that worked like RES but tells the linker the memory may straddle
multiple contiguous memory regions, but there is no such thing.

For now, put a big warning comment by the RES 300 that the linker file must
change if it is ever reduced to less than RES 256.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2010\04\09@084114 by Olin Lathrop

face picon face
Isaac Marino Bavaresco wrote:
> DATABANK NAME=gpr1_8 START=0x100 END=0x8FF

Warning: Only do this if your large buffer is uses up enough of the space so
that everything else that might get placed in that memory region is
guaranteed not to straddle any bank.  Making a single large region like this
without requiring it is a very bad idea.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2010\04\09@091937 by Isaac Marino Bavaresco

flavicon
face
Em 9/4/2010 09:41, Olin Lathrop escreveu:
> Isaac Marino Bavaresco wrote:
>  
>> DATABANK NAME=gpr1_8 START=0x100 END=0x8FF
>>    
> Warning: Only do this if your large buffer is uses up enough of the space so
> that everything else that might get placed in that memory region is
> guaranteed not to straddle any bank.  Making a single large region like this
> without requiring it is a very bad idea.
>  


The idea is exactly that, the buffer is declared to use explicitly the
large section and should occupy it all. It is perfectly safe as long as
you only use it to allocate variables that will be accessed indirectly
by FSR.


Best regards,

Isaac

__________________________________________________
Fale com seus amigos  de graça com o novo Yahoo! Messenger
http://br.messenger.yahoo.com/

2010\04\09@103848 by Olin Lathrop
face picon face
Isaac Marino Bavaresco wrote:
> The idea is exactly that, the buffer is declared to use explicitly the
> large section and should occupy it all. It is perfectly safe as long
> as
> you only use it to allocate variables that will be accessed indirectly
> by FSR.

Right, but the problem is guaranteeing that.  Actually the large buffer
doesn't need to occupy all of the large memory region, only enough of it to
guarantee no other section can straddle any bank boundaries within the
region.

Unless you declare the large memory region PROTECTED other sections could
get placed there.  But if you do that, any remaining memory in the large
region is not accessible unless you explicitly put them there.  Either way
there are problems or manual work required if the large buffer is later made
smaller and a bank boundary is left uncovered.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2010\04\10@202042 by Josh Koffman

face picon face
On Fri, Apr 9, 2010 at 8:31 AM, Olin Lathrop <spam_OUTolin_piclistTakeThisOuTspamembedinc.com> wrote:
> Go to the linker file and merge just enough banks to fit your large buffer,
> then use RES normally in the code.  For example, here is a normal linker
> file snippet:
>
>  DATABANK NAME=bank4 START=0x400 END=0x4FF //register bank 4
>  DATABANK NAME=bank5 START=0x500 END=0x5FF //register bank 5
>
>  SECTION NAME=.BANK4 RAM=bank4 //to put registers in bank 4
>  SECTION NAME=.BANK5 RAM=bank5 //to put registers in bank 5
>
> Change that to make one large memory region:
>
>  DATABANK NAME=big START=0x400 END=0x5FF //banks 4,5 together

Well that makes sense. Would I need to have a SECTION definition as
well? Something like:
SECTION NAME=.BIG RAM=big //to put registers in the large bank

> The gotcha is that if you ever shrink the buffer to fit in a whole bank,
> then a section could straddle the bank boundary.  Unfortunately there is no
> automated way to catch this.  It would be nice if there was something like
> RESB that worked like RES but tells the linker the memory may straddle
> multiple contiguous memory regions, but there is no such thing.

I'm not sure I fully understand this. Do you mean if I shrink the
buffer size to something less then 256 bytes that it or other
variables might get placed in the extra large bank and straddle a
boundary? This would be bad because I would have to be sure about my
banking during the program, so I'd have to use BANKSEL or your
DBANKIF, correct?

I think I like the idea of modifying the linker file. It means that if
I ever target another processor I'm going to be forced to do some
research into how the memory lays out and I can't make any
assumptions. Well, I can but the code won't compile!

Josh
--
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
       -Douglas Adams

2010\04\11@103216 by Olin Lathrop

face picon face
Josh Koffman wrote:
>> DATABANK NAME=bank4 START=0x400 END=0x4FF //register bank 4
>> DATABANK NAME=bank5 START=0x500 END=0x5FF //register bank 5
>>
>> SECTION NAME=.BANK4 RAM=bank4 //to put registers in bank 4
>> SECTION NAME=.BANK5 RAM=bank5 //to put registers in bank 5
>>
>> Change that to make one large memory region:
>>
>> DATABANK NAME=big START=0x400 END=0x5FF //banks 4,5 together
>
> Well that makes sense. Would I need to have a SECTION definition as
> well? Something like:
> SECTION NAME=.BIG RAM=big //to put registers in the large bank

You don't need it unless you want to force other RAM into the leftover
cracks in BIG.  If you do a RES 300, the linker will have no choice but to
place the section containing that RES into BIG .

> I'm not sure I fully understand this. Do you mean if I shrink the
> buffer size to something less then 256 bytes that it or other
> variables might get placed in the extra large bank and straddle a
> boundary?

Right.  The linker doesn't know about bank boundaries.  We normally make
each bank a separate region because the linker can only place any section
wholly in one region.  This guarantees no section will straddle a bank
boundary.  However, now the BIG region does have a bank boundary in the
middle.  As long as you have a section exceeding one bank in size, that
section will get placed in BIG, and will guarantee to straddle the bank
boundary, further guaranteeing no other section will straddle it.

> I think I like the idea of modifying the linker file. It means that if
> I ever target another processor I'm going to be forced to do some
> research into how the memory lays out and I can't make any
> assumptions. Well, I can but the code won't compile!

It will compiler fine since the compiler and assembler have no idea of
linker memory regions.  It's the linker that will catch the error.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

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