Searching \ for '[PIC]: 16F628 EEPROM write routine' 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: '16F628 EEPROM write routine'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: 16F628 EEPROM write routine'
2002\02\04@215425 by Jinx

face picon face
Now that my stocks of F84 are dwindling, I'm moving s/w over
to the F628. I hope I'm not missing anything embarrassingly
obvious, but this EEPROM routine (which did work on the F84,
before the necessary changes to PIR1) doesn't seem to work.
It's straight from the manual

What happens is that the LED turns on at the start of the routine
but never goes out, indicating that the write didn't finish or the
routine didn't complete

If the circuit is reset, the value intended to be written is at the
EEPROM location it should be

What has me head-scratching is the address of 1C compiled
for EECON1 with WREN

WTF ? I've looked at Microchip's latest data, but that repeats
what is in the manual

Fixes gratefully received, then maybe I can stop p*ssing about
with this and get some proper work done

TIA

============================================

0053  1606  STEE      bsf    portb,led
0054  1283                   bcf    status,rp0
0055  1303                   bcf    status,rp1
0056  3000                   movlw  0x00
0057  009B                  movwf  0x1B           ;eeadr
0058  3053                   movlw  0x53
0059  009A                   movwf  rcreg           ;eedata
005A  138C                  bcf    pir1,eeif
005B  1683                   bsf    status,rp0

005C  138B  WRITE    bcf    intcon,gie
005D  151C                  bsf    0x1C,0x2     ;eecon1,wren
005E  3055                   movlw  0x55
005F  009D                   movwf  0x1D        ;eecon2
0060  30AA                   movlw  0xAA
0061  009D                   movwf  0x1D         ;eecon2
0062  149C                    bsf    0x1C,0x1    ;eecon1,wr

0063  1F8C  WREND   btfss  pir1,eeif
0064  2863                    goto   WREND
0065  138C                    bcf    pir1,eeif
0066  111C                    bcf    0x1C,0x2     ;eecon1,wren
0067  1283                     bcf    status,rp0
0068  1303                     bcf    status,rp1
0069  1206                     bcf    portb,led

006A  286A  ENDWR   goto   ENDWR

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spam_OUTlistservTakeThisOuTspammitvma.mit.edu with SET PICList DIGEST in the body


2002\02\04@220835 by David Duffy

flavicon
face
At 03:52 PM 05/02/2002 +1300, you wrote:
>Now that my stocks of F84 are dwindling, I'm moving s/w over
>to the F628. I hope I'm not missing anything embarrassingly
>obvious, but this EEPROM routine (which did work on the F84,
>before the necessary changes to PIR1) doesn't seem to work.
>It's straight from the manual
>
>What happens is that the LED turns on at the start of the routine
>but never goes out, indicating that the write didn't finish or the
>routine didn't complete
>
>If the circuit is reset, the value intended to be written is at the
>EEPROM location it should be
>
>What has me head-scratching is the address of 1C compiled
>for EECON1 with WREN

EECON1 is in bank 1 (9Ch)

>WTF ? I've looked at Microchip's latest data, but that repeats
>what is in the manual

The datasheet is just plain wrong from memory!
Taken from a recent 'F628 project:

ee_write:                       ;
        btfsc   ee_busy         ;is the eeprom busy from a previous write?
        goto    ee_write        ;yes, loop & wait
        bcf     gie             ;no, disable the global interupt
        bank1                   ;bank 1
        movwf   eeadr           ;set up eeprom address
        movf    ee_temp,w       ;get data for eeprom saved in calling routine
        movwf   eedata          ;set eeprom data
        bsf     wren            ;enable eeprom writing
        movlw   h'55'           ;
        movwf   eecon2          ;eeprom write unlock sequence
        movlw   h'aa'           ;
        movwf   eecon2          ;eeprom write unlock sequence
        bsf     wr              ;initiate data eeprom write
        bank0                   ;bank 0
        bsf     ee_busy         ;set flag to say eeprom is busy
        bsf     gie             ;re-enable the global interupt
        return                  ;exit

Regards...

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservKILLspamspam@spam@mitvma.mit.edu with SET PICList DIGEST in the body


2002\02\04@220850 by Tom Messenger

