[<<] [<] Page 1 of 1 [>] [>>] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: [gnupic] Problem with large udata section.
From: David ####@####.#### Date: 31 Aug 2007 14:12:13 +0100 Message-Id: <20070831090849.5130e917@DEEPTHOUGHT.BARNET.net> On Fri, 31 Aug 2007 02:11:06 -0700 "Jon Philpott" ####@####.#### wrote: > Hi all, > > I'm trying to define a udata section that's pretty large, > 1024 > bytes, however, when i try this: > > udata > bitfield res BITFIELD_SIZE > memory_area res 1024 > foo_area res 2 > > with this linker script: > > ACCESSBANK NAME=accessram START=0x0 END=0x7F > DATABANK NAME=gpr0 START=0x80 END=0xF7F > ACCESSBANK NAME=accesssfr START=0xF80 END=0xFFF > PROTECTED > > at link time I get: > error: no target memory available for section ".udata" > > However, if i change memory_area to be res 512, or even res 900, it > works fine! I would wager that your default radix in the ASM file is set to hexadecimal, so that 1024 means 0x1024, or 4132 in decimal. There are a few ways to specify decimal literals, like .1024 or d'1024', but my personal preference is to (a) use hexadecimal rather than decimal where the decimal doesn't clarify, and (b) never leave a number literal to be the default radix. Also note that the default lkr script splits RAM into sections of 0x100. I'm not sure if this is correct, but make sure you don't accidentally use the default. HTH, David Barnett | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: [gnupic] Problem with large udata section.
From: "Jon Philpott" ####@####.#### Date: 31 Aug 2007 17:06:18 +0100 Message-Id: <c141fc100708310905m610e299dxc385335c0acdf2bf@mail.gmail.com> On 8/31/07, David ####@####.#### wrote: > On Fri, 31 Aug 2007 02:11:06 -0700 > "Jon Philpott" ####@####.#### wrote: > > I would wager that your default radix in the ASM file is set to > hexadecimal, so that 1024 means 0x1024, or 4132 in decimal. There are a > few ways to specify decimal literals, like .1024 or d'1024', but my > personal preference is to (a) use hexadecimal rather than decimal where > the decimal doesn't clarify, and (b) never leave a number literal to be > the default radix. You're correct. I guess I shouldn't try and tackle these problems at 1am in the future. I've not been PIC programming for a while, so I forgot that the default radix was hex. D'oh Thanks for your help, Jon Philpott | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
[<<] [<] Page 1 of 1 [>] [>>] |