Internal EEPROM

[SeeCwriter]

I am still having problems reading and writing the internal EEPROM of an
18F8722. Plus I'm confused by the compiler manual. I'm using PCHW
v5.043.

In the Data EEPROM section of the manual, pg 63, it shows an example of
writing and reading the EEPROM:

write_eeprom(0x10, 0x1337); // Writes 0x1337 to data EEPROM location 10.
value=read_eeprom(0x0); // Reads data EEPROM location 10 returns 0x1337.

According to this section you can write and read 16-bit values.

But when I look at the function descriptions for read_eeprom() and write_eeprom(),
it says the read_eeprom() function returns "an 8 bit int", and that for the
write_eeprom() function the value it writes is "an 8 bit int".

So my first question is, which is correct?

[rnielsen]

I believe the manual states you can write 8 bit or 16 bit depending on the part. The spec sheet for the 18F8722 states that 8 bits are to be written. If you need to write a 16 bit variable to the eeprom then you'll need to do it with two operations.

Ronald

[SeeCwriter]

Actually, the manual only says the address a 8 bit or 16 bit int depending
on the part. The data is always specified as an 8 bit int. Which is fine, I just
needed clarity.

I am unable to read and write the data EEPROM, since the data does not
persist through a power cycle. Whenever I read the EEPROM after a power
cycle the data is always 0xFF.

Is there something wrong with the 2 functions I'm using to read and write?

[asmboy]

the datasheet is the governing document.
the eeProm writes a BYTE at a time
to a WORD offset - of which only 10 bits are used .

\

[SeeCwriter]

I'm aware of what the data sheet says. But that does not mean that the
CCS library functions couldn't have been written to handle reading or
writing multiple byes with a single call.

Perhaps you could elaborate on where I went off the rails with GetParameter().

[ELCouz]

Don't always expect to have a byte of data gor internal eeprom...

dspic30,33 and pic 24 have 16 bit writes and read on internal eeprom (two bytes at time)...
_________________
Regards,
Laurent

-----------
Here's my first visual theme for the CCS C Compiler. Enjoy!

[asmboy]

[Ttelmah]

Funnily enough, a second thread about the EEPROM on a PIC30, is running at almost exactly the same time.

The manual is actually _wrong_ on the write EEPROM function for these later chips. However if you look at the example 'ex_intee.c', you will see how (and for which chips), CCS handle the switch between sizes.

[ELCouz]

[ELCouz]

[SeeCwriter]

I was looking at passing arguments by pointer before you posted. I was
remembering a previous PIC project from a few years ago where I was
burned by using pointers to pass a parameter to a function. And it bit
me in the a** again.
I was trying to make use of function overloading, and passing a pointer
seemed like the best option. Oh well. Removing the pointer and just returning the value fixed the problem.

This seems like a compiler bug. Or at least the compiler should give a
warning when passing pointers.

[asmboy]

#1 - assume that parameters passed INTO the function code space by POINTER - can NOT be used to pass data back OUT.

if you think about it - that's why you can safely pass an argument in by value that is contained in an otherwise global VAR.

#2 when we execute "ADR++"
after first use - the external GLOBAL var passed as "ADR" is only a copy of the GLOBAL VAR -hence the source VAR for ADR in this case - is not altered by the function.

#3 -If you don't know how already -lean to read the .LST pseudo assembler file. SO much can be figured about about compiler behavior by reading and comprehending what it shows of the actual pic code .