flavicon
face
Whatever you find, please post your results here.  I just built a test
fixture using my last '84 and ordered a couple dozen 'F628's to use in the
future.

Seems that someone had posted to the list a while back what the pertinent
differences were so you might have some luck perusing the PICLIST archives.

Good luck
Tom M.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservspamKILLspammitvma.mit.edu with SET PICList DIGEST in the body


2002\02\05@005633 by Tony Nixon

flavicon
picon face
Jinx wrote:

> Fixes gratefully received, then maybe I can stop p*ssing about
> with this and get some proper work done
>

This works when simulated with MPLAB.

Some addresses like 0x1B forced MPLAB to complain so I used the
Mnemonics for them.

STEE  bsf    PORTB,LED
     bsf    STATUS,RP0     ; <<<<  changed from bcf
     bcf    STATUS,RP1
     movlw  0x00
     movwf  EEADR          ; <<< MPLAB complained about 0x1B
     movlw  0x53
     movwf  EEDATA         ; << MPLAB complained
     bcf    STATUS,RP0     ; <<<<<<<< added
     bcf    PIR1,EEIF
     bsf    STATUS,RP0

WRITE bcf    INTCON,GIE
     bsf    EECON1,0x2     ; eecon1,wren
     movlw  0x55
     movwf  EECON2         ; eecon2
     movlw  0xAA
     movwf  EECON2         ; eecon2
     bsf    EECON1,0x1     ; eecon1,wr
     bcf STATUS,RP0        ; <<<<< added = RAM Pg 0 now

WREND btfss  PIR1,EEIF
     goto   WREND

     bcf    PIR1,EEIF
     bsf    STATUS,RP0     ; <<<<<< added = RAM Pg 1 now
     bcf    EECON1,0x2     ; eecon1,wren
     bcf    STATUS,RP0
     ; <<<<< deleted - bcf    status,rp1
     bcf    PORTB,LED

ENDWR   goto   ENDWR


--
Best regards

Tony

mICros
http://www.bubblesoftonline.com
.....salesKILLspamspam.....bubblesoftonline.com

--
http://www.piclist.com hint: To leave the PICList
EraseMEpiclist-unsubscribe-requestspam_OUTspamTakeThisOuTmitvma.mit.edu


2002\02\05@005641 by Jinx

face picon face
That routine works a treat, thanks David, slip that into the book.
Locks up with the bsf gie at the end (even though I've got none
enabled), so I took it off for now. I just checked the F628 errata.
Basically the same as the manual (hmmm, they also omit the
bsf gie from their routine now) and nothing like yours

Still get that 1C/9C thing with EECON1, but it works anyway. ???

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestspamspam_OUTmitvma.mit.edu


2002\02\05@053213 by Jinx

face picon face
> This works when simulated with MPLAB.
>

Yes, it does

> Best regards

You too

--
http://www.piclist.com hint: To leave the PICList
@spam@piclist-unsubscribe-requestKILLspamspammitvma.mit.edu


2002\02\05@073551 by Bob Ammerman

picon face
> Still get that 1C/9C thing with EECON1, but it works anyway. ???

Register addresses onl;y occupy the low 7 bits in the instruction. The 8th
bit (ie 0x80 bit) is not part of the register address.

Note that (0x1C & 0x7F) == (0x9C & 0x7F)

Bob Ammerman
RAm Systems

--
http://www.piclist.com hint: To leave the PICList
KILLspampiclist-unsubscribe-requestKILLspamspammitvma.mit.edu


2002\02\05@082745 by James Hillman

flavicon
face
Tony wrote:

{Quote hidden}

Is there any reason why you can't do what I have done below ? This is based
on a write routine I wrote last week. I haven't had any problems with it,
but maybe I've been lucky ??

Instead of polling PIR1,EEIF you poll EECON1,WR which is cleared (according
to data sheet DS40300B) at the completion of the write cycle. This saves a
couple of bank switches and clearing of EEIF bit instructions.

STEE  bsf    PORTB,LED
     bsf    STATUS,RP0     ;
     bcf    STATUS,RP1     ;bank 1

     movlw  0x00
     movwf  EEADR
     movlw  0x53
     movwf  EEDATA         ;load address and data

