gnupic: Re: [gnupic] Error in default link script for pic16f676
Subject:
Re: [gnupic] Error in default link script for pic16f676
From:
David ####@####.####
Date:
9 Jun 2007 06:49:29 +0100
Message-Id: <20070609004517.30db0121@DEEPTHOUGHT.BARNET.net>
On Fri, 08 Jun 2007 21:26:40 -0700
"R. Timothy Edwards" ####@####.#### wrote:
> Dear David,
>
> >> I found an error in the default link script for the PIC
> >> 16F676 chip. The line:
> >>
> >> SHAREBANK NAME=gpr0 START=0xA0 END=0xDF
> >>
> >> should be:
> >>
> >> SHAREBANK NAME=gpr1 START=0xA0 END=0xDF
> >>
> > <snip>
> >> Several other link scripts
> >> duplicate the name "gprnobnk", but I'm not sure if this
> >> is intentional or not.
>
> > Actually, I think those lines are correct as-is.
<snip>
>
> Certainly the duplicate "gpr0" was a problem in that without it, the
> linker ran of of data space on a very simple program, whereas once I
> changed it, the program linked, and I was able to download it to the
> PIC, plug it into the circuit board, and it ran like a charm.
The key to all this is the concept of shadowed RAM. The 16f676 actually
has half the gpr's you think it has, with two ways to access each
address. Address 0x20 refers to the same RAM cell as address 0xA0, 0x21
as 0xA1, etc. You can verify that on the 16f676 datasheet: over the
address range 0xA0-0xDF, it says "accesses 20h-5Fh". The SHAREBANK
sections just describe the layout of the chip, so if you change it as
you describe, you'll be randomly overlaying each cell on another,
and you'll eventually have data collisions.
> Admittedly, the 16F676 has a meager amount of memory and is probably
> not the best thing to be compiling code for
Yep. You probably already know this, but when you compile code from C,
there's a little bit of fixed overhead along with a little bit of
variable overhead. On your chip, the fixed overhead probably eats up
most of your RAM. Plus in C it's easy to make much bigger programs
RAM-wise without realizing it.
> Off-topic:
>
> By the way, is there any plan to write a driver for the USB-based
> ICD2 programmer?
Not that I'm aware of. I program my chips with the ICD2 as well, but I
think the logic is that if we have a good simulator, we can build
cheaper programmers that don't need expensive USB and drivers. gpsim
has a few flaws and missing features that are hard to work around if
they affect you, but in a lot of ways it's better than the hardware
itself or MPSIM (MPLAB's built-in simulator). Anyway, it's really
pretty easy copying the HEX and cod files onto a windows box to debug
with the ICD2.
Hope that all gave you some perspective.
David Barnett
