This is a C problem.
period periods[3] = {p1, p2, p3};
is invalid in C, as p1, p2 & p3 are struct variables, and not constants known at compile-time, therefore you cannot use them as initializers.
You may use macros to substitute the same constant values into p1, p2, p3 and periods[3] so that you don't have to duplicate the values:
#define P1 {1, {0, 0, 0, 1, 1, 14}, {20, 0, 0, 1, 1, 14}, 1}
#define P2 {1, {21, 0, 0, 1, 1, 14}, {50, 0, 0, 1, 1, 14}, 1}
#define P3 {1, {51, 0, 0, 1, 1, 14}, {59, 0, 0, 1, 1, 14}, 1}
period p1 = P1;
period p2 = P2;
period p3 = P3;
period periods[3] = { P1, P2, P3 };
Or you may simply avoid initializers altogether, and use explicit statements at the beginning of your program to initialize these arrays.
To test all below I used MPLAB 8.76, compiler XC8 ver 1.30:
First a digression/advice:
If you have switched to PIC16F690 recently: ~ 6 weeks ago I decided to abandon this chip, except for really small projects. It has little FLASH, little RAM and only 256 EEPROM. And you can not debug it easily on real target.
I use 18FK4620 now: it has 16 times as much FLASH (64kB) , 4 times more EEPROM (1kB),
and almost 16 times RAM (~ 4kB), it can run at up to 64MHz Fosc (!), plus more ports, etc.
And the MOST IMPORTANT: you can DEBUG 18F46K20 using standard PICKIT2 and MPLAB 8.76 ... 8.91 (I do not use MPLAB X yet, as I heard a lot of bad stories about it). And you do not need any extra interface boards etc.
Just your target board --> PICKIT2 (i.e. you do not have to switch to a mishap PICKIT3)
And price is very similar: 18F46K20 is ~ $2.90 and 16F690 is ~ $2.40 in retail.
NOW SOLUTIONS FOR YOU:
---------------------- Solution 1a:
Use something like this (and change '20' to the array size you want):
__eeprom unsigned char my_eeprom_values[20] =
{ 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17, 0x18, 0x19, 0x20,
0x21, 0x22, 0x23, 0x24, 0x25, 0x26, 0x27, 0x28, 0x29, 0x30};**
But if you use the above then you do NOT know where compiler will place these in EEPROM.
(Note though that __eeprom qualifier is ignored by XC8 compiler for many PIC18Fxxx devices)
---------------------- Solution 1b:
const unsigned char abc1 @ 0x2100 = 0x11; // @ EEPROM addr = 0
// ......
const unsigned char abc2 @ 0x2110 = 0x22; // @ EEPROM addr = 17**
Note that it looks that EEPROM in 16F690 starts at addr. 0x2100 (not 0xF00000 as you mentioned). I checked .map file after build.
I also checked the result of the above after compiling the code and then I viewed the EEPROM
using PICKIT2 (or if you debug under MPLAB using MPLAB SIM, then after you build the code, go to Menu -> VIEW -> EEPROM). You will see al data there as desired.
---------------------- Solution 1c:
You can mix (1a) and (1b) above, you can use 'int' instead of 'char', but :
- be aware that because __EEPROM_DATA does not allow to specify the eerpom address, one statement will overwrite some of the other ones. To illustrate this I placed 0x99 in locations that WOULD be overwritten. XC8 warns about this anyway - see the end of my post.
- Endian that XC8 uses 'swaps' bytes OF 'int' type: the below 'abc' data will be stored as : 22114433, instead of as 11223344.
---------------------- EXAMPLE:
Here is a tested example for 16F690 under XC8 ver 1.30:
const unsigned int abc1 @ 0x2100 = 0x1122;
const unsigned int abc2 @ 0x2102 = 0x3344;
__EEPROM_DATA(0x99, 0x99, 0x99, 0x99, 5, 6, 7, 8);
const unsigned int abc3 @ 0x2108 = 0x5566;
__EEPROM_DATA(0x99, 0x99, 0x83, 0x84, 0x85, 0x86, 0x87, 0x88);
__eeprom unsigned char my_eeprom_values[20] = \
{ 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17, 0x18, 0x19, 0x20,
0x21, 0x22, 0x23, 0x24, 0x25, 0x26, 0x27, 0x28, 0x29, 0x30};
Resulting EEPROM CONTENTS is this:
22 11 44 33 05 06 07 08 66 55 83 84 85 86 87 88
11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
27 28 29 30 FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF ...
So 0x(22 11 44 33) have overwritten 4 x 0x99. Same with 0x(66 55).
But note that the rest is just a plain copy of data in C code.
---------------------- Solution 2: 'yours':
Just as you said place as many '8 byte' long __EEPROM_DATA statements as you need.
What's wrong with this ? It is simple and works always.
Compiler places data in the order you will have them in your C code.
If you need some bytes to be unchanged then place 0xFF for them. Eg.
__EEPROM_DATA(0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF); // addr: 0x00 ... 0x07
__EEPROM_DATA(0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88); // addr: 0x08 ... 0x0F
__EEPROM_DATA(0x55, 0x66, 0x87, 0x65, 0xFF, 0xFF, 0xFF, 0xFF); // addr: 0x10 ... 0x17
etc.
During build in (1b/1c) XC8 compiler gives these warnings:
.... object "_abc1" lies outside available code space
... (1343) hexfile data at address 0x4200 (0x99) overwritten with 0x22
but I got data I wanted in EEPROM where I wanted it so I don;t care.
Memory Summary:
Program space used F00h ( 3840) of 1000h words ( 93.8%)
Data space used E4h ( 228) of 100h bytes ( 89.1%)
EEPROM space used 24h ( 36) of 100h bytes ( 14.1%)
...
-end-
Best Answer
It's right there in the user guide in black and white...
bitand__bitare exactly the same, except for the level of compatibility:So you can use
bitfor your own data type, variable name, function name, whatever you want, if you specify --STRICT on the command line, and still use__bitto specify a bit.