Searching \ for '[PIC]: F871 EEPROM read fixed..thanks' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/memory.htm?key=eeprom
Search entire site for: 'F871 EEPROM read fixed..thanks'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: F871 EEPROM read fixed..thanks'
2001\02\08@103719 by Hardware Engineering

picon face
Thanks again..those who pointed out some errors.  Now, I did read the app
notes about reads/writes and followed the example but I could never get it to
work.  The other problem is, since I could not get it to work, I tried to copy
other code snippets, but being from a diff processor, it was not exactly the
same.  So live and learn..

What I did find was I had to set the page bits back to 00 else it would go off
to never never land.  Strange the notes didnt mention it.

So for those who care, this is the routine that works.  Next I will go back to
the writes...so stay tuned for more HELP ME posts!
testread:
       movlw   _minutes        ; points to location in EEPROM
       movwf   EEPROM_ADR      ;  and store to variable
       call    TESTRD
       movf    EEPROM_DATA,W   ; get EEPROM data and store to W
       movwf   MINUTES


TESTRD:
       movf    EEPROM_ADR,W    ;0x00
       bcf     STATUS,RP0      ; change to page 2
       bsf     STATUS,RP1      ; change to page 2

       movwf   EEADR           ; set up eeprom address from W
       bsf     STATUS,RP0      ; change to page 3
       bcf     EECON1,EEPGD    ; Be sure to read from EEPROM
       bsf     EECON1,RD       ; set the read bit
       bcf     STATUS,RP0      ; back to page 2
       movf    EEDATA,W        ; return value in W
       movwf   EEPROM_DATA     ;  and store
       bcf     STATUS,RP0      ; change to page 0
       bcf     STATUS,RP1      ; change to page 0
       return

____________________________________________________________________
Get free email and a permanent address at http://www.netaddress.com/?N=1

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\02\08@110023 by Drew Vassallo

picon face
>What I did find was I had to set the page bits back to 00 else it would go
>off
>to never never land.  Strange the notes didnt mention it.

The bank bits (not PAGE bits) shouldn't matter AFTER you access the EEPROM
memory.  (Just as a note, the page bits (PCLATH) are set when you do your
call and restored on return.  Each page of these devices are 0xFF in length.
 Typically the page bits in PCLATH are manipulated when you modify the
program counter PCL, as in the case of a computed goto.  Otherwise, you
really don't have to worry about PCLATH much.)

Of course, whatever you access after you return will have to have the bank
bits set appropriately.  You don't have to reset the selected bank to 0
before you return, you can do it afterwards.  This shouldn't have caused any
errors with this routine.

{Quote hidden}

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\02\08@120445 by Olin Lathrop

face picon face
> (Just as a note, the page bits (PCLATH) are set when you do your
> call and restored on return.

PCLATH is **NOT** altered by a CALL or RETURN.

> Typically the page bits in PCLATH are manipulated when you modify the
> program counter PCL, as in the case of a computed goto.  Otherwise, you
> really don't have to worry about PCLATH much.)

No, no, no!  You have to worry about PCLATH whenever you do a CALL or GOTO
to a location that could be on a different page.  After a subroutine
returns, PCLATH is set the way the subroutine left it, which is usually
pointing to its page.  This can mess up GOTOs that otherwise go to addresses
known to be on the same page.


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, spam_OUTolinTakeThisOuTspamembedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\02\08@144829 by Drew Vassallo

picon face
>No, no, no!  You have to worry about PCLATH whenever you do a CALL or GOTO
>to a location that could be on a different page.  After a subroutine
>returns, PCLATH is set the way the subroutine left it, which is usually
>pointing to its page.  This can mess up GOTOs that otherwise go to
>addresses
>known to be on the same page.

This is odd because I have programs that call subroutines at the very end of
a 2K PIC from the ISR routine at ORG 4 with no trouble.  I don't save PCLATH
and never adjust it in the program.  The only trouble I run into is when I
do a computed GOTO jump, in which case I set the PCLATH manually.

If your statement is true, I'd never be able to return to nearly 80% of my
calls, since they run the gamut of program memory locations from 0x00A
through 0x700.  Yet I have no problems.

--Andrew
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\02\08@150535 by Drew Vassallo

picon face
> > (Just as a note, the page bits (PCLATH) are set when you do your
> > call and restored on return.
>
>PCLATH is **NOT** altered by a CALL or RETURN.

Of course you're right on this... I don't know what I was thinking (or not
thinking, as the case may be).

But I still am concerned about the fact that I have never had a problem with
any return to calling routines, regardless of page location.

Literally, though, I have one program that makes calls to the final few
program memory locations from inside the ISR at ORG 4 on a PIC16C71.  And I
don't adjust the PCLATH.  This is just one example, I have subroutines
located all over the program that can be called from anywhere.

--Andrew
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\02\08@151306 by Bob Ammerman

picon face
> This is odd because I have programs that call subroutines at the very end
of
> a 2K PIC from the ISR routine at ORG 4 with no trouble.  I don't save
PCLATH
> and never adjust it in the program.  The only trouble I run into is when I
> do a computed GOTO jump, in which case I set the PCLATH manually.
>
> If your statement is true, I'd never be able to return to nearly 80% of my
> calls, since they run the gamut of program memory locations from 0x00A
> through 0x700.  Yet I have no problems.
>
> --Andrew

Ah... there's pages and then there's PAGES:

Sometimes it matters what 256 byte page you're talking about.

Sometimes it matters what 2048 byte PAGE you're talking about.


For ADDWF PCL,F or MOVWF PCL or other things that directly hack PCL, PCLATH
better contain the high half of the correct 256 byte page.

For CALL or GOTO, the low order 3 bits of PCLATH are ignored, and thus
PCLATH only has to refer to any 256 byte page with the 2048 byte PAGE.

[Note: this is how it is on some PICs, but not all!]

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\02\08@153849 by Olin Lathrop

face picon face
> >No, no, no!  You have to worry about PCLATH whenever you do a CALL or
GOTO
> >to a location that could be on a different page.  After a subroutine
> >returns, PCLATH is set the way the subroutine left it, which is usually
> >pointing to its page.  This can mess up GOTOs that otherwise go to
> >addresses
> >known to be on the same page.
>
> This is odd because I have programs that call subroutines at the very end
of
> a 2K PIC from the ISR routine at ORG 4 with no trouble.  I don't save
PCLATH
> and never adjust it in the program.  The only trouble I run into is when I
> do a computed GOTO jump, in which case I set the PCLATH manually.
>
> If your statement is true, I'd never be able to return to nearly 80% of my
> calls, since they run the gamut of program memory locations from 0x00A
> through 0x700.  Yet I have no problems.

Not odd at all because everything you mention is within the first code page,
from 0 to 7FF.  You won't get away with ignoring PCLATH if your code is on
multiple pages.  You will also have to save/set/restore PCLATH in the
interrupt routine if you do any GOTOs or CALLs in it anywhere.


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, .....olinKILLspamspam@spam@embedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


More... (looser matching)
- Last day of these posts
- In 2001 , 2002 only
- Today
- New search...