WRITE bcf    INTCON,GIE
     bsf    EECON1,0x2     ; eecon1,wren
     movlw  0x55
     movwf  EECON2         ; eecon2
     movlw  0xAA
     movwf  EECON2         ; eecon2
     bsf    EECON1,0x1     ; eecon1,wr

WREND btfsc  EECON1,0x1     ;wait for WR bit clear
     goto   WREND

     bcf    EECON1,0x2     ; eecon1,wren
     bcf    STATUS,RP0     ; bank 0

     bcf    PORTB,LED

ENDWR goto   ENDWR

James

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestTakeThisOuTspammitvma.mit.edu


2002\02\05@162155 by Jinx

face picon face
> Is there any reason why you can't do what I have done below ?

With all due and sincere respect to David, Tony and James
and farts in Microchip's general direction, there is something
screwy going on. The various routines I've tried and modified
do write to the EEPROM (any value, any location) yet previously
written-to locations revert to FF. This is not a good thing

<bones>
"It writes Jim, but not as we know it"
</bones>

I'll have to sit and bash this out again today

--
http://www.piclist.com hint: To leave the PICList
spamBeGonepiclist-unsubscribe-requestspamBeGonespammitvma.mit.edu


2002\02\05@165553 by Tony Nixon

flavicon
picon face
James Hillman wrote:

> Is there any reason why you can't do what I have done below ? This is based
> on a write routine I wrote last week. I haven't had any problems with it,
> but maybe I've been lucky ??
>
> Instead of polling PIR1,EEIF you poll EECON1,WR which is cleared (according
> to data sheet DS40300B) at the completion of the write cycle. This saves a
> couple of bank switches and clearing of EEIF bit instructions.


None at all. That's the method I normally use for the reasons you
mention.

I reserve the EEIF flag for use with interrupt routines, which is what
it is there for.

--
Best regards

Tony

mICros
http://www.bubblesoftonline.com
TakeThisOuTsalesEraseMEspamspam_OUTbubblesoftonline.com

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestspamTakeThisOuTmitvma.mit.edu


2002\02\05@170832 by Tony Nixon

flavicon
picon face
Jinx wrote:
>
> > Is there any reason why you can't do what I have done below ?
>
> With all due and sincere respect to David, Tony and James
> and farts in Microchip's general direction, there is something
> screwy going on. The various routines I've tried and modified
> do write to the EEPROM (any value, any location) yet previously
> written-to locations revert to FF. This is not a good thing
>

Weird is the word.

I've never had any problems like that before.

The only EEPROM write problem I have had, is in a 16F876 running at
20MHz. Sometimes the write fails. I haven't been able to nail why, but
dropping to 16MHz cures the problem.

--
Best regards

Tony

mICros
http://www.bubblesoftonline.com
salesEraseMEspam.....bubblesoftonline.com

--
http://www.piclist.com hint: To leave the PICList
EraseMEpiclist-unsubscribe-requestspammitvma.mit.edu


2002\02\05@175758 by Jinx

face picon face
> > written-to locations revert to FF. This is not a good thing
> >
> Weird is the word.

It almost seems as if there's some sort of bulk erase being
done, but that's simply not possible in a routine that doesn't
have any kind of loop or repetitive call on the EEPROM. I've
tried two PICs with the same result. Obviously I'm reluctant
to point the finger at my code, but it must be the culprit. That
said, I'm still not 100% confident about the programming
regime on the F628. Never had problems with the F84

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestEraseMEspamEraseMEmitvma.mit.edu


2002\02\05@185659 by Tony Nixon

flavicon
picon face
Jinx wrote:
>
> > > written-to locations revert to FF. This is not a good thing
> > >
> > Weird is the word.
>
> It almost seems as if there's some sort of bulk erase being
> done, but that's simply not possible in a routine that doesn't
> have any kind of loop or repetitive call on the EEPROM. I've
> tried two PICs with the same result. Obviously I'm reluctant
> to point the finger at my code, but it must be the culprit. That
> said, I'm still not 100% confident about the programming
> regime on the F628. Never had problems with the F84
>
> --
> http://www.piclist.com hint: To leave the PICList
> RemoveMEpiclist-unsubscribe-requestspam_OUTspamKILLspammitvma.mit.edu

Hi Jinx,

Have you got the exact code. I have quite a few 16F62x chips that I can
try it out on.


