EEPROM writes and reads

1 Attachment(s)

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)?

Code:

'************************************************** '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

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>

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

Hi, Boroko

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

Code:

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

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 ;-}

Quote:

Originally Posted by 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?

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 ...

Quote:

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

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