[PIC] Different types of memory

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

[PIC] Different types of memory

Peter Onion-2
**** I'm using GPUTILS ****

I've run into something I don't understand.

I tried to port some absolute mode 16F627 code to relocatable code on a
16F870.

I replaced the "CBLOCK 0x20" with a UDATA section but ran into this
problem with the linker...

 message: using default linker script
"/usr/local/share/gputils/lkr/16f870.lkr"
error: linker script has no definition that matches the type of section
".udata"

Looking at the data sheet for the 16F870 it has more than enough memory
but the linker script doesn't declare any of it to be "DATABANK".

Is this right ?  Maybe I don't understand something.

Peter

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|

Re: [PIC] Different types of memory

hector (Bugzilla)
The GPRs on F870 are shared. Memory in bank 0 is mapped to 2, and
memory in 1 is mapped to 3. The chunk of memory at the end is mapped
to all of them. Since all the memory is also mapped in other banks, it
has all been declared SHAREBANK. OTOH, I'm not sure this is how it
should be done. As per the F84 linkscript:

DATABANK   NAME=gprs     START=0xC      END=0x4F

seems a much better way of doing it (just declare everything in the
first bank it occurs, except the higher shared memory addresses)

So you can either use UDATA_SHR instead of UDATA, or replace the
following lines in the linkscript:

SHAREBANK   NAME=gprnobnk0     START=0x20     END=0x6F
SHAREBANK   NAME=gprnobnk0     START=0x120    END=0x16F

SHAREBANK   NAME=gprnobnk1     START=0xA0     END=0xBF
SHAREBANK   NAME=gprnobnk1     START=0x1A0    END=0x1BF

SHAREBANK  NAME=gprnobnk2 START=0x70     END=0x7F
SHAREBANK  NAME=gprnobnk2 START=0xF0     END=0xFF
SHAREBANK  NAME=gprnobnk2 START=0x170    END=0x17F
SHAREBANK  NAME=gprnobnk2 START=0x1F0    END=0x1FF

with:

DATABANK   NAME=gprs0     START=0x20     END=0x6F
DATABANK   NAME=gprs1     START=0xA0     END=0xBF

SHAREBANK  NAME=gprnobnk START=0x70     END=0x7F
SHAREBANK  NAME=gprnobnk START=0xF0     END=0xFF
SHAREBANK  NAME=gprnobnk START=0x170    END=0x17F
SHAREBANK  NAME=gprnobnk START=0x1F0    END=0x1FF

(or something similar)

Maybe this should be filed as a bug in gputils?

Peter Onion wrote:

> **** I'm using GPUTILS ****
>
> I've run into something I don't understand.
>
> I tried to port some absolute mode 16F627 code to relocatable code on a
> 16F870.
>
> I replaced the "CBLOCK 0x20" with a UDATA section but ran into this
> problem with the linker...
>
>  message: using default linker script
> "/usr/local/share/gputils/lkr/16f870.lkr"
> error: linker script has no definition that matches the type of section
> ".udata"
>
> Looking at the data sheet for the 16F870 it has more than enough memory
> but the linker script doesn't declare any of it to be "DATABANK".
>
> Is this right ?  Maybe I don't understand something.
>
> Peter
>


--
Hector Martin ([hidden email])
Public Key: http://www.marcansoft.com/hector.asc

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|

Re: [PIC] Different types of memory

Peter Onion-2
On Fri, 2005-06-17 at 11:58 +0200, Hector Martin wrote:

> The GPRs on F870 are shared. Memory in bank 0 is mapped to 2, and
> memory in 1 is mapped to 3. The chunk of memory at the end is mapped
> to all of them. Since all the memory is also mapped in other banks, it
> has all been declared SHAREBANK. OTOH, I'm not sure this is how it
> should be done. As per the F84 linkscript:
>
> DATABANK   NAME=gprs     START=0xC      END=0x4F
>
> seems a much better way of doing it (just declare everything in the
> first bank it occurs, except the higher shared memory addresses)
>
> So you can either use UDATA_SHR instead of UDATA, or replace the
> following lines in the linkscript:
>
> SHAREBANK   NAME=gprnobnk0     START=0x20     END=0x6F
> SHAREBANK   NAME=gprnobnk0     START=0x120    END=0x16F
>
> SHAREBANK   NAME=gprnobnk1     START=0xA0     END=0xBF
> SHAREBANK   NAME=gprnobnk1     START=0x1A0    END=0x1BF
>
> SHAREBANK  NAME=gprnobnk2 START=0x70     END=0x7F
> SHAREBANK  NAME=gprnobnk2 START=0xF0     END=0xFF
> SHAREBANK  NAME=gprnobnk2 START=0x170    END=0x17F
> SHAREBANK  NAME=gprnobnk2 START=0x1F0    END=0x1FF
>
> with:
>
> DATABANK   NAME=gprs0     START=0x20     END=0x6F
> DATABANK   NAME=gprs1     START=0xA0     END=0xBF
>
> SHAREBANK  NAME=gprnobnk START=0x70     END=0x7F
> SHAREBANK  NAME=gprnobnk START=0xF0     END=0xFF
> SHAREBANK  NAME=gprnobnk START=0x170    END=0x17F
> SHAREBANK  NAME=gprnobnk START=0x1F0    END=0x1FF
>
> (or something similar)