--
Best regards

Tony

mICros
http://www.bubblesoftonline.com
RemoveMEsalesTakeThisOuTspamspambubblesoftonline.com

--
http://www.piclist.com hint: To leave the PICList
EraseMEpiclist-unsubscribe-requestspamspamspamBeGonemitvma.mit.edu


2002\02\05@193537 by David Duffy

flavicon
face
Jinx wrote:
>With all due and sincere respect to David, Tony and James
>and farts in Microchip's general direction, there is something
>screwy going on. The various routines I've tried and modified
>do write to the EEPROM (any value, any location) yet previously
>written-to locations revert to FF. This is not a good thing

"Go away or I shall taunt you some more!" (Monty Python - Holy Grail)
Seriously, do they really revert to FF? Have you checked them by
reading the chip back into MPLAB & checking the EE window?
One thing that drove me crazy was that I was changing the value
of EEADR before the write was completed. I think I was trying to
read a different EE location when the EE write was still in progress.
This really screws things up because the write routine is still using
EEADR and it suddenly gets moved by the EE read routine!
Send me your code if you like & I will take a look for you.
Regards...

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestKILLspamspammitvma.mit.edu


2002\02\05@204402 by Jinx

face picon face
> Seriously, do they really revert to FF? Have you checked them by
> reading the chip back into MPLAB & checking the EE window?

Yes, I just did that with today's unsullied boot of MPLAB. I haven't
run the code or tinkered with that PIC since the 'puter was turned
off

EEPROM contents are all FF, even the #27 I saw in location $10
before calling it quits last night

I'm just back in the saddle after some other work and I'll be into
the code this avo while I keep an eye on the cricket finals. You'll
be watching won't you Tony ? It should be a great....oh that's
right, sorry (titter)

David, I'll get to the bottom of this one way or another and post
code that works, as well as the (possibly) errant code

btw, "Your mother was an 'amster and your father smells of
elderberries"

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestSTOPspamspamspam_OUTmitvma.mit.edu


2002\02\05@205654 by Tony Nixon

flavicon
picon face
Jinx wrote:

> I'm just back in the saddle after some other work and I'll be into
> the code this avo while I keep an eye on the cricket finals. You'll
> be watching won't you Tony ? It should be a great....oh that's
> right, sorry (titter)

I do believe the footy season is around the corner.....

--
Best regards

Tony

mICros
http://www.bubblesoftonline.com
spamBeGonesalesSTOPspamspamEraseMEbubblesoftonline.com

--
http://www.piclist.com hint: To leave the PICList
KILLspampiclist-unsubscribe-requestspamBeGonespammitvma.mit.edu


2002\02\05@210515 by Jinx

face picon face
> I do believe the footy season is around the corner

'kin oath mate

Anyway, back to business........

--
http://www.piclist.com hint: To leave the PICList
EraseMEpiclist-unsubscribe-requestspamEraseMEmitvma.mit.edu


2002\02\06@012226 by uter van ooijen & floortje hanneman

picon face
> It almost seems as if there's some sort of bulk erase being
> done, but that's simply not possible in a routine that doesn't
> have any kind of loop or repetitive call on the EEPROM. I've
> tried two PICs with the same result. Obviously I'm reluctant
> to point the finger at my code, but it must be the culprit. That
> said, I'm still not 100% confident about the programming
> regime on the F628. Never had problems with the F84

Are you sure your Vcc is rock-steady? Maybe add an elco + a 0.1u really near
to the power/ground pins?

Wouter

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\02\06@181013 by Jinx

face picon face
This s/w writes reliably (AFAICT) to the 628's EEPROM.
Unfortunately, like Jennifer Lopez, I'm more than a little
behind and haven't time for post mortems on the other
write code variants, but I still have one or two things I'd
like to get clear in my own mind at some point

The deal with the EEPROM locations erasing was that
MPLAB writes FF to the whole block when you upload new
code to the PIC. Unticking the EEPROM Data box before
programming stopped that and so left previous contents
as they were. I should've spotted that, but I'll take the Homer
stance - "It's everybody's fault but mine" ;-)

Thanks for the input chaps

==========================================

;ee_628.asm
;
;7th February 2002
;
        list p=16F628
        #include <p16F628.inc>

