El mapeado de memoria del 18F2550: escribir y leer la flash

!! No es posible pregrabar el pic con la directiva #rom!! ¿¿o no sabemos hacerlo??

     Si Belando es capaz de comprender esto sin sacarme de mis casillas es que el escribir y leer de la flash es tan sencillo como sumar o restar con los dedos. A ver como me explico sin meter caña.

     El paso del 16F al 18F es duro y hay que tener paciencia. El mapeado es de 16bits o lo que es lo mismo 2 bytes de 8 bits cada uno. Vamos a demostrarlo sobre nuestro programa y visualizado con el Winpic800. Algo de publicidad hay que hacerle.

     Aquí tenemos nuestro programa cargado:

     Trabaja en 16 Bits ó 2Bytes de 8bits, que al caso es lo mismo, y numera de izquierda a derecha. Hasta aquí no hay nada raro. ¿Cómo numera contando a 8bits? pues no! no es de izquierda a derecha. De la posición 0x0000 (contado de 8 en 8bits el primero es el de la derecha y el segundo el de la izquierda del 0x0000. Vamos a contar la primera fila y queda más claro:

     !Vaya! Ahora se entiende lo mal que va el compilador, va estupendamente. Verdaderamente no nos importa ya que guardamos o leemos sin importarnos donde lo hace. El problema viene cuando querremos grabar algo y el compilador hace lo que quiere (aparentemente,claro está) Nosotros somos los que no lo hacemos bien. Vamos a ver si es verdad lo dicho y entendemos como funciona la flash y así usarla de EEprom. Para ello vamos a usar:

write_program_eeprom (address, data); //para escribir

read_program_eeprom (address); //para leer

     Para ello metemos en el programa que nos lea una posición de memoria y la grabe al final de la memoria y 0x3344 por la mitad:
                           ddd = read_program_eeprom(Alarm1[0]);

                           write_program_eeprom(0x5ff8,0x3344);
                           write_program_eeprom(0x7ff0,ddd);

     La posición 0x5FF8 se sale del mapeado pero escribirá en la posición: 0x5FF8 / 2 = 0x2FFC . La otra: idem de lo mismo. Ejecutamos el programa y  la posición 0x2FFC tiene que contener 0x44 en el octeto de menor peso y 0x33 en el de mayor peso. Vamos a verificar lo que ocurre:

     Nos ha detectado el grabado. No hace falta que lo busquemos... Si! ya que vamos a realizar otra prueba:

     y la otra al final:

     Si todo lo dicho anteriormente es cierto: si grabamos a partir del 0x5ff9 (uno más) tiene que meter el 0x44 donde esta el 0x33 y el 0x33 dos octetos a la derecha de donde está el 0x44. Veamos al ejecutar  write_program_eeprom(0x5ff9,0x3344); que ocurre:

     Para empezar no está mal. El error lo da en la misma posición de memoria al verificar y se aprecia el 0x44 en el byte de mayor peso. Vamos a verlo en el mapeado:

     Ahora es comprensible y ya no nos asusta que al grabar de la posición de memoria 8 a la 9 haya un poco de despiste (aparentemente lo graba al revés) y de la 9 a la A haya un mayor despiste (aparentemente se lo lleva a donde le da la gana y no es así). Espero que haya sido comprensible.

     Comprendido esto ya podemos usar la directiva #rom. Ahora si sabemos como se hace y donde va a parar lo que hacemos.

#rom 0x7f18={0x1832,0x3053,0x1944,0x1f20,0x1143,0x2433,0x2631,0x3233,0x0d0a}
                             //FALLO DE ELCTRICIDAD pte programar 32 caracteres

#rom 0x7f28={0x1841,0x3053,0x1944,0x1f20,0x1143,0x2449,0x2641,0x1441,0x304c,0x1120
                  ,0x1c41,0x3045,0x1e54,0x2241,0x1441,0x0a20,0x3030 ,0x0d0a}
                            //HA SIDO ACTIVADA LA LA ENTRADA: 0

     Ahora si está controlada la cosa. Tampoco era tan dificil ¿no?