EEPROM writes and reads

[boroko]

Hi all,

Having a bit of a problem with the EEPROM access.

Trying to save a mode setting so that if I re-power, it comes back in the last state. Here is the portion that I'm having the most trouble with. I know that there is ~10mS on the WRITE, and that makes sense. Can't find in the datasheet where that applies to the READ. I'm not jumping into the "StoreMode" sub, so I'm having troubleshooting it. It doesn't seem to be saving in EE.
Does the WRITE dwell in that line of code for the 10mS, or do you need to set up a wait (or check the flag)?



'************************************************* *
'Timing Sub
'************************************************* ***
DlyTime:
for Dly = speed to 0 step -1
READ 0,ModeStore
if modestore <> modecnt then StorMode
'READ 1,Speed ' get the stored SPEED when entering: LATER OPTION
'IF Speed <> StorSpeed THEN StoreMode :LATER OPTION
next Dly
return
StorMode:
modeStore = ModeCnt ' update ModeStore to new ModeCnt
'Speed = StoreSpeed ' update the speed value: LATER OPTION
hserout ["StorMode ",dec modeStore,10,13] 'verify jump to StorMode: DEBUG
'hserout ["StoeSpeed ",dec Speed,10,13] 'verify Speed Change: DEBUG
@ INT_DISABLE RX_INT ; disable to allow the WRITE
@ INT_DISABLE TMR1_INT ; MAY need to disable SPWM_INT for READ to work
write 0, modestore ' re-save the ModeCnt into EEPROM.0
'WRITE 1, Speed ' save the speed value into EEPROM.1: LATER OPTION
@ INT_ENABLE TMR1_INT ; MAY need to re-enable SPWM_INT
@ INT_ENABLE RX_INT ; disable to allow the WRITE

return


I have attached the whole program so that it can be seen in context if that helps. If you do choose to look at the whole thing, I apologize ahead of time. It's not completely cleaned up yet, and I am definitely open to suggestions on improvements ;-}

Thanks, as always, for your time.
Bo

Legit PBP 2.47, MPASM 5.20, 16F877A on a LABX-1

[Darrel Taylor]

Writes to internal EEPROM are self-timed. So you don't need to pause or wait for a flag.

My guess is that it's saving the value to EEPROM. But it's not Reading it before trying to display it.

As you follow through from the start of the program, nothing happens to ModeStore. Then just before GetBytes, it does GOTO Main, and the first statement in Main: is the hserout to display ModeStore, but it hasn't been read yet.

Had that "call DlyTime" just before main been executed, it might have read the value, except that ModeCnt was set to 6 at the beginning, so no matter what, the EEPROM value would end up as 6. Even if it had been written to something else before.

I'd say, read the value from eeprom first, and only set it to 6 if the value read is 255 (erased).

Or set the default value with EEPROM or DATA, and don't set ModeCnt at the beginning.
<br>

[boroko]

Thanks for the reply,

I figured that the first time through, there would be no value, but after any use of the device, from there to eternity, there would be a value to work with. Subsequent tries are still not working as expected.

In light of your advice, I will look at it again and see where I can get something out to determine what I'm missing.

Darrel, If you looked at the whole thing, you may have noticed that there was a block in there that you suggested for the RX. I haven' completely understood it yet so I haven't implemented it yet. I like what I understand and I will get to it, so please don't feel your efforts were in vain.

Thanks again
Bo

[Acetronics2]

Hi, Boroko

Here's an example of what I usually do ...




mesure VAR WORD
duree VAR WORD
dureeprog VAR WORD
dureeral VAR WORD
dureesafe VAR WORD
echantillon VAR WORD
lastok VAR WORD

delay VAR BYTE
wrong VAR BYTE
ohoh VAR BYTE

side VAR BIT
flagbougie VAR BIT
battok VAR BIT
dejavu VAR BIT

PORTA = 0
PORTB = 0

'Pour 16F628

CMCON = 7
CCP1CON = 0

' End of Config.

'************************************************* *****************************
' EEPROM checking
'************************************************* *****************************


Read 2,dureeprog.lowbyte
Read 1,dureeprog.highbyte
Read 3,side
Read 5,dureesafe.lowbyte
Read 4,dureesafe.highbyte
Read 7,dureeral.lowbyte
Read 6,dureeral.highbyte
' Read 8,flagbougie 'Seulement si déverrouillé, sinon 0

IF ( dureeprog <> $FFFF ) AND ( dureesafe <> $FFFF ) AND ( dureeral <> $FFFF ) Then

lastok = dureesafe ' If memory programmed
flagbougie = 0 ' Start on locked position ... for safety.

GoTo locked ' Starting address

EndIF


'************************************************* *****************************
' Measure of programming pulse
'************************************************* *****************************


IF reset = 0 Then mesurepro ' If jumper ON jump to programming mode

'************************************************* *****************************
' Check if programming jumper ON and lock if not
'************************************************* *****************************


oubli:

error = 1
Pause 50
error = 0
Pause 50

GoTo oubli


'************************************************* *******************
mesurepro: ' Programming mode

led = 1 : error = 1


mesurepro1:

Pause 50
led = 0 : error = 0

...
...


Looks EXACTLY what Darrel told you ... no ???

Alain

[boroko]

Hi Alain,

I see that you have given an example of what Darrel was saying (thanks), but I don't understand why you needed to READ the data in that order. Obviously to get .lowbyte and then .highbyte,but why is that necessary?

Is that just for your application or is that something that I need to pay attention to?

Is there anything wrong with just storing it in order in the first place?

My understanding is that you cut this example out of one of your existing apps and the rest of the code doesn't necessarily apply to mine, right?

For mine, I believe that I would do the IF/THEN to check for $FFFF, and if it were blank, give it a start value.


Darrel,
Thanks for your feedback. I didn't see that I wasn't getting to the first "call DlyTime" just before main been executed.

Guys, thanks for looking at. Sometimes the finer points are the ones that are hard to catch. "codeblind" has a nice ring to it ;-}

[Acetronics2]

Hi Alain,

I see that you have given an example of what Darrel was saying (thanks), but I don't understand why you needed to READ the data in that order. Obviously to get .lowbyte and then .highbyte,but why is that necessary?
Is that just for your application or is that something that I need to pay attention to?

Is there anything wrong with just storing it in order in the first place?



Hi, Boroko

Here, it's on your own ... you place your variables in the order you want ... just always use the same order, not to mix them ...





My understanding is that you cut this example out of one of your existing apps and the rest of the code doesn't necessarily apply to mine, right?

For mine, I believe that I would do the IF/THEN to check for $FFFF, and if it were blank, give it a start value.



YES, of course ... may be you already have noted I'm suddently a bit lazy when giving "already cooked" food ...

Alain

[boroko]

Alain,
Thanks for the answer. I was pretty sure that I understood it, but I still remember when I would hang on every word of advise that came from someone that I respected. I remember trying to figure out every possible meaning of a suggestion and feeling frustrated. Now, because of those memories, I try and close the loop and give a conclusion so that everyone can gain from the advise. Thank you for offering it so that we could learn.

Bo