led    equ 0x04       ;indicator - lights for short time during write
go     equ 0x05       ;push button, start write

start  equ 0x00       ;program start vector
ram    equ 0x20       ;start of RAM in bank0

      __config _intrc_osc_noclkout & _wdt_off & _pwrte_on & _lvp_off &
_boden_off

        org 0x00
        goto entry

entry    clrf   porta
           movlw  0x07     ;comparators off
           movwf  cmcon
           clrf   status        ;set rp0, rp1 = 0 = Bank0

        bsf    status,rp0
        bcf    status,rp1

        movlw  b'00000000'   ;oooo oooo
        movwf  trisa

        movlw  b'00100000'   ;ooio oooo
        movwf  trisb

        movlw  0x80
        movwf  option_reg

        bcf    status,rp0
        bcf    status,rp1

        clrf   porta
        clrf   portb

wait     btfsc  portb,go   ;look for PB press/release on b.5
           goto   wait
waitl    btfss  portb,go
           goto   waitl

STEE  bsf    PORTB,LED
           bsf    STATUS,RP0     ;
           bcf    STATUS,RP1     ;bank 1

     movlw  0x10
     movwf  EEADR
     movlw  0xd2
     movwf  EEDATA         ;load address and data

WRITE bcf    INTCON,GIE
            bsf    EECON1,0x2     ; eecon1,wren
            movlw  0x55
            movwf  EECON2         ; eecon2
            movlw  0xAA
            movwf  EECON2         ; eecon2
            bsf    EECON1,0x1     ; eecon1,wr

WREND btfsc  EECON1,0x1     ;wait for WR bit clear
               goto   WREND

     bcf    EECON1,0x2     ; eecon1,wren
     bcf    STATUS,RP0     ; bank 0

     bcf    PORTB,LED

ENDWR goto   ENDWR

 end

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\02\07@013907 by Jinx

face picon face
> Are you sure your Vcc is rock-steady? Maybe add an
> elco + a 0.1u really near to the power/ground pins?

I didn't have them before, but I do now. The PS is 4 x NiCd
btw, which does seem to be glitch free

One tip I should mention - make sure you're accessing the
correct RAM when loading the eedata register. I puzzled
about an unchanging value for more than a few minutes
before realising, of course, that the F628 has RAM in each
bank. In my case, values are being stored in the bank0 RAM

stee     bsf    portb,led
           movf   ppval,w    ;get value from bank0 RAM
           bsf    status,rp0
           bcf    status,rp1  ;now switch to bank 1
           movwf  eedata
           movf   fsr,w         ;store in EEPROM table
           movwf  eeadr

The above snippet is part of the porting of this circuit and
routine from F84 to F628

http://home.clear.net.nz/pages/joecolquitt/0pots.html

I haven't used some 628 features yet, but assume that a similar
sort of circuit could built around Vref and the comparators ?

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\02\07@042743 by Kevin Blain

flavicon
face
Have you read

http://www.microchip.com/download/lit/suppdoc/errata/80073d.pdf

It would seem there are some errors in the data sheet regarding EEPROM
read/write - concerning the banks the registers are in.

Hope this helps.

Regards, Kevin.

> {Original Message removed}

2002\02\07@062736 by Jinx

face picon face
> Have you read
>
> http://www.microchip.com/download/lit/suppdoc/errata/80073d.pdf
>
> It would seem there are some errors in the data sheet regarding
> EEPROM read/write - concerning the banks the registers are in

I read this a couple of days ago. Although I'm not totally sure I'm
on top of this yet, what I've found disagrees with Example 13-2

In that piece of code, setting up for a write, eeadr and eedata
are loaded AFTER the bank has been changed to bank1

BSF          STATUS,RP0
MOVLW   CONFIG_ADDR
MOVWF   EEADR
MOVLW   CONFIG_DATA
MOVWF   EEDATA

BSF          EECON1,WREN

In the routine I'm working on, that doesn't produce the correct
result because the data and address indices aren't in bank1

IMVHO, the errata sheet is misleading, or at least incomplete

If that's true, then it's a poor show. Microchip have these ICs
for a long long time before we get to play with them and the
documentation should be perfect. After all, these are digital
chips with entirely predictable behaviour

