reading writing to eeprom

[Visitor]

Continuing my EEPROM tests, I stored data as ShortInt and Integer (which can be positive or negative). Reading back as the proper type variable yields the respected results. Reading back as bytes, the negative values are in 2s-complement format.

Saving constant values is more interesting. They need to be read back in the appropriate format. If you don't know the size of the value stored, you may get the wrong result.

The conclusions are pretty simple:

¤ You need to leave enough space for the format you are storing.

¤ You need to read the data as the same type it was stored.

¤ If you save constant values, you need to consider how a value of that size would have been stored and read it as the proper type.

No big surprises here, just details to be aware of.

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

Part 5 - ShortInt and Integers


EE.30 = Short +42, EE.32 = Short -42, EE.34 = Int +42, EE.36 = Int -42

Read as bytes

Addr29: 255
Addr30: 42
Addr31: 255
Addr32: 214
Addr33: 255
Addr34: 42
Addr35: 0
Addr36: 214
Addr37: 255

Read in format written.

Addr 30: 42
Addr 32: -42
Addr 34: 42
Addr 36: -42


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

Part 6 - Constants


EE.40 = 42, EE.42 = -42, EE.44 = 747, EE.46 = -747

Read as bytes

Addr39: 255
Addr40: 42
Addr41: 255
Addr42: 214
Addr43: 255
Addr44: 235
Addr45: 2
Addr46: 21
Addr47: 253

EE.40 read in various formats. =42

Addr 40 as byte: 42
Addr 40 as word: 65322
Addr 40 as short int: 42
Addr 40 as int: -214

EE.42 read in various formats. -42

Addr 42 as byte: 214
Addr 42 as word: 65494
Addr 42 as short int: -42
Addr 42 as int: -42

EE.44 read in various formats. =747

Addr 44 as byte: 235
Addr 44 as word: 747
Addr 44 as short int: -21
Addr 44 as int: 747

EE.46 read in various formats. =-747

Addr 46 as byte: 21
Addr 46 as word: 64789
Addr 46 as short int: 21
Addr 46 as int: -747

 

[tumbleweed]

Isn't all of that exactly what you would expect to happen?

If you leave it up to the complier, then EE.Write(0, $55) will be whatever the compiler decides it needs to be.
That's not a good idea.

If you give it a defined type to work with then you're a lot better off. At least you now know what's going to happen.

const MY_CONST as word = $55
EE.Write(0, MY_CONST)

will use 2 bytes ('sizeof(word)') even though it would normally only require a byte to store the value $55,
which is what you'll get if you just use 'const MY_CONST = $55' with no type specifier and 'const MY_CONST = $1234' will get you two bytes stored.

Don't let the compiler guess what you want to happen... tell it.
Or, use the dedicated WriteByte, WriteWord, WriteFloat etc methods instead of Write()

 

[Visitor]

Isn't all of that exactly what you would expect to happen?

Absolutely. I was hoping some people reading this thread might actually pay attention and learn something. I should realize by now that this is a futile effort.

 

[MrDEB]

If I remove the

 EE.Write(1,best_score)
    EE.Read(0,tmpByte)
    If tmpByte = $77 Then
        EE.Read(1,best_score)
        End If