That seems more sensible to me.  I never use the "shared bank" features
as I alway put BANKSEL directives where they are needed.  I've not found
anything that says you cant use UDATA on a 16F870 because of the linker
script definitions.

> Maybe this should be filed as a bug in gputils?

It's not a gputils issue as gpling uses the linker scripts that come
from Microchip.  I only put "I'm using gputils" at the top so that Olin
can't complain ;-)
 
Peter


--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|

RE: [PIC] Different types of memory

Jan-Erik Söderholm
In reply to this post by Peter Onion-2
Peter Onion wrote :

[snipped lnk details...]

>
> That seems more
sensible to me.  I never use the "shared
> bank" features as I alway
put BANKSEL directives where
> they are needed.

Now, for variables
defined in a bank that is shared over
*all* banks, you don't need
BANKSEL at all, of course. And I
would expect MPASM/MPLINK to be clever
enought to
*never* add any extra bank select code for those variables
anyway, but I'm not sure there.

Anyway, shared GPRs is a *performance*
feature/option,
but you don't have to use it, of course.

> I've not
found anything that says you cant use UDATA
> on a 16F870 because of
the linker script definitions.

Hm, well... It's in the MPASM/MPLINK
manual. In the
descriptions of the UDATA/UDATA_SHR directives.

And in
general, in *any* PIC that don't have any one-bank-
only-GPR, you can't
use UDATA. It's nothing that has
to be in all data sheets (or
whatever).

Regards,
Jan-Erik.



--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|

RE: [PIC] Different types of memory

Peter Onion-2
On Fri, 2005-06-17 at 13:07 +0200, Jan-Erik Soderholm wrote:


> Hm, well... It's in the MPASM/MPLINK
> manual. In the
> descriptions of the UDATA/UDATA_SHR directives.
>

I'm looking at that now,
4.61 udata - BEGIN AN OBJECT FILE UNINITIALIZED DATA SECTION
and there is no mention of anything like that on the page....
Peter

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|

RE: [PIC] Different types of memory

Jan-Erik Söderholm
In reply to this post by Peter Onion-2
Peter Onion wrote :

> On Fri, 2005-06-17 at 13:07 +0200, Jan-Erik
Soderholm wrote:
>
>
> > Hm, well... It's in the MPASM/MPLINK
> >
manual. In the
> > descriptions of the UDATA/UDATA_SHR directives.
> >
>
> I'm looking at that now,
> 4.61 udata - BEGIN AN OBJECT FILE
UNINITIALIZED DATA SECTION
> and there is no mention of anything like
that on the page....
> Peter

Well, that is not the *only* page in that
manual... :-)

Under 4.61.4, it says : "See also.... udata_shr"

Under
4.64 "UDATA_SHR", it says :

"This directive is used to declare
variables that are
 allocated in RAM that is shared across all RAM
 
banks (i.e., unbanked RAM)".

And later in the same (manual-) section :

"This directive is similar to udata, except that it is
 only used on
parts with memory accessible from
 multiple banks. udata_shr is used
with SHAREBANK
 locations in the linker script, where as udata
 
sections are used with DATABANK
 locations in the linker script.

Best
Regards,
Jan-Erik.



--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|

Re: [PIC] Different types of memory

John J. McDonough
In reply to this post by Jan-Erik Söderholm
----- Original Message -----
From: "Jan-Erik Soderholm" <[hidden email]>
Subject: RE: [PIC] Different types of memory

> And in
> general, in *any* PIC that don't have any one-bank-
> only-GPR, you can't
> use UDATA.

Except, of course, if you edit the linker script or use one of the chips
where Microchip's linker script is different.

In fairness to Microchip, on a chip without one bank only gpr, it makes more
logical sense to use udata_shr, but since the older chips were not handled
that way, it is hard for Microchip to suddenly break a lot of programs by
changing the older linker scripts, but it does add confusion.

But it is pretty easy to avoid the confusion, just use the source, Luke.
Read the bloody linker script.

--McD

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|

Re: [PIC] Different types of memory

hector (Bugzilla)
In reply to this post by Peter Onion-2
Peter Onion wrote:
> That seems more sensible to me.  I never use the "shared bank" features
> as I alway put BANKSEL directives where they are needed.  I've not found
> anything that says you cant use UDATA on a 16F870 because of the linker
> script definitions.

The idea of those are for example for saving the W register in an ISR.
You either need to reserve the same location on all banks for that, or
use a location that is mirrored on all banks.

>
>> Maybe this should be filed as a bug in gputils?
>
> It's not a gputils issue as gpling uses the linker scripts that come
> from Microchip.  I only put "I'm using gputils" at the top so that Olin
> can't complain ;-)

Then, it should be filed as a bug to microchip :P

--
Hector Martin ([hidden email])
Public Key: http://www.marcansoft.com/hector.asc

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist