gnupic: Thread: Re: [gnupic] Problem with large udata section.


[<<] [<] 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 [>] [>>]


Powered by ezmlm-browse 0.20.