the current_score starts adding up instead of showing actual current_score so I think it needs to be there. What it does nobody stated what it actually does. Only reason it's there I used the example from Graham Mitchels TETRIS code.
I tried writing the current_score into the 2 slot of eerom (ee.write(2,current_score) but didn't seem to work.
I can display on the lcd "WriteAt(2,1,"seconds ",s," ")" and get the correct format but the value of ms from the current score is used.
the problem seems to be converting both scores.

 

[Visitor]

You may have noticed I've been ranting on and on endlessly about EEPROM addresses and so on, curiously starting at post #46. No, I suppose you didn't.

Your various scores are WORD variables. A WORD is 2 BYTES.

Each EEPROM cell holds one BYTE. A WORD therefore requires 2 EEPROM cells. If you write a WORD at cell 1, it will put one BYTE in cell 1 and one BYTE in cell 2.

If you write another WORD to cell 2, it puts one BYTE in cell 2 and the other BYTE in cell 3.

But cell 2 was already in use by the WORD you stored in cell 1, which put a BYTE in cell 1 and a BYTE in cell 2.

WORD variables can't be written to adjacent locations – they must be stored at least 2 locations apart or values will be overwritten.

Regarding Graham's Tetris code: I don't know what he was doing and neither do you. You aren't trying to play Tetris, so it makes no sense to include a scrap of code you don't understand does it?

Back to my EEPROM rant. A blank EEPROM cell has all its bits set: %11111111. The value of a blank location is 255. Unless YOU write something to EEPROM cell 0, it will ALWAYS read as 255. There is no way the somehow the value $77 appears in this cell unless YOUR code puts it there. By the way, the $ sign indicates the that this is a number in hexidecimal. 77 in hex = 119 in decimal.

My BEST suggestion to you is to delete EVERYTHING in that subroutine and start fresh, understanding why every line is there. Currently, it's a mess and will only be made worse by throwing bandaids on it.

You want to store the best score. Let's put it in EE.0.

Read EE.0 to see what the current best score is. It will start at 65,535 after you load code into the PIC. Why? Because loading code (usually) clears. EEPROM data (sets it high) and best score is a WORD.

If an IF/THEN statement to check if the current score is less the the best score. If it is, set best score = current score and save it at EE.0. If it's not, don't do anything.

This is all the subroutine needs to do. You can add a couple lines to display the results, but this should be simple and straightforward.

 

[MrDEB]

I was getting LOST so yes I am rewriting the entire subroute
am writing to two separate slots or best score and current score Using 1 and 4 slots
I noticed I didn't save current_score so doing that as well. Not sure I need it but?
one issue is converting the scores using s=DecToStr(ms/1000)+"."+DecToStr((ms Mod 1000))
but the ms is used in both current score and best score when converting thus the scores are wrong
using WriteAt(2,1,"best score="dectostr(best_score) ",s," ") then
WriteAt(2,1,"current score="dectostr(current_score) ",t," ")
will post new code later as wife wants to go shopping

 

[Visitor]

EEPROM has limited number of write cycles, remember? Why do you need to save the current score in EEPROM? When you turn this thing on, does the score from the last game matter?

The term is subroutine. Please use it.

 

[MrDEB]

I kinda wanted the last score stored in eeprom but after rethinking I realized WHY do I need to write the current score.
working on a better KISS method with hopefully on;u one write/read for just the best score to date.
curious how many "slots" of memory are available in an eeprom of say 256k?
Each "word" would take up 2 slots I assume?

 

[Ian Rogers]

I kinda wanted the last score stored in eeprom but after rethinking I realized WHY do I need to write the current score.
working on a better KISS method with hopefully on;u one write/read for just the best score to date.
curious how many "slots" of memory are available in an eeprom of say 256k?
Each "word" would take up 2 slots I assume?

Ahh but!! When numerous scores are saved, its normal to date them... For your purpose I would just show 5 last high scores... 10 bytes... Locations 0, 2, 4, 6 and 8... ( This is going to be good )

 

[Visitor]

Each "word" would take up 2 slots I assume?

OMG. Do you read any of the replies people post?

I'm sorry. I'm done. No amount of explaining is going to help if you don't even read it.

Looking at only my replies, this has been covered in posts #105, #84, #81, #50 AND #46. In excruciating detail. That's just my replies; many other replies by others have explained the same thing.

Absolutely. I was hoping some people reading this thread might actually pay attention and learn something. I should realize by now that this is a futile effort.

[Media]

 

[MrDEB]

I have redone the subroutine and now trying to convert the WORDS using the DecToStr(ms/1000)+"."+DecToStr((ms Mod 1000)) but the ms value is carried over from the current score conversion. this causes the current score and best score to be the same.
Presently only have one ee.write and one ee.read only for best score

 

[granddad]

I'm sorry. I'm done. No amount of explaining is going to help if you don't even read it.

Well done Visitor , surviving for 110 posts is quite an achievement.

 

[Visitor]

I have redone the subroutine and now trying to convert the WORDS using the DecToStr(ms/1000)+"."+DecToStr((ms Mod 1000)) but the ms value is carried over from the current score conversion. this causes the current score and best score to be the same.
Presently only have one ee.write and one ee.read only for best score

You can't be this dumb can you? You're trolling us all, right? Well played.

 

[MrDEB]

You're trolling us all, right?

not sure what your referring to.
I just following your suggestion then convert after

 

[tumbleweed]

You're trolling us all, right?

No, unfortunately.

MrDEB gets an A+++ for persistence.

 

[Visitor]

And F- in reading comprehension and ability to communicate.

 

[be80be]

DecToStr((ms Mod 1000)) Why do you even need all that

game starts score 0 you play a bit score is 100 you get tired you hit button to save score
EE.write (0,100)
you fire up game you
EE.read (0,Oldscore)
you want see Oldscore
you print
WriteAt DecToStr((1,1,Oldscore))

 

[MrDEB]

Well after trying several different things and experimenting with different code formats I think I discovered where my issue with the current_score and best_score were getting mixed together.
I was converting it wrong
here is what I came up with

 writeat(2,1,"best   ",dectostr(best_score/1000)+"."+dectostr(best_score mod 1000))

was just using

WriteAt(2,1,DecToStr(ms/1000)+"."+DecToStr((ms Mod 1000)))

 

[be80be]

Why are you using mod

 

[be80be]

The modulo (or "modulus" or "mod") is the remainder after dividing one number by another.