Hola, no se si se ha discutido antes del tema en el foro pero lo comento por si alguien se había fijado...
Muchos sabreis que es facil grabar la memoria Eeprom de los PICs utilizando WinPic800. Tan facil como rellenar "a mano" los valores en la pestaña de "Datos"; de esta forma cuando grabamos la memoria de programa del PIC, también se graban los valores que pusimos en la Eeprom.
Lo que yo no sabía, hasta ahora, es que utilizando una directiva en Mplab(en ensamblador al menos, en C18 no se si se puede...) se pueden guardar valores para la Eeprom en el archivo hexadecimal. Si insertamos lo siguiente en nuestro código:
ORG 0xF00000
DE 0x0A,0x0B,0x0C, 0x0D,0x0E,0x0F
Al compilar Mplab nos incluirá esa información(de la Eeprom) en el archivo Hexadecimal.
Mi sorpresa ha sido que al abrir el archivo .hex con WinPic800 he visto que el programa sólo reconoce los bytes impares y en posiciones de memoria consecutivas. Es decir, en vez de leer
Posiciones: 1 2 3 4 5 6
0xA 0xB 0xC 0xD 0xE 0xF
WinPic800 lee:
Posiciones: 1 2 3
0xA 0xC 0xF
Seguidamente, he corregido los valores en WinPic800 y he comparado los 2 hexadecimales... el caso es que WinPic800 guarda los bytes de la Eeprom como si fueran palabras(2 bytes) con el byte alto a 0. Por ejemplo, Mplab guardaría los valores consecutivos 0xA, 0xB, 0xC y 0xD(estoy obviando el resto de información de la linea del archivo .hex para no liar más
) como:
0A0B0C0D
... mientras que WinPic guardaría:
0A000B000C000D00
De esta forma es facil comprender que cuando Winpic800 lee un archivo generado por Mplab con información de la Eeprom, obvia el byte alto de cada palabra... pues para él en principio deberían ser = 0.
He planteado todo lo anterior porque estoy trabajando en mi propio software de grabación. Hasta ahora he utilizado Winpic800 para fijarme en como generaba los .hex. También encontré alguna diferencia más como que genera los bytes de la palabra de configuración en 2 lineas del .hex mientras que Mplab lo hace poniendo un único byte en cada linea... pero esto no es demasiado importante pues tiene fácil solución.
Mi duda es si alguién había notado lo que ocurre con la Eeprom y Winpic800. No me atrevo a afirmar que es un "bug" porque también pienso que es posible que el resto de compiladores(que no tengo por tanto no puedo comprobarlo
) lo hagan como Winpic800 y que el diseñador no se fijase en el compilador de Microchip, sino en otros.... pero realmente no tengo ni idea...¿?
Se me ólvido comentar que el problema en sí ocurre con los Pic18, todavía no me ha dado tiempo a comprobar otras familias. Espero que alguien pueda opinar al respecto de mi duda/exposición o que comente si le ha ocurrido lo mismo utilizando otros compiladores.
Saludos a tod@s!
(Por favor, que algún moderador elimine el duplicado... pues me aparecen mensajes de fallo en la base de datos) ==>> LO SIENTO!!!
