Post by thread:[PIC] Defining large memory tables in relocatable

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

Em 8/4/2010 21:13, Josh Koffman escreveu: {Quote hidden}> 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 > 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/

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.

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.

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/

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.

On Fri, Apr 9, 2010 at 8:31 AM, Olin Lathrop <spam_OUTolin_piclistTakeThisOuTembedinc.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

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.