MPLAB linker problem for PIC18

Isn't there access RAM using half of the RAM in bank 0 of that processor?

Best regards, Spehro Pefhany

--
"it\'s the network..."                          "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

Well, yes, but I was under the impression that you could use the first

96 bytes as BOTH access ram and general purpose ram. Actually, that's kind of what I'm trying to do, so that no matter whether I use the access ram feature or just straight memory mapping for operands like ADDWF it will still have the same address and I don't have to screw around with bank select bits. I realize that anything above the first 96 bytes I will have to pay close attention to the 'a' part of the operand, but it still saves me half of the headache. Am I mistaken in assuming I can declare all my RAM at once? Do I really need to split it into: (?)

UDATA_ACS VAR1 RES 1 VAR2 RES 1 VAR3 RES 1 . . . VARn RES 1

UDATA 0x060 VARn+1 RES 1 VARn+2 RES 1 VARn+3 RES 1 . . . VARn+p RES 1

-Will

something wrong with the ORG statement somwhere maybe?

--
"I\'m never wrong, once i thought i was, but was mistaken"
Real Programmers Do things like this.
http://webpages.charter.net/jamie_5

Look at the memory map of the first bank. It is used by a lot of the processor configuration registers. I'm not sure what pic you are using but for if you goto the memory organization section of its datasheet you'll see that the first bank actually contains a section for special purpose registers.

" To ensure that commonly used registers (SFRs and

select GPRs) can be accessed in a single cycle, PIC18

devices implement an Access Bank. This is a 256-byte

memory space that provides fast access to SFRs and

the lower portion of GPR Bank 0 without using the

BSR. Section 5.3.3 "Access Bank" provides a

detailed description of the Access RAM."

also

"

The instruction set and architecture allow operations

across all banks. The entire data memory may be

accessed by Direct, Indirect or Indexed Addressing

modes. Addressing modes are discussed later in this

subsection."

and

"

Depending on the instruction, each location can be

addressed directly by its full 12-bit address, or an 8-bit

low-order address and a 4-bit Bank Pointer."

and

"

To streamline access for the most commonly used data

memory locations, the data memory is configured with

an Access Bank, which allows users to access a

mapped block of memory without specifying a BSR.

The Access Bank consists of the first 96 bytes of

memory (00h-5Fh) in Bank 0 and the last 160 bytes of

memory (60h-FFh) in Block 15. The lower half is known

as the "Access RAM" and is composed of GPRs. The

upper half is where the device's SFRs are mapped.

These two areas are mapped contiguously in the

Access Bank and can be addressed in a linear fashion

by an 8-bit address (Figure 5-5).

The Access Bank is used by core PIC18 instructions

that include the Access RAM bit (the 'a' parameter in

the instruction). When 'a' is equal to '1', the instruction

uses the BSR and the 8-bit address included in the

opcode for the data memory address. When 'a' is '0',

however, the instruction is forced to use the Access

Bank address map; the current value of the BSR is

ignored entirely."

So you shoudln't worry about it to much. Stick your data in the second bank and then select that bank and you should be fine. My suggestion would be to move into the pic24's. Those 8-bit devices are no fun.

I suspect the problem is in the linker script, the .lkr file. It probably has an access section already setup that is causing the link error. Look at some of the examples in the MPASM and the MPLINK manuals.

--
Joe Chisolm
Marble Falls, TX

I'm afraid you've completely ignored my entire post... Yes, I am aware there are special function registers, but on the PIC18F they are all at address F60h and above, hence the whole reason there is an Access Bank to begin with. The reason I want MY variables to live in the 000h to 0FFh bank is that I don't want to have to muck around with bank select!!!! I've had to do that for ages with the 16 series and now that the 18 series has this spiffy new feature I'd really like to make use of it. As far as moving to another processor... This is the real world. When a project is already six months along in development, and you chose an MCU specifically for its physical size, feature set, and application specific hardware (brushless DC motor control in this case) and have 85% of your software written and tested, you DO NOT SIMPLY CHANGE MICROCONTROLLERS!!!! The correct thing to do is understand the problem, and then either work around it or fix what you are doing wrong. In this case I can live with having to declare my variables in a way that looks funny so long as it all still works. I just want to learn for the next time around.

--------------------------------------------------------------------------------------------------------------

I think Joe might be onto something with the linker script file. I've never messed with those before, so I don't know what I can and can't do in one, but the one I have right now has the following lines, which I could understand causing problems:

ACCESSBANK NAME=accessram START=0x0 END=0x5F DATABANK NAME=gpr0 START=0x60 END=0xFF

Anyone know if bad things will happen if I switch the start address of gpr0 to 0x0? Is this simply a limitation of the linker that I can't use 0x00-0x5F as GPR without specifically declaring it as being in the access bank?

-Will

Instead of using the UDATA directive use UDATA_ACS. It's in the MPASM manual

--
Joe Chisolm
Marble Falls, TX

Right, that's what the code originally had, but then I have to figure out and track exactly where the split between blocks occurs. I was hoping to just use one giant .udata section to enumerate all of bank

1. Guess that's just not gonna happen... :(

-Will

You can probably get by with changing the linker file and get rid of the accessram section and just make grp0 go from 0-0xFF. If you are doing everything in assembler this should work. Note sure about mixing c/asm and this setup.

--
Joe Chisolm
Marble Falls, TX