But I've a fresh batch of "hat sauce" simmering if that's not
the case, and someone can show me it's not

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\02\07@074832 by Byron A Jeff

face picon face
On Thu, Feb 07, 2002 at 10:50:06PM +1300, Jinx wrote:
{Quote hidden}

Yes they are. That's the error in the original data sheet. Everything for
the data EEPROM is in bank one. You even switch to bank 1 in the code you
posted yesterday "s/w writes reliably (AFAICT)"

>
> IMVHO, the errata sheet is misleading, or at least incomplete

No. It's write from my brief review of it.

>
> If that's true, then it's a poor show. Microchip have these ICs
> for a long long time before we get to play with them and the
> documentation should be perfect. After all, these are digital
> chips with entirely predictable behaviour

True. But documentation is no fun. Mchip has a habit of simply transferring
data from one chip to another. That's how a lot of errata results.

BAJ

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\02\07@075142 by Kevin Blain

flavicon
face
So is EEADR in bank 0 or 1? The data sheet itself, page 14 for example,
show them all in bank 1, but you are saying that the 'data and address
indeces aren't in bank 1'???

I'm following this closely, as I'll be playing with them myself in the
next couple of days, and I would be interested to know if there are any
gotchas!

It's not yet too late for me to switch to 16F872 or 16F873 if I have
too!


Regards, Kevin

> {Original Message removed}

2002\02\07@085257 by James Hillman

flavicon
face
> In that piece of code, setting up for a write, eeadr and eedata
> are loaded AFTER the bank has been changed to bank1
>
> BSF          STATUS,RP0
> MOVLW   CONFIG_ADDR
> MOVWF   EEADR
> MOVLW   CONFIG_DATA
> MOVWF   EEDATA
>
> BSF          EECON1,WREN
>
> In the routine I'm working on, that doesn't produce the correct
> result because the data and address indices aren't in bank1

CONFIG_ADDR and CONFIG_DATA are literal values (because of MOVLW
instruction) so example is correct. On a 16F628 EEADR and EEDATA are in bank
1.

If you are trying to load values from ram locations defined in bank0 you
need to do something like this

BCF     STATUS,RP0        ;bank 0
MOVF    BANK0ADDRESS,W    ;address from bank 0 into w
BSF     STATUS,RP0        ;bank 1
MOVWF   EEADR
BCF     STATUS,RP0        ;back to bank 0
MOVF    BANK0DATA,W       ;data from bank 0 into w
BSF     STATUS,RP0        ;bank 1 again !
MOVWF   EEDATA

BSF     EECON1,WREN       etc...

You could save some bank switching by using the FSR register to access one
of the bank0 values

James

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\02\07@113356 by Byron A Jeff

face picon face
On Thu, Feb 07, 2002 at 12:02:53PM -0000, Kevin Blain wrote:
> So is EEADR in bank 0 or 1? The data sheet itself, page 14 for example,
> show them all in bank 1, but you are saying that the 'data and address
> indeces aren't in bank 1'???

Everything is in bank 1. To review:

1) Register map on page 14 of the data sheet is correct.
2) Code in chapter 13 of the data sheet is incorrect.
3) Code in the Errata sheet with the URL below is correct.
4) Jinx's posted code (easily found in the archive) is correct.

>
> I'm following this closely, as I'll be playing with them myself in the
> next couple of days, and I would be interested to know if there are any
> gotchas!
>
> It's not yet too late for me to switch to 16F872 or 16F873 if I have
> too!

Well I'd advise taking a decent read of the errata sheet before
proceeding. There seems to be a handful of gotchas that can bite
you if you are not aware of them.

BAJ
>
>
> Regards, Kevin
>
> > {Original Message removed}

2002\02\07@144915 by Jinx

face picon face
> > In the routine I'm working on, that doesn't produce the correct
> > result because the data and address indices aren't in bank1
>
> Yes they are. That's the error in the original data sheet.

Tut-tut, now it's me that needs a slap for being unclear. I meant
MY data and indices, not the PIC's. EEADR and EEDATA are
in bank1, the data I want to store and the info on where it should
go are in Bank0. Sorry

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\02\07@153430 by Byron A Jeff

face picon face
On Fri, Feb 08, 2002 at 08:49:20AM +1300, Jinx wrote:
> > > In the routine I'm working on, that doesn't produce the correct
> > > result because the data and address indices aren't in bank1
> >
> > Yes they are. That's the error in the original data sheet.
>
> Tut-tut, now it's me that needs a slap for being unclear. I meant
> MY data and indices, not the PIC's. EEADR and EEDATA are
> in bank1, the data I want to store and the info on where it should
> go are in Bank0. Sorry

No apology necessary. I did misunderstand your point.

Any chance of moving YOUR ;-) data and indices into the 0x70-0x7f
general ram area that's mirrored in every bank. Or possibly using
FSR/INDF which can span 2 banks.

Just some random thoughts.

BAJ

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\02\07@160127 by Jinx

face picon face
> > in bank1, the data I want to store and the info on where it should
> > go are in Bank0. Sorry
>
> No apology necessary. I did misunderstand your point.
>
> Any chance of moving YOUR ;-) data and indices into the
> 0x70-0x7f general ram area that's mirrored in every bank.
> Or possibly using FSR/INDF which can span 2 banks.

That's something to consider. For another couple of projects
that won't be possible as I need every bit of RAM I can get
hold of

I always get this head-spin after working for a while on
non-banked micros like Mot or AVR and then move back
to PICs with their funny little ways, bless 'em

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\02\07@164227 by Tony Nixon

flavicon
picon face
Kevin Blain wrote:
>
> So is EEADR in bank 0 or 1? The data sheet itself, page 14 for example,
> show them all in bank 1, but you are saying that the 'data and address
> indeces aren't in bank 1'???
>
> I'm following this closely, as I'll be playing with them myself in the
> next couple of days, and I would be interested to know if there are any
> gotchas!
>
> It's not yet too late for me to switch to 16F872 or 16F873 if I have
> too!

I haven't had problems to date. I am using 16F627's and 628's in this
open source project.


http://www.bubblesoftonline.com/fobbit/fobbit.html

--
Best regards

Tony

mICros
http://www.bubblesoftonline.com
@spam@sales@spam@spamspam_OUTbubblesoftonline.com

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\02\07@171945 by Jinx

face picon face
> > So is EEADR in bank 0 or 1? The data sheet itself, page
> 14 for example, show them all in bank 1, but you are saying
> that the 'data and address indices aren't in bank 1'???

No, I should repeat that -

MY data and indices, not the PIC's. EEADR and EEDATA are
in bank1, the data I want to store and the info on where it should
go are in Bank0.

In Example 13-2 of the errata, the data is being got from a
Bank1 RAM address, without explanation that the data could
be got from any RAM in any bank if the bank select bits are set
appropriately. Then set the bank bits to access EEDATA and
EEADR

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\02\07@175432 by Byron A Jeff

face picon face
On Fri, Feb 08, 2002 at 11:19:18AM +1300, Jinx wrote:
> > > So is EEADR in bank 0 or 1? The data sheet itself, page
> > 14 for example, show them all in bank 1, but you are saying
> > that the 'data and address indices aren't in bank 1'???
>
> No, I should repeat that -
>
> MY data and indices, not the PIC's. EEADR and EEDATA are
> in bank1, the data I want to store and the info on where it should
> go are in Bank0.

Right.

>
> In Example 13-2 of the errata, the data is being got from a
> Bank1 RAM address, without explanation that the data could
> be got from any RAM in any bank if the bank select bits are set
> appropriately. Then set the bank bits to access EEDATA and
> EEADR

Well not exactly. The example in the errata is static. Notice
that the address and data are assigned with movlw, i.e. statically
assigned.

The issues you raise are correct, however not relavent to that
particular example.

BAJ

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\02\07@182117 by Jinx

face picon face
> The issues you raise are correct, however not relavent to
> that particular example.

Duly noted. I'm guessing though that most EEPROM writes
would not be immediate values but from RAM (eg a data
logger or sensor buffer), in which case you would have to
be aware of where the data is coming from. It's just one
of those after-the-fact "oh, that's how you do it" things

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\02\11@043802 by Kevin Blain

flavicon
face
No, in the example, the data is coming from literals.

{Quote hidden}

http://www.piclist.com/#topics




*****************************************************************
This email has been checked by the altohiway e-Sweeper Service
*****************************************************************

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


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