gnupic: Re: [gnupic] org H'2100', EEPROM and "Warnung:Address exceeds maximum range for this processor."
Subject:
Re: [gnupic] org H'2100', EEPROM and "Warnung:Address exceeds
maximum range for this processor."
From:
David ####@####.####
Date:
28 Oct 2007 16:02:31 +0000
Message-Id: <20071028115552.1bb73415@DEEPTHOUGHT.BARNET.net>
On Sun, 28 Oct 2007 12:58:14 +0100
####@####.#### wrote:
> Am Sonntag, 28. Oktober 2007 schrieb David:
> > On Sat, 27 Oct 2007 23:48:39 +0200
> > I don't know offhand... are there any MCU's with more than 2
> > non-consecutive ROM address ranges?
> I don't know also... Maybe there are techniques/ways to declare
> eeprom data for i2c connected eeproms (I'm only guessing...)
I've used an i2c serial eeprom on my projects, but there was no
hardware support. I can only guess too whether any PICs are different
on that specifically. I was thinking of high-end PICs when I posed the
question. I seem to remember some of them having strange regions in ROM.
That was an open question for everyone, BTW.
@everyone: Do you use a PIC with 3+ non-consecutive ROM regions?
> > > with the new gputils version (gpasm-0.13.5 beta) I will get a
> > > "Warnung: Address exceeds maximum range for this processor"
> > > message...
> > >
> > > This happens at the
> > > org H'2100'
> > > directive during declaring eeprom data for the 12F625 pic...
> > >
> > > Are there new ways to for storing eeprom data or is this a
> > > new "feature" ;-) ?
Now that I think about it, could you pass along a little more info?
What directives are you actually using to declare the data (e.g.
'DATA'), and do you get a warning with just an empty 'ORG' (no data)?
> > It looks like ultimately we'll also need the eeprom bounds
> > separately in gpasm.
> The definition may be: 0x2100-0x21ff[,0x03000-0x030ff...] (But I think
> that's clear :-))
Yeah, I was going by the numbers in gputils' default lkr script
(although I couldn't turn up anything about 12F625...did you mean
635?). Those files frequently have mistakes in them, but we take the
lazy evaluation approach and say that it's right until a user
complains, and then it's easy to fix =).
> BTW: Are there also bounds checking for goto/call ? (Sorry, maybe a
> beginner question...)
I don't think so, but to be honest I don't remember. Give it a shot.
I'm thinking there isn't because the PAGESELs make it nearly impossible
to predict the actual GOTO/CALL targets on many PICs.
However, I've been dreaming of adding intelligent control flow
prediction to gputils (impossible in the general case, but definitely
possible for some cases), which would allow features like that (and
much, much more exciting features).
David Barnett
