gnupic: Thread: Re: [gnupic] org H'2100', EEPROM and "Warnung:Address exceeds maximum range for this processor."

On Sat, 27 Oct 2007 23:48:39 +0200
####@####.#### wrote:

> Hi
> 
> @David Barnett:
> Thanks for the new release !
Glad to hear it's getting some use!

> 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" ;-) ?
Good question. I hadn't thought much about the eeprom addresses on the
small PICs. I suppose a quick fix would be to raise the max address to
0x217F for that MCU (and similarly for others), but that will defeat
the purpose for those MCUs because there won't be a warning when you
first go over address 0x2000. It looks like ultimately we'll also need
the eeprom bounds separately in gpasm.

I don't know offhand... are there any MCU's with more than 2
non-consecutive ROM address ranges? This bounds checking for absolute
mode may be much stickier than I thought...

David Barnett

Am Sonntag, 28. Oktober 2007 schrieb David:
> On Sat, 27 Oct 2007 23:48:39 +0200
>
> ####@####.#### wrote:
> > Hi
> >
> > @David Barnett:
> > Thanks for the new release !
>
> Glad to hear it's getting some use!
>
> > 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" ;-) ?
>
> Good question. I hadn't thought much about the eeprom addresses on the
> small PICs. I suppose a quick fix would be to raise the max address to
> 0x217F for that MCU (and similarly for others), but that will defeat
> the purpose for those MCUs because there won't be a warning when you
> first go over address 0x2000. 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 :-))
>
> 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...)

> This bounds checking for absolute 
> mode may be much stickier than I thought...
As usual...
>
> David Barnett

BTW: Are there also bounds checking for goto/call ? (Sorry, maybe a
beginner question...)

tia,
   Thomas Welsch

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

Am Sonntag, 28. Oktober 2007 schrieb David:
> On Sun, 28 Oct 2007 12:58:14 +0100
....
> 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)?
>
OK, here a stripped down example:

----snip----snip----snip----snip----snip----snip----snip----snip----snip----snip----snip----snip----snip	
	;list      	p=12F675
	#include 	<p12f675.inc>

	__CONFIG  _CP_OFF & _WDT_OFF & _BODEN_ON & _PWRTE_ON & _INTRC_OSC_NOCLKOUT & 
_MCLRE_OFF & _CPD_OFF

	;---------------------------------------------------------------------
	org		0x000		; start of program memory (reset-vector)
	;---------------------------------------------------------------------

start:
	goto	start		; endless loop...


	;---------------------------------------------------------------------
	org	H'2100'			; EEPROM-Data:
	;---------------------------------------------------------------------

	DE	"Hello world..."
		
end

----snip----snip----snip----snip----snip----snip----snip----snip----snip----snip----snip----snip----snip	

Compiled with:
	gpasm -c  -pp12f675 -w0 demo.asm

I got these messages:
demo.asm:19:Warning [220] Address exceeds maximum range for this processor.
demo.asm:19:Warning [220] Address exceeds maximum range for this processor.
demo.asm:19:Warning [220] Address exceeds maximum range for this processor.
demo.asm:19:Warning [220] Address exceeds maximum range for this processor.
demo.asm:19:Warning [220] Address exceeds maximum range for this processor.
demo.asm:19:Warning [220] Address exceeds maximum range for this processor.
demo.asm:19:Warning [220] Address exceeds maximum range for this processor.
demo.asm:19:Warning [220] Address exceeds maximum range for this processor.
demo.asm:19:Warning [220] Address exceeds maximum range for this processor.
demo.asm:19:Warning [220] Address exceeds maximum range for this processor.
demo.asm:19:Warning [220] Address exceeds maximum range for this processor.
demo.asm:19:Warning [220] Address exceeds maximum range for this processor.
demo.asm:19:Warning [220] Address exceeds maximum range for this processor.
demo.asm:19:Warning [220] Address exceeds maximum range for this processor.

> > > 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 =).
Ops, sorry i mean 12f675 ...


bye,
	Thomas Welsch