weird eeprom issue

[cerr]

Hi There,

I posted the other day already with eeprom issues but then thought i got them resolved and it all seemed to work fine but now I have yet another issue I can't explain

It seems as if my read algorithm would only read 0xff out but only if i didn't write before. If I write before I read I read 0x00 out of every cell.. :(
I have no clue what's going on here, my read algoithm looks like this:

[temtronic]

I'd add some 'printf'...statements so that you can verify your writing to eeprom addresses and data are correct.

Also, make a table of known 'test' data and try that.
Always a lot easier to debug when you know what it's supposed to be....!

[Ttelmah]

First, in C, variables can _only_ be declared at the start of a program section. 'lobyte', is technically declared legally, but hibyte is not.
Historically, variables could only be declared right at the start of a function (not just a program section), and CCS still prefers this, so though lobyte's declaration location is technically 'legal', far safer to declare all variables at the start of the function.

Second, don't try to assign from a function, inside the declaration. The values assigned to a variable in it's declaration, is only allowed to be a _constant_ in traditional C (which CCS basically is). Initialisation, is done _before the code actually runs...

Best Wishes

[cerr]

[cerr]

[temtronic]

cerr
Please do not criticize, condemn and complain about CCSs product until YOU can create and sell us a better product for the same price.
Every 'language' has it's quirks and it is very important to read the manual, forums like this, etc.
Not having been shown your entire code, I would not assume that the data you say you wrote to the eeprom was correct. A previous pointer could have overlapped ram, some 'offset' from some other function, heck your power supply could have dipped. A hundred different valid reasons for why your code fragment doesn't work.
After 20+ years of programming PICs my crystal ball is getting cloudy but the more info you show us, the better we can help.

[Ttelmah]

Problem here is that C, is not a 'strongly typed' language.
Now 'strong typing', implies that if (for instance), you use a int, where a char is expected, the compiler will complain. Plus of this, is it makes it harder to make 'type' mistakes. However 'downside', is that it prevents you from deliberately cross-using types 'on the fly'.

Originally, C, was aimed at being able to perform a lot of the jobs that otherwise needed assembler, allowing you (for example), to happily manipulate an array of characters, as an array, but also as a string, without too much extra overhead over the assembler version. CCS keeps very close to the original K&R usage, and definitions, and this is one reason why everyone programming in C, really should have a copy of "The C programming language", and if in doubt refer to this along with the CCS manual.

The way to avoid lack of typing causing problems is to become a better disciplined programmer:
1) Use the explicitly 'sized' types. So int8, int16, int32, rather than 'int', or 'long'. This way your declarations show the size of variable you are declaring.
2) Use names that reflect the type. So for defines, use capitals. For a type declared as a pointer to an int16 array, called 'fred' inside a routine, give it a name like 'lpfred'. Done with some logic, it makes your code self documenting, so if you use a -> construct, it should always have a variable in front of it starting with 'p' or 'lp' to say this variable is a pointer. One problem here is that the type checking on 'higher level' languages, can make people lazy, and careless about this sort of thing, relying on the checks to report stuff, which (not being perfect), they sometimes don't. Then finding a type fault, on a 50000+ line program, without any of these little hints in the names, becomes a real exercise. So, approaches like this, are _better_, whatever language you are using, and will help to make your programs more likely to compile 'right' first time.

Best Wishes