gnupic: Thread: [gpasm] The PAGESEL directive with 18F chips

Hi,
The documentation for gpasm states that the PAGESEL directive is
ignored for 16bit enhanced devices.  Can anyone explain why this is
the case?  Is the sequence:

	movlw	UPPER(<label>)
	movwf	PCLATU
	movlw	HIGH(<label>)
	movwf	PCLATH

not required before doing an:

	addwf	PCL, F

I would assume that the program counter latches need to be defined
before doing a computed goto?  Non enhanced 16 bit devices do have
the:

	movlw	HIGH(<label>)
	movwf	PCLATH

sequence.  What is the difference between enhanced and non-enhanced
chips?
	-- Robert

-- 
    Robert James Kaes    ---  Flarenet Inc.  ---    (519) 426-3782
		 http://www.flarenet.com/consulting/
      * Putting the Service Back in Internet Service Provider *

On Tue, 2004-02-17 at 16:30, Robert James Kaes wrote:
> Hi,
> The documentation for gpasm states that the PAGESEL directive is
> ignored for 16bit enhanced devices.  Can anyone explain why this is
> the case?  Is the sequence:
> 
> 	movlw	UPPER(<label>)
> 	movwf	PCLATU
> 	movlw	HIGH(<label>)
> 	movwf	PCLATH
> 
> not required before doing an:
> 
> 	addwf	PCL, F
> 
> I would assume that the program counter latches need to be defined
> before doing a computed goto?  Non enhanced 16 bit devices do have
> the:
> 
> 	movlw	HIGH(<label>)
> 	movwf	PCLATH
> 
> sequence.  What is the difference between enhanced and non-enhanced
> chips?

16 bit = 17xx
16 bit Enhanced = 18xx

No paging is required on 18xx devices.

The part numbering of PICs is pretty bad. It leads to a lot of
confusion.

> 	-- Robert

> The part numbering of PICs is pretty bad. It leads to a lot of
> confusion.

You're not kidding.  The whole 12F family confuses almost everyone.
My poor local sales rep just gets this whipped puppy look when I
bring that up.  I guess he gets it from everyone on that issue.

The worst part about their scheme is that it *almost* makes sense.
You think you have the pattern down and then they do something
*completely different*.

The recent push of legacy compatible flash parts is sort of funky,
too.  Take a look at the 16F5[47] and the future 12F50[89].

Contrast that with the additions to the 18F line.  They tend
to be whole logically layed out families.  Same core features,
but different packaging and different memory sizes--generally
all possible combinations, too.  Each family seems to have a
goal in life and, sometimes, a logical relationship to other
families.

18FABCD

A is 1 for 18 pin
     2 for 28 pin
     4 for 40 pin
     6 for 64 pin
     8 for 80 pin
B is 2 for 2k
     3 for 4k
     4 for 6k or 8k
     5 for 12k or 16k or 24k
     6 for 32k
     7 for 64k
CD is a feature set generally, but there is some confusion--for me.

Cheers,
David

On Tue, 17 Feb 2004, Craig Franklin wrote:
> 16 bit = 17xx
> 16 bit Enhanced = 18xx
> 
> No paging is required on 18xx devices.

Does that mean there is a bug in the gpsim simulator?  If I do not
include the:

	local	here
here:
	movlw	UPPER(here)
	movwf	PCLATU
	movlw	HIGH(here)
	movwf	PCLATH

before doing an:

	addwf	PCL, F

the simulator does not work correctly.  (Well it does work, but only
in the first 256 bytes of program memory.  If I assemble, at say 100h
the simulator dies in an infinite loop at the addwf opcode.)

I'll have to test the actual hardware when I get home tonight.
	-- Robert

-- 
    Robert James Kaes    ---  Flarenet Inc.  ---    (519) 426-3782
		 http://www.flarenet.com/consulting/
      * Putting the Service Back in Internet Service Provider *

On Wed, 18 Feb 2004, ####@####.#### wrote:
> Hi all,
> 
>   Firstly, I'm new in this list.  :-)
> 
>   From the 18F452 datasheets :
> 
> "(..). The CALL, RCALL, GOTO and program branch
> instructions write to the program counter directly. For
> these instructions, the contents of PCLATH and
> PCLATU are not transferred to the program counter.
> 
>    The contents of PCLATH and PCLATU will be transferred
> to the program counter by an operation that
> writes PCL."


I have a feeling that the PAGESEL _should_ still be required for
computed GOTOs.  In the PIC18FXX8 datasheet section 4.8.1 states:

  "The ADDWF PCL instruction does not update PCLATH/PCLATU.  A read
  opeation on PCL must be performed to update PCLATH and PCLATU."

Therefore, for a computed GOTO (addwf PCL) to work correctly, the
PCLATH and PCLATU registers _must_ be properly set.  These registers
do not seem to be set by any instruction (like GOTOs, CALLs, etc.)
For a computed GOTO to work, they need to be set manually.

Maybe the name PAGESEL is misleading, but it would appear that setting
the PCLATH/PCLATU is required before doing an addwf PCL.
	-- Robert

-- 
    Robert James Kaes    ---  Flarenet Inc.  ---    (519) 426-3782
		 http://www.flarenet.com/consulting/
      * Putting the Service Back in Internet Service Provider *

On Tue, 17 Feb 2004, Craig Franklin wrote:
> 
> 16 bit = 17xx
> 16 bit Enhanced = 18xx
> 
> No paging is required on 18xx devices.

All right I just tried doing an:

	addwf PCL, F

on a 18f258.  If the code does _not_ include the:

	movlw	UPPER(label)
	movwf	PCLATU
	movlw	HIGH(label)
	movwf	PCLATH

the computed GOTO does not work.  However, if I use the above sequence
or simply do a:

	movfw	PCL

the code does work.  Therefore, an enhanced PIC (18xx) does not need
PAGESEL for before a GOTO, CALL, etc., but the PCLAT* register's _do_
need to be set before doing a computed GOTO.

Sorry for the confusion and I hope this clarifies the situation.
	-- Robert

-- 
    Robert James Kaes    ---  Flarenet Inc.  ---    (519) 426-3782
		 http://www.flarenet.com/consulting/
      * Putting the Service Back in Internet Service Provider *

On Wed, 2004-02-18 at 11:38, Robert James Kaes wrote:
> I have a feeling that the PAGESEL _should_ still be required for
> computed GOTOs.  In the PIC18FXX8 datasheet section 4.8.1 states:
> 
>   "The ADDWF PCL instruction does not update PCLATH/PCLATU.  A read
>   opeation on PCL must be performed to update PCLATH and PCLATU."
> 

gpasm operates the same as mpasm.  They both ignore PAGESEL for 18xx
devices.

I don't think the PAGESEL directive was created with computed gotos in
mind.  For instance, only bits 4 and 3 of PCLATH are set for 14 bit
devices.  So PAGESEL can't be used.  IIRC, the only device that sets all
of PCLATH with a PAGESEL are the 17xx.

> Therefore, for a computed GOTO (addwf PCL) to work correctly, the
> PCLATH and PCLATU registers _must_ be properly set.  These registers
> do not seem to be set by any instruction (like GOTOs, CALLs, etc.)
> For a computed GOTO to work, they need to be set manually.
> 

Yes, they need to be set.

I should have been more specific in my previous response.

18xx devices use 2 word call and goto instructions.  This allows them to
address the entire memory map.  You don't have to manually set the upper
bits using a directive such as PAGESEL.

If you are directly manipulating the program counter (computed goto), it
is up the user to ensure that the contents of the PCLATH registers are
correct.

> Maybe the name PAGESEL is misleading, but it would appear that setting
> the PCLATH/PCLATU is required before doing an addwf PCL.
> 	-- Robert

On Wed, 18 Feb 2004, Robert James Kaes wrote:


> On Tue, 17 Feb 2004, Craig Franklin wrote:
> > 
> > 16 bit = 17xx
> > 16 bit Enhanced = 18xx
> > 
> > No paging is required on 18xx devices.
> 
> All right I just tried doing an:
> 
> 	addwf PCL, F
> 
> on a 18f258.  If the code does _not_ include the:
> 
> 	movlw	UPPER(label)
> 	movwf	PCLATU
> 	movlw	HIGH(label)
> 	movwf	PCLATH
> 
> the computed GOTO does not work.  However, if I use the above sequence
> or simply do a:
> 
> 	movfw	PCL

> On Tue, 17 Feb 2004, Craig Franklin wrote:
> > 
> > 16 bit = 17xx
> > 16 bit Enhanced = 18xx
> > 
> > No paging is required on 18xx devices.
> 
> All right I just tried doing an:
> 
> 	addwf PCL, F
> 
> on a 18f258.  If the code does _not_ include the:
> 
> 	movlw	UPPER(label)
> 	movwf	PCLATU
> 	movlw	HIGH(label)
> 	movwf	PCLATH
> 
> the computed GOTO does not work.  However, if I use the above sequence
> or simply do a:
> 
> 	movfw	PCL

> On Tue, 17 Feb 2004, Craig Franklin wrote:
> > 
> > 16 bit = 17xx
> > 16 bit Enhanced = 18xx
> > 
> > No paging is required on 18xx devices.
> 
> All right I just tried doing an:
> 
> 	addwf PCL, F
> 
> on a 18f258.  If the code does _not_ include the:
> 
> 	movlw	UPPER(label)
> 	movwf	PCLATU
> 	movlw	HIGH(label)
> 	movwf	PCLATH
> 
> the computed GOTO does not work.  However, if I use the above sequence
> or simply do a:
> 
> 	movfw	PCL

> On Tue, 17 Feb 2004, Craig Franklin wrote:
> > 
> > 16 bit = 17xx
> > 16 bit Enhanced = 18xx
> > 
> > No paging is required on 18xx devices.
> 
> All right I just tried doing an:
> 
> 	addwf PCL, F
> 
> on a 18f258.  If the code does _not_ include the:
> 
> 	movlw	UPPER(label)
> 	movwf	PCLATU
> 	movlw	HIGH(label)
> 	movwf	PCLATH
> 
> the computed GOTO does not work.  However, if I use the above sequence
> or simply do a:
> 
> 	movfw	PCL

> On Tue, 17 Feb 2004, Craig Franklin wrote:
> > 
> > 16 bit = 17xx
> > 16 bit Enhanced = 18xx
> > 
> > No paging is required on 18xx devices.
> 
> All right I just tried doing an:
> 
> 	addwf PCL, F
> 
> on a 18f258.  If the code does _not_ include the:
> 
> 	movlw	UPPER(label)
> 	movwf	PCLATU
> 	movlw	HIGH(label)
> 	movwf	PCLATH
> 
> the computed GOTO does not work.  However, if I use the above sequence
> or simply do a:
> 
> 	movfw	PCL
> 
> the code does work.  Therefore, an enhanced PIC (18xx) does not need
> PAGESEL for before a GOTO, CALL, etc., but the PCLAT* register's _do_
> need to be set before doing a computed GOTO.


And by 'does work' do you mean in the simulator too?

Scott

On Wed, 18 Feb 2004, Scott Dattalo wrote:
> And by 'does work' do you mean in the simulator too?
> 
> Scott

The simulator also requires either the updating of the PCLAT*
registers manually, or doing a addfw PCL.  If you do either of these,
the simulator does the right thing for the computed GOTO.

(The only problem with the simulator is that the PCLATU register isn't
implemented for the 18c252.)
	-- Robert

-- 
    Robert James Kaes    ---  Flarenet Inc.  ---    (519) 426-3782
		 http://www.flarenet.com/consulting/
      * Putting the Service Back in Internet Service Provider *