Hi.

 > I think you may have a perception problem with this memory space.

No, I have not. :-)
I know very well that it is a remapping of regular GPR space.

My "problem" was how to allocate a continous 100 byte
buffer accessable as one part via FSR's in the linear area.
Without hard coded addresses, of course. I thought that
calculating the "real" addresses by hand and allocate them
directly from the banks seemed a bit silly.

Anyway, I created a project and did some experiments.

I first checked the LKR for the 16F1938. Anyone can open their
own copy of 16f1938_g.lkrm but here are the critical parts:

-----------------------------------------------------------------
DATABANK  NAME=3Dgpr0  START=3D0x20  END=3D0x6F  SHADOW=3Dlinear0:0x2000
DATABANK  NAME=3Dgpr1  START=3D0xA0  END=3D0xEF  SHADOW=3Dlinear0:0x2050
....
DATABANK  NAME=3Dgpr11 START=3D0x5A0 END=3D0x5EF SHADOW=3Dlinear0:0x2370
....
....
SECTION   NAME=3DLINEAR0 RAM=3Dlinear0         // Linear Memory
-----------------------------------------------------------------

Note the "shadow=3D" parts and the new special LINEAR0 section !

Now, "linear0" can by used directly by UDATA for allocations :

-----------------------------------------------------------------
; Allocate one "normal" GPR...
GPR_VAR1        UDATA
MYVAR1          RES        1

; Allocate two buffers 100 and 200 bytes in "linear" memory.
LINEAR0         UDATA
mybuff1         RES        d'100'
mybuff2         RES        d'200'

; An additional GPR.
GPR_VAR2        UDATA
MYVAR2          RES        1
-----------------------------------------------------------------

The two mybuffx symbols are created as expected (from the MAP file):

-----------------------------------------------------------------
  MYBUFF1   0x002000       data     static D:\DATA\proj\CDS\CDS.ASM
  MYBUFF2   0x002064       data     static D:\DATA\proj\CDS\CDS.ASM
-----------------------------------------------------------------

This writes "ABCD" to the first four positions of mybuff2 :

-----------------------------------------------------------------
     movlw   high    mybuff2
     movwf   fsr0h
     movlw   low     mybuff2
     movwf   fsr0l

; FSR0 now points to h'2064'.

     movlw   a'A'
     movwi   indf0++
     movlw   a'B'
     movwi   indf0++
     movlw   a'C'
     movwi   indf0++
     movlw   a'D'
     movwi   indf0++
-----------------------------------------------------------------

SIMulating the code above shows an "ABCD" in the expected place.
And the regular variables MYVAR1 and MYVAR2 are allocated
after the two buffers in bank 4, just as one want.

Then it is "only" the usual handling of the FSR including, of
course, the new automatic post/pre dec/inc of the FSR...

Nice ! :-)

Jan-Erik.



Byron Jeff wrote 2012-07-24 21:57:
> Jan-Eric,
>
> I think you may have a perception problem with this memory space. The key
> element to understand that the space is only accessible via the FSR
> registers. There is no direct addressing mechanism.
>
> BAJ
>
> On Tue, Jul 24, 2012 at 08:17:17PM +0200, Jan-Erik Soderholm wrote:
>> Hi.
>>
>> I'm loooking at starting up my first 16F1xxx project.
>> It will be the 16F1938 (on the "PICkit 28-pin demo board").
>>
>> Now, these PICs has something called "linear memory" where
>> GPR from the (up to) 32 banks are combined into one linear
>> area without holes or jumps. Fine so far. But how do I "use"
>> this area? I know of the usual UDATA and UDATA_SHR but I
>> expected something like UDATA_LIN to specificaly allocate
>> memory from that area.
>>
>> Normal UDATA allocation will not cross banks, right?
>>
>> Maybe using UDATA together with a hardcoded adress in the
>> linear area ? But that defeets the automatic allocation.
>>
>> Anyone who has used this memory area for (e.g.) buffers
>> larger then one single bank?
>>
>> Jan-Erik.
>>
>> --
>> http://www.piclist.com PIC/SX FAQ & list archive
>> View/change your membership options at
>> http://mailman.mit.edu/mailman/listinfo/piclist
>
--=20
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.