Supplementary code / definitions and declarations

[minolta]

Hi,

I have to predefine 2 constant values in the internal eeprom of a PIC18F25K50.
For this i used supplementary code, definition and functions declarations where i wrote:

#pragma DATA _EEPROM, 45, 182, 28, 45

The problem is at compiling:

Ver3.1.c:
442: #pragma DATA _EEPROM, 45, 182, 28, 45
^ (335) unknown pragma "DATA" (warning)

I have read the eeprom content, address 0 is "00" and the rest is "FF"
This syntax worked with with FC5 and FC6.

I need help to overcome this problem.

Thanks.

[kersing]

You can use the EEPROM component to set the initial values. Or use

Code: Select all

__EEPROM_DATA   (45, 182, 28, 45);

in the supplementary code.

[minolta]

Your suggestion worked.
But, the predefined eeprom data are always written from address 8, not from address 0, as expected.

00 FF FF FF FF FF FF FF 2D B6 0A 64 2D B6 0A 64
2D B6 0A 64 FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
.......

From within the program i can read or write any eeprom location without problems.
After the chip(18F25K50) is programmed ( with PICKIT2), location 0 of the eeprom is "00", which is unusual.
This is clearly a bug, but is from FC7 or compiler side?

[medelec35]

From with in the program you can use Read or right EEPROM component to read/wright at address starting from 0.
Or you can place constants using the Initial Values from EEPROM properties as kersing has stated

If you can post your flowchart we can see if we can help you further.

Martin

[jadiflow]

You can use the EEPROM component to set the initial values. Or use

Code: Select all

__EEPROM_DATA   (45, 182, 28, 45);

in the supplementary code.

Thanks; I had the same issue migrating from FC5/6 to FC7.

How do I specify which EEPROM location to preset? I don't want to start from loc 0 and sequentially fill the memory, but I need to do something like

__EEPROM_LOC (0x2110, 44) to put 44 in loc 10.

Do I need to explicitly adress the EEPROM (which starts in my device at 0x2100, so loc 10 would be 0x2110).

Also, in FC5/6 the EEPROM read/write assumed a UI variable. Now in FC7 it says: 'read or write is 8 or 16 bits depending on platform'. How/where is my 16F886 specified as 'platform' in this respect?

Thanks,

Jan Didden

[Benj]

Hi Jan,

If you look at the EEPROM component properties then there is an initial values property. This will be numbered from the start of EEPROM so you could do something like this in the property text field.

255,255,255,255,255,255,255,255,255,255,44

to assign the value 44 to location 10, the other values at 255 will be as if they were unprogrammed.

The upside to this is that it simulates and doesn't require any nasty custom C code in your project

Now in FC7 it says: 'read or write is 8 or 16 bits depending on platform'. How/where is my 16F886 specified as 'platform' in this respect?

The 16F886 is an 8-bit device so the EEPROM read and write will be 8-bit.

[jadiflow]

OK, I will try that.
But it seems a big step backwards. No possibility to preset individual EEPROM locations and no possibility to read/write 16bit integers.

Jan

[jadiflow]

I reviewed this stuff in the FC7 C-compiler XC8, and apparently there is a nifty feature toi use EEPROM to store named variables as in regular RAM.
I wonder if this is supported by FC7? Or I can use inline C-code, but Ben doesn't like that

Qoute from the user manual (bold mine):

"5.5.5 Variables in EEPROM
For devices with on-chip EEPROM, the compiler offers several methods of accessing
this memory. You can defined named variables in this memory space, or use
block-access routines to read or write EEPROM. The EEPROM access methods are
described in the following sections.
5.5.5.1 EEPROM VARIABLES
When compiling for baseline and mid-range parts, the eeprom qualifier allows you to
create named C variables that reside in the EEPROM space. See
Section 5.4.8.5 “Eeprom Type Qualifier”.
Variables qualified eeprom are cleared or initialized, just like ordinary RAM-based variables;
however, the initialization process is not carried out by the runtime startup code.
Initial values are placed into the HEX file and are burnt into the EEPROM when you
program the device. Thus, if you modify the EEPROM during program execution and
then reset the device, these variables will not contain the initial values specified in your
code at startup up.

The following example defines two arrays in EEPROM.
eeprom char regNumber[10] = "A93213";
eeprom int lastValues[3];

For both these objects, initial values will be placed into psects and will appear in the
HEX file. Zeros will be used as the initial values for lastValues.
The generated code to access eeprom-qualified variables will be much longer and
slower than code to access RAM-based variables. You should avoid using
eeprom-qualified variables in complicated expressions. Consider copying values from
the EEPROM to regular RAM-based variables and using these in your code.

[jadiflow]

Hi,

I have to predefine 2 constant values in the internal eeprom of a PIC18F25K50.
For this i used supplementary code, definition and functions declarations where i wrote:

#pragma DATA _EEPROM, 45, 182, 28, 45

The problem is at compiling:

Ver3.1.c:
442: #pragma DATA _EEPROM, 45, 182, 28, 45
^ (335) unknown pragma "DATA" (warning)

Some additional info: the fact that this doesn't compute in FC7 is not Matrix'es fault - it is the Microchip XC8 compiler, used within FC7, that does not support this syntax. In FC5 there was another C-compiler that did.

In cases like this it is a good idea to download and review the XC8 User Manual which is available at the Microchip website.

My next task is to find out the method/syntax to set things like oscillator frequency, which I did in FC5 with an asm in-line to set/clear bits in the OSCCON. This does not seem to be 1-to-1 portable to FC7. Onward!

Jan

[medelec35]

Hi Jan,
Have you seen this post?

Martin

[jadiflow]

Hi Jan,
Have you seen this post?

Martin

I have now and it is exactly what I was looking for! Many thanks.

I also note that there is apparently no firm standard of naming those SFRs - I see WPUP and WPUPE; OPTION and OPTION_REG.

Jan