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