Para probar todo lo siguiente, usé MPLAB 8.76, compilador XC8 versión 1.30:
Primero una digresión / consejo:
Si ha cambiado a PIC16F690 recientemente: hace aproximadamente 6 semanas, decidí abandonar este chip, excepto para proyectos realmente pequeños. Tiene poca memoria flash, poca memoria RAM y solo 256 EEPROM. Y no puedes depurarlo fácilmente en target real.
Uso 18FK4620 ahora: tiene 16 veces más FLASH (64kB), 4 veces más EEPROM (1kB),
y casi 16 veces la RAM (~ 4kB), puede funcionar a hasta 64 MHz Fosc (!), más puertos, etc.
Y lo MÁS IMPORTANTE: puedes DEBUGAR 18F46K20 usando PICKIT2 y MPLAB 8.76 ... 8.91 (aún no uso MPLAB X, ya que escuché muchas historias malas al respecto). Y no necesitas ninguna placa de interfaz adicional, etc.
Solo tu tablero objetivo - > PICKIT2 (es decir, no tiene que cambiar a un contratiempo PICKIT3)
Y el precio es muy similar: 18F46K20 es ~ $ 2.90 y 16F690 es ~ $ 2.40 en ventas minoristas.
AHORA SOLUCIONES PARA USTED:
---------------------- Solución 1a:
Use algo como esto (y cambie '20' al tamaño de matriz que desee):
__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};**
Pero si usa lo anterior, NO sabe dónde los colocará el compilador en la EEPROM.
(Tenga en cuenta que el compilador XC8 ignora el calificador __eeprom para muchos dispositivos PIC18Fxxx)
---------------------- Solution 1b:
const unsigned char abc1 @ 0x2100 = 0x11; // @ EEPROM addr = 0
// ......
const unsigned char abc2 @ 0x2110 = 0x22; // @ EEPROM addr = 17**
Tenga en cuenta que parece que EEPROM en 16F690 comienza en addr. 0x2100 (no 0xF00000 como usted mencionó). Revisé el archivo .map después de la construcción.
También verifiqué el resultado de lo anterior después de compilar el código y luego vi la EEPROM
utilizando PICKIT2 (o si realiza una depuración en MPLAB utilizando MPLAB SIM, luego de compilar el código, vaya a Menú - > VER - > EEPROM). Verá todos los datos allí como desee.
---------------------- Solution 1c:
Puedes mezclar (1a) y (1b) arriba, puedes usar 'int' en lugar de 'char', pero:
- tenga en cuenta que debido a que __EEPROM_DATA no permite especificar la dirección eerpom, una declaración sobrescribirá algunas de las otras. Para ilustrar esto, coloqué 0x99 en ubicaciones que se sobrescribirían. XC8 advierte sobre esto de todos modos: mira el final de mi publicación.
- Endian dice que XC8 usa bytes de "swaps" de tipo "int": los siguientes datos "abc" se almacenarán como: 22114433, en lugar de como 11223344.
---------------------- EJEMPLO:
Aquí hay un ejemplo probado para 16F690 bajo XC8 versión 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};
Los CONTENIDOS EEPROM resultantes son los siguientes:
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 ...
Entonces 0x (22 11 44 33) ha sobrescrito 4 x 0x99. Lo mismo con 0x (66 55).
Pero tenga en cuenta que el resto es solo una copia simple de los datos en código C.
---------------------- Solución 2: 'tuyo':
Justo como dijiste, coloca tantas declaraciones __EEPROM_DATA de '8 bytes como lo necesites.
¿Qué pasa con esto? Es simple y funciona siempre.
El compilador coloca los datos en el orden en que los tendrá en su código C.
Si necesita que algunos bytes no se modifiquen, coloque 0xFF para ellos. P.ej.
__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.
Durante la compilación en (1b / 1c) el compilador XC8 da estas advertencias:
.... object "_abc1" lies outside available code space
... (1343) hexfile data at address 0x4200 (0x99) overwritten with 0x22
pero obtuve los datos que quería en la EEPROM donde los quería, así que no me importa.
Resumen de memoria:
El espacio del programa utilizó F00h (3840) de 1000h palabras (93.8%)
Espacio de datos utilizado E4h (228) de 100h bytes (89.1%)
Espacio EEPROM utilizado 24h (36) de 100h bytes (14.1%)
...
-end-