TODOPIC
Microcontroladores PIC => Primeros pasos - Iniciación a los microcontroladores => Mensaje iniciado por: amandapardo en 25 de Agosto de 2013, 15:31:00
-
Hola a todos,
he comenzado hace poco con la programación de pics y estoy haciendo pruebas con el pic16f1503 (http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en553475).
Este pic tiene "Flash Program Memory with self read/write capability", según lo que he entendido es un sustitutivo de las EEPROM a la hora de poder guardar información y que si el chip sufre algún corte en la alimentación, cuando se vuelva a alimentar se pueden recuperar los datos grabados antes de sufrir el corte.
He estado leyendo el datasheet pero no me entero muy bien de como funciona la programación de las funciones de lectura/escritura de la memoria flash.
Llevo un par de semanas buscando por todos lados algún ejemplo sencillo con el que poder experimentar y enseñarme a utilizar esta capacidad, pero no he encontrado nada.
También he buscado por este foro pero tampoco he visto nada.
Si alguien sabe de algún ejemplo, si es posible XC8 o en ensamblador, se lo agradecería mucho.
Saludos. Amanda Pardo.
-
Creo que todos los pics tienen esa funcion en la actualidad por lo cual puedes buscar ejemplos de cualquier pic de esa familia 16f, seguro que del 16f877a hay muchos ejemplos por ahi.
No es que sea un sustituto a las eeprom, se utiliza una eeprom cuando se requiere mucha capacidad, osea cuando la memoria del pic se queda corta.
Buscate ejemplos de pics mas utilizados, si no encuentras nada ya te explico yo por aqui porque es algo complejo.
-
Creo que todos los pics tienen esa funcion en la actualidad por lo cual puedes buscar ejemplos de cualquier pic de esa familia 16f, seguro que del 16f877a hay muchos ejemplos por ahi.
No es que sea un sustituto a las eeprom, se utiliza una eeprom cuando se requiere mucha capacidad, osea cuando la memoria del pic se queda corta.
Buscate ejemplos de pics mas utilizados, si no encuentras nada ya te explico yo por aqui porque es algo complejo.
Hola, he buscado bastante y no he encontrado nada .... de la familia 18f algo encontré en "PIC18 Peripheral Library" pero para pic de la familia 16f no he visto nada.
Si me puedes ayudarme te lo agradeceria.
-
En XC8 Para los PIC16F y PIC16F1, tengo entendido que se deben escribir las funciones que realizan la lectura o escritura de la FLASH, los algoritmos para realizarlo se encuentra en la hoja de datos del microcontrolador, en el caso de su microcontrolador se encuentra en la seccion FLASH PROGRAM MEMORY CONTROL, ahi puede ver los pasos a seguir para leer borrar y grabar en la memoria.
Saludos
-
A Bootloader is where the Pic is programmed with a small 'bootloader' program which then allows the PC to send a users program to the Pic for the bootloader to place into memory .Focke-Wulf Fw 190 (http://www.rctophobby.com/brands/dynam/dynam-rc-plane-rtf-1/dynam-upgraded-brushless-focke-wulf-fw-190-4-channel-remote-control-rc-scale-plane-rtf.html). so there is no need to use a hardware programmer like the Pickit2. :-/
-
Este pic tiene "Flash Program Memory with self read/write capability", según lo que he entendido es un sustitutivo de las EEPROM a la hora de poder guardar información y que si el chip sufre algún corte en la alimentación, cuando se vuelva a alimentar se pueden recuperar los datos grabados antes de sufrir el corte.
No deberías de usar la flash para esos menesteres, ten en cuenta que tiene un ciclo de vida muy corto, tan solo 1000 ciclos de borrado/escritura, luego el chip se queda inservible. Si necesitas un PIC con eeprom, tienes muchos para elegir de 8 bits. Los que trabajamos con PIC32, no tenemos esa suerte, ninguno tiene eeprom, aún así no debe de usarse nunca la flash para simular una eeprom, salvo que el programa grabe datos muy de vez en cuando, como puede ocurrir en un bootloader cuando se utiliza para facilitar actualizaciones de firmware en un producto comercial.
He estado leyendo el datasheet pero no me entero muy bien de como funciona la programación de las funciones de lectura/escritura de la memoria flash.
Llevo un par de semanas buscando por todos lados algún ejemplo sencillo con el que poder experimentar y enseñarme a utilizar esta capacidad, pero no he encontrado nada.
También he buscado por este foro pero tampoco he visto nada.
Si alguien sabe de algún ejemplo, si es posible XC8 o en ensamblador, se lo agradecería mucho.
Ejemplos en C, será dificil que encuentres, porque hasta la aparición de la serie XC de compiladores, Microchip no ofrecía ningún compilador en C para micros de 8 bits, puede que localices algo de Mikroe pero con sus librerias y compilador.
En ensamblador si que hay cosas, bájate las notas aplicativas AN851 y AN1310 y sus correspondientes fuentes, ahí tienes unos bootloader para PIC16 y PIC18, el fuente está en ensamblador, pero puedes ver como se borra y graba la flash.
El proceso consiste básicamente, en borrar la flash antes de grabarla, imprescindible para poder grabar, el borrado se tiene que hacer por páginas, no puedes borrar una sola direccion, en PIC32 el tamaño de una página es de 4096 bytes, supongo que con los 8 bits será de 1K o menos. Luego ya puedes grabar en la flash. Las rutinas en los fuentes de las notas AN851 y AN1310 están muy bien documentadas, no te costará nada extraer las rutinas de programa que borran y graban la flash.
Yo no perdería el tiempo con esto, salvo que quieras hacer un bootloader, si quieres eeprom para almacenar datos de manera permanente, elige otro PIC, tienes un montón con eeprom desde 64 hasta 256 bytes, y si necesitas más almacenamiento usa una eeprom externa por I2C o una tarjeta SD por SPI.
-
Creo que todos los pics tienen esa funcion en la actualidad por lo cual puedes buscar ejemplos de cualquier pic de esa familia 16f, seguro que del 16f877a hay muchos ejemplos por ahi.
No es que sea un sustituto a las eeprom, se utiliza una eeprom cuando se requiere mucha capacidad, osea cuando la memoria del pic se queda corta.
Buscate ejemplos de pics mas utilizados, si no encuentras nada ya te explico yo por aqui porque es algo complejo.
Hola, he buscado bastante y no he encontrado nada .... de la familia 18f algo encontré en "PIC18 Peripheral Library" pero para pic de la familia 16f no he visto nada.
Si me puedes ayudarme te lo agradeceria.
En cualquier bootloader para pic16 encontraras el codigo. De todas formas en el datasheet viene como hacerlo, te viene el proceso que viene a ser este:
-Leer el bloque completo
-Modificar lo que quieras escribir
-Pasar el bloque a la RAM
-Escribir de la RAM al bloque
Aun asi, te aviso que este proceso es largo y la escritura tarda unos ms, si se te va la alimentacion puede que no le de tiempo a escribir antes de que se quede sin alimentacion completamente.
-
En cualquier bootloader para pic16 encontraras el codigo. De todas formas en el datasheet viene como hacerlo, te viene el proceso que viene a ser este:
-Leer el bloque completo
-Modificar lo que quieras escribir
-Pasar el bloque a la RAM
-Escribir de la RAM al bloque
Te falta borrar la flash antes de escribir, salvo la primera vez si la página está toda a FF.
-
Gracias a todos, estoy viendo todas las indicaciones que me estáis haciendo a ver si consigo hacer una programación sencilla que funcione.
Por lo que deduzco de lo que me comentáis es que en ensamblador no tiene que haber problemas en programarlo, pero en cambio en C dependiendo del compilador, puede ser que tenga librerías que lo contemplen o no.
Me ha surgido una duda con lo que alguno habéis comentado, ¿se puede iniciar el bloque con una información primera durante la programación?
Voy a investigar todo lo que me comentáis y espero aclarame.
Un saludo a todos.
-
No es necesario librerias, para escribir en la flash solo necesitas modificar registros y poco mas, cualquier funcion que necesites la puedes implementar desde C con la correspondiente funcion en ASM
-
Por lo que deduzco de lo que me comentáis es que en ensamblador no tiene que haber problemas en programarlo, pero en cambio en C dependiendo del compilador, puede ser que tenga librerías que lo contemplen o no.
Busca por Google algún bootloader para XC8, alguno hay, así trabajas en C que es mucho más cómodo que el ensamblador.
Me ha surgido una duda con lo que alguno habéis comentado, ¿se puede iniciar el bloque con una información primera durante la programación?
Si claro, tendrás que asignar direcciones de flash concretas para las variables que vayas a almacenar, yo te puedo poner un ejemplo en C32, para los 8 bits debe de haber algo parecido. Estas son algunas de las instrucciones que yo pongo en mi bootloader pare reservar determinadas direcciones de la flash a ciertas variables, que leo con punteros y actualizo con las librerias NVMem, en este ejemplo las incializo todas a 0xFFFFFFFF en el momento de compilar el programa:
unsigned int __attribute__ ((space(prog), address(0x9D005104))) Reservada_62 = 0xFFFFFFFF; // Direccion reservada para usos varios
unsigned int __attribute__ ((space(prog), address(0x9D005108))) Reservada_63 = 0xFFFFFFFF; // Direccion reservada para usos varios
unsigned int __attribute__ ((space(prog), address(0x9D00510C))) Reservada_64 = 0xFFFFFFFF; // Direccion reservada para usos varios
unsigned int __attribute__ ((space(prog), address(0x9D005110))) Reservada_65 = 0xFFFFFFFF; // Direccion reservada para usos varios
unsigned int __attribute__ ((space(prog), address(0x9D005114))) Reservada_66 = 0xFFFFFFFF; // Direccion reservada para usos varios
En C32, el procedimiento completo para leer, modificar y regrabar la flash, sería así, algo parecido habrá para XC8, pero la librería NVMem es solo para PIC32:
// Leo página, FFF bytes, guardo en matriz
unsigned int pageBuff[1024]; // matriz 1024 elementos para guardar pagina (1024*4=4096 bytes)
unsigned int *userFlashPage;
userFlashPage = PAGINA_FLASH_VARIABLES; // Inicio pagina a copiar
memcpy((void *)pageBuff, (void *)userFlashPage, 4096);
// Reemplazo Numero serie de producto y Codigo producto
pageBuff[0] = Num_dispositivo;
pageBuff[1] = Codigo_producto;
// Borro pagina, total 4096 bytes
NVMemErasePage((void *)PAGINA_FLASH_VARIABLES);
// Grabo página con matriz temporal modificada, 4096 bytes
unsigned int ix;
for(ix = 0; ix < 1024; ix++)
{
NVMWriteWord((void *)(userFlashPage + ix), pageBuff[ix]);
}
-
No es necesario librerias, para escribir en la flash solo necesitas modificar registros y poco mas, cualquier funcion que necesites la puedes implementar desde C con la correspondiente funcion en ASM
Perdona no se si te comprendo bien,... me quieres decir que programando en C se pueden poner cosas escritas en ensamblador??
-
Asi es, en XC18 se usa asi:
_asm _endasm
por ejemplo:
_asm NOP _endasm
con eso incluyes un NOP en la linea correspondiente
Otra forma es creando un archivo .s e incluyendolo en el proyecto, creas tus respectivas funciones en asm y luego las puedes llamar desde C.
-
No es necesario librerias, para escribir en la flash solo necesitas modificar registros y poco mas, cualquier funcion que necesites la puedes implementar desde C con la correspondiente funcion en ASM
Perdona no se si te comprendo bien,... me quieres decir que programando en C se pueden poner cosas escritas en ensamblador??
En todos los lenguajes (C,Basic,etc) se pueden hacer partes en assembler, normalmente las partes que deben tener control muy rapido son escritas en assembler. :mrgreen: :mrgreen:
-
Gracias a todos, parece que Mikroe C, tiene librerías que lo soportan, lo probaré a ver si consigo hacer algo.
www.mikroe.com/download/eng/documents/compilers/mikroc/pro/pic/help/flash_memory_library.htm?TB_iframe=true&height=740&width=970
Saludos. Amanda
-
Hola a todos de nuevo,
tal y como os comenté estoy con Mikroe C intentando lo de escribir y leer la flash del pic16f1503.
Estoy haciendo un pequeño programilla basado en un ejemplo que provee Mikroe C pero para otro pic16 distinto, pero no consigo hacer que funcione.
Os lo dejo aqui para si alguien puede echarle un vistazo y decirme que esta pasando.
Saludos. Amanda
*********************************************************
char i = 0;
unsigned int addr, data_, dataAR[4][4] = {{0x3FAA+0, 0x3FAA+1, 0x3FAA+2, 0x3FAA+3},
{0x3FAA+4, 0x3FAA+5, 0x3FAA+6, 0x3FAA+7},
{0x3FAA+8, 0x3FAA+9, 0x3FAA+10, 0x3FAA+11},
{0x3FAA+12, 0x3FAA+13, 0x3FAA+14, 0x3FAA+15}};
void main() {
C1ON_bit = 0; // Disable comparators
C2ON_bit = 0;
PORTA = 0; // Todos los pines del puerto PORTA se ponen a cero
TRISA = 0b11111100; // Todos los pines del puerto PORTA menos PORTA.RA0 se
// configuran como salidas
Delay_ms(500);
addr =0x0700; // starting Flash address
for (i = 0; i < 4; i++){ // Write some data to Flash
Delay_ms(100);
// FLASH_Erase(addr+i*4);
FLASH_Write(addr+i*4, dataAR);
}
Delay_ms(500);
addr = 0x0700;
for (i = 0; i < 16; i++){
data_ = FLASH_Read(addr++); // P16's FLASH is 14-bit wide, so
Delay_us(20);
if ((i==0) & (data_ == 16298)){ // 16298 == 0x3FAA
PORTA=0b00000010; //ilumino en Proteus el led verde
}else{
PORTA=0b00000001; //ilumino en Proteus el led amarillo
}
Delay_ms(500);
}
************************************************************************
-
He estado mirando el datasheet de tu pic y he visto que el maximo de memoria que tiene es hasta 0x07FF y tu estas intentando escribir en 0x3FAA
http://ww1.microchip.com/downloads/en/DeviceDoc/41607A.pdf
En el apartado MEMORY ORGANIZATION
-
Estoy haciendo un pequeño programilla basado en un ejemplo que provee Mikroe C pero para otro pic16 distinto, pero no consigo hacer que funcione.
addr =0x0700; // starting Flash address
for (i = 0; i < 4; i++){ // Write some data to Flash
Delay_ms(100);
// FLASH_Erase(addr+i*4);
FLASH_Write(addr+i*4, dataAR);
}
Al margen de que puedan haber otros errores como el que comenta MerLiNz, no estás borrando la flash antes de grabarla, si no lo haces es imposible que funcione.
En cuanto a ese borrado comentado, dentro del FOR, tampoco funcionaría si lo utilizas. La flash se borra del tirón toda una página, no hay que borrarla dirección por dirección en bucle como has intentado probar (sin éxito supongo), de manera que de hacerlo tendría que estar ANTES y FUERA del bucle FOR y en una sola instrucción, a menos que quieras borrar más de una página.
No conozco el C de Mikroe, pero suponiendo que el resto del programa es correcto y no hay errores en el juego de instrucciones, podrías probar algo asi, date cuenta de que borramos la página completa de la flash, y luego entramos en bucle a grabar. Cerciórate también de que esa dirección que estás usando 0x700 existe en la flash de tu PIC, cógete el datasheet y mira el mapa de memoria.
addr =0x0700; // starting Flash address
FLASH_Erase(addr);
for (i = 0; i < 4; i++)
{
Delay_ms(100);
FLASH_Write(addr+i*4, dataAR); // Write some data to Flash
}
-
Creo que 0x3FAA es uno de los datos de la tabla que se utiliza para grabar en la flash..... la dirección apartir de donde se graba es: addr =0x0700; .... si no me equivoco, no?
He estado mirando el datasheet de tu pic y he visto que el maximo de memoria que tiene es hasta 0x07FF y tu estas intentando escribir en 0x3FAA
http://ww1.microchip.com/downloads/en/DeviceDoc/41607A.pdf
En el apartado MEMORY ORGANIZATION
-
Estoy haciendo un pequeño programilla basado en un ejemplo que provee Mikroe C pero para otro pic16 distinto, pero no consigo hacer que funcione.
addr =0x0700; // starting Flash address
for (i = 0; i < 4; i++){ // Write some data to Flash
Delay_ms(100);
// FLASH_Erase(addr+i*4);
FLASH_Write(addr+i*4, dataAR);
}
Al margen de que puedan haber otros errores como el que comenta MerLiNz, no estás borrando la flash antes de grabarla, si no lo haces es imposible que funcione.
En cuanto a ese borrado comentado, dentro del FOR, tampoco funcionaría si lo utilizas. La flash se borra del tirón toda una página, no hay que borrarla dirección por dirección en bucle como has intentado probar (sin éxito supongo), de manera que de hacerlo tendría que estar ANTES y FUERA del bucle FOR y en una sola instrucción, a menos que quieras borrar más de una página.
No conozco el C de Mikroe, pero suponiendo que el resto del programa es correcto y no hay errores en el juego de instrucciones, podrías probar algo asi, date cuenta de que borramos la página completa de la flash, y luego entramos en bucle a grabar. Cerciórate también de que esa dirección que estás usando 0x700 existe en la flash de tu PIC, cógete el datasheet y mira el mapa de memoria.
addr =0x0700; // starting Flash address
FLASH_Erase(addr);
for (i = 0; i < 4; i++)
{
Delay_ms(100);
FLASH_Write(addr+i*4, dataAR); // Write some data to Flash
}
de eso tambien me di cuenta, pero tambien pense que por defecto ya esta borrada, asi que como minimo le deberia escribir lo que pone, luego para modificar los valores ya si habria que borrar, pero para escribir por primera vez le vale el codigo.
-
Estoy haciendo un pequeño programilla basado en un ejemplo que provee Mikroe C pero para otro pic16 distinto, pero no consigo hacer que funcione.
addr =0x0700; // starting Flash address
for (i = 0; i < 4; i++){ // Write some data to Flash
Delay_ms(100);
// FLASH_Erase(addr+i*4);
FLASH_Write(addr+i*4, dataAR);
}
Al margen de que puedan haber otros errores como el que comenta MerLiNz, no estás borrando la flash antes de grabarla, si no lo haces es imposible que funcione.
En cuanto a ese borrado comentado, dentro del FOR, tampoco funcionaría si lo utilizas. La flash se borra del tirón toda una página, no hay que borrarla dirección por dirección en bucle como has intentado probar (sin éxito supongo), de manera que de hacerlo tendría que estar ANTES y FUERA del bucle FOR y en una sola instrucción, a menos que quieras borrar más de una página.
No conozco el C de Mikroe, pero suponiendo que el resto del programa es correcto y no hay errores en el juego de instrucciones, podrías probar algo asi, date cuenta de que borramos la página completa de la flash, y luego entramos en bucle a grabar. Cerciórate también de que esa dirección que estás usando 0x700 existe en la flash de tu PIC, cógete el datasheet y mira el mapa de memoria.
addr =0x0700; // starting Flash address
FLASH_Erase(addr);
for (i = 0; i < 4; i++)
{
Delay_ms(100);
FLASH_Write(addr+i*4, dataAR); // Write some data to Flash
}
Yo creo que si existe ... en el datasheet habla de un maximo de memoria que tiene es hasta 0x07FF ... por lo que deduzco que la 0x0700 es viable, no?
Respecto a lo que comentas del borrado de la memoria seria como repetir el bucle for del write pero esta vez con el erase, y este bucle erase antes del bucle write, no?
-
Creo que 0x3FAA es uno de los datos de la tabla que se utiliza para grabar en la flash..... la dirección apartir de donde se graba es: addr =0x0700; .... si no me equivoco, no?
He estado mirando el datasheet de tu pic y he visto que el maximo de memoria que tiene es hasta 0x07FF y tu estas intentando escribir en 0x3FAA
http://ww1.microchip.com/downloads/en/DeviceDoc/41607A.pdf
En el apartado MEMORY ORGANIZATION
si, no me di cuenta de eso, de todas formas para empezar a probar te recomiendo que hagas una simple escritura y una simple lectura ya que tanto dato sin haberlo escrito uno mismo es mas dificil de ver donde esta el fallo, osea lo que te digo es:
main() {
Flash_write(0x0700,0x00FA);
val=Flash_read(0x0700);
if(val=0x00FA) ilumino....
}
otra cosa que te falta es un while(1) en el final del codigo para que no se resetee constantemente
-
Yo creo que si existe ... en el datasheet habla de un maximo de memoria que tiene es hasta 0x07FF ... por lo que deduzco que la 0x0700 es viable, no?
Si, la última dirección de la flash sería la 0x07FF, que en decimal es 2047, el tamaño de flash para ese micro
Respecto a lo que comentas del borrado de la memoria seria como repetir el bucle for del write pero esta vez con el erase, y este bucle erase antes del bucle write, no?
No.
La flash no se borra dirección a dirección, se borra por páginas. Cuando lanzas la función de borrado, se está borrando una página completa
¿ cuanto es una página ?, yo solo trabajo con PIC32, en ese caso una página son 4096 bytes, supongo que en un PIC de 8 bit, una página serán 1024 bytes o incluso 512 bytes.
Es decir que cada que vez que llamas a la función de borrado, en realidad se están borrando 1024 bytes o 512 bytes, del tirón, teniendo en cuenta que ese pic tiene 2048 bytes de Flash, suponiendo que el tamaño de página fuera de 1024 bytes (que no lo se, solo lo sospecho), con solo dos llamadas a la función de borrado, tendrías TODA la flash limpia, si el tamaño de página fuera de 512 bytes, pues con 4 llamadas a la función de borrado, toda la flahs borrada. Para eso no hace falta meter la llamada en un bucle.
¡ Ojo ¡, que si borras la flash en la que en ese momento se está ejecutando el programa, el PIC se colgará. :mrgreen: :mrgreen:
-
En este caso, este pic16 hace los borrados por row, es decir, borra de 14 en 14bits por cada funcion de erase asi que tal como lo tienes esta bien, sin embargo ya te digo, un pic sin escribir ninguna vez no necesitas borrarla puesto que por defecto esta borrada.
-
Creo que 0x3FAA es uno de los datos de la tabla que se utiliza para grabar en la flash..... la dirección apartir de donde se graba es: addr =0x0700; .... si no me equivoco, no?
He estado mirando el datasheet de tu pic y he visto que el maximo de memoria que tiene es hasta 0x07FF y tu estas intentando escribir en 0x3FAA
http://ww1.microchip.com/downloads/en/DeviceDoc/41607A.pdf
En el apartado MEMORY ORGANIZATION
si, no me di cuenta de eso, de todas formas para empezar a probar te recomiendo que hagas una simple escritura y una simple lectura ya que tanto dato sin haberlo escrito uno mismo es mas dificil de ver donde esta el fallo, osea lo que te digo es:
main() {
Flash_write(0x0700,0x00FA);
val=Flash_read(0x0700);
if(val=0x00FA) ilumino....
}
otra cosa que te falta es un while(1) en el final del codigo para que no se resetee constantemente
Hola, al parecer esto que me comentas no se puede hacer ya que según dicen aquí siempre hay que hacerlo todo por bloques, en mi caso 16 words para el 16f1503.
Aquí es donde viene el ejemplo que cogí para intentar adaptarlo a mi pic, http://www.mikroe.com/download/eng/documents/compilers/mikroc/pro/pic/help/flash_memory_library.htm
El caso es que no paro de repasar todo, una y otra vez... y no consigo averiguar porque no me funciona.
Saludos de la que va a perder la cabeza. ;)
-
Perdón por la intromisión.
Tal vez malentiendo pero ¿es el programa (o algún procedimiento de él) lo que se pretende modificar durante la ejecución del mismo? ¿Alguien conoce de algún caso donde se tenga que alterar o cambiar un programa en ejecución?
Ciertamente se puede y se me hace lógico llegar a cambiar la información del área de datos incluyendo el área eeprom durante la ejecución de un programa (por ejemplo en la actualización de parámetros de operación) pero no me imagino hacer cambios en el programa mismo. Sobre todo que no se me ocurre de donde se leería el nuevo procedimiento.
Recuerdo el uso de overlays cuando las computadoras tenían 64KB o menos donde según la función reemplazaban procedimientos en la memoria de acuerdo a las necesidades (sistema operativo CP/M y similares) pero no se me ocurre hacer lo mismo en un controlador ya que se pueden seleccionar chips con más memoria de programa o en algunos incluso añadir chips de memoria adicionales.
Puedo equivocarme pero por más que le pienso no se me ocurre tal situación.
Si alguien conoce tal caso por favor ilústrenme. Bien valdría la pena conocer el caso para desarrollar la técnica correspondiente.
Un saludo y estaré muy al pendiente de este hilo.
-
Tal vez malentiendo pero ¿es el programa (o algún procedimiento de él) lo que se pretende modificar durante la ejecución del mismo? ¿Alguien conoce de algún caso donde se tenga que alterar o cambiar un programa en ejecución?
Esa es sencillita, un Bootloader.
Ciertamente se puede y se me hace lógico llegar a cambiar la información del área de datos incluyendo el área eeprom durante la ejecución de un programa (por ejemplo en la actualización de parámetros de operación) pero no me imagino hacer cambios en el programa mismo. Sobre todo que no se me ocurre de donde se leería el nuevo procedimiento.
En un bootloader, se cambia todo o parte del programa, para actualizar el firmware del chisme en cuestión, seguro que en tu casa estás rodeado de aparatos a los que les puedes actualizar el firmware (móvil, consola, televisor, etc...).
El firmware puede ser necesario cambiarlo para corregir bugs detectados, mejorar las prestaciones o añadir nuevas, cualquier producto electrónico que sale al mercado hoy en día, se puede actualizar gracias al bootloader que llevan cargado.
Yo lo primero que me planteé al hacer mis primeros diseños comerciales, fué programar un Bootloader, incluso antes de diseñar los circuitos, me puse a crear mi propio bootloader encriptado, para poder facilitar actualizaciones a mis futuros clientes, es algo imprescindible. Imagínate que pones un producto en la calle, y resulta que tiene errores de programa, a ver como corriges el problema con cientos o miles de unidades vendidas y dispersas por el "mundo".
-
Lo estabas haciendo en proteus no?? Porque no miras que valor contiene la rom en la direccion que escribiste? A ver si el problema es que no escribe, o que no lee.
-
Gracias por tu respuesta amigo planeta9999, pero sigo con la duda.
Cuando corres un bootloader para modificar o actualizar el firmware de un dispositivo como yo lo entiendo es que en sí el bootloader no corre en la memoria que se va a modificar sino en otra. Hasta donde sé es lo que se llama(ba) shadow ram o memoria sombra.
Como lo entiendo es por ejemplo en el BIOS de una PC donde al arrancar todo el contenido del eprom es copiado a la zona ram correspondiente. De esa manera es que es posible actualizar el BIOS. El procedimiento ya no corre desde la eprom sino desde su imágen en ram. Entre otras cosas por eso es muy importante no interrumpir el proceso de actualización cuando se está ejecutando. Si se interrumpe, el contenido de la eprom quedaría dañado o incompleto.
De lo anterior he visto procedimientos de "emergencia" donde se permite "regresar" la información de la imágen en ram al eprom. Por supuesto si es que no se ha apagado el equipo.
Quiero entender algo. De acuerdo a lo que leí en el hilo permíteme unas preguntas.
1. ¿Es posible borrar el área de la memoria de programa en forma zonificada?
2. En tu idea del bootloader, en sí el bootloader no puede ser cambiado ¿o sí?
3. Para la modificación del área de programa el origen de la información ¿es siempre externo?
De hecho mi duda general parte de la última pregunta ya que es en sí lo que no me puedo imaginar. Que un programa en ejecución se pueda modificar a sí mismo partiéndo de las propias condiciones que encuentre.
Lo he visto en técnicas de AI (inteligencia artificial). El caso más clásico es en los algoritmos genéticos y evolutivos, pero no se me ocurre en un microcontrolador sobre todo porque dichas técnicas corren en ram y memoria secundaria (disco duros, etc.).
Gracias por tu atención.
-
Gracias por tu respuesta amigo planeta9999, pero sigo con la duda.
Cuando corres un bootloader para modificar o actualizar el firmware de un dispositivo como yo lo entiendo es que en sí el bootloader no corre en la memoria que se va a modificar sino en otra. Hasta donde sé es lo que se llama(ba) shadow ram o memoria sombra.
Claro el bootloader, tiene que estar en una parte de la flash que no vamos a borrar, si no la liaríamos parda, y se bloquearía todo.
Todo el programa se almacena en la flash, normalmente el bootloader a partir de la primera dirección de la flash. Ese término de "shadow ram", no creo que sea aplicable a los microcontroladores, en todo caso a un PC y similares, para que los programas se ejecuten desde RAM más rápido, en un microcontrolador estamos muy limitados, TODO se ejecuta desde la flash, la RAM es solo para almacenar variables de trabajo.
Como lo entiendo es por ejemplo en el BIOS de una PC donde al arrancar todo el contenido del eprom es copiado a la zona ram correspondiente. De esa manera es que es posible actualizar el BIOS. El procedimiento ya no corre desde la eprom sino desde su imágen en ram. Entre otras cosas por eso es muy importante no interrumpir el proceso de actualización cuando se está ejecutando. Si se interrumpe, el contenido de la eprom quedaría dañado o incompleto.
Si eso en un PC, pero no es aplicable a los microcontroladores, date cuenta de que trabajamos con tamaños de flash y RAM muy pequeños en comparación con un PC.
1. ¿Es posible borrar el área de la memoria de programa en forma zonificada?
No es que sea posible, es que es obligatorio, por páginas, en los PIC32 son páginas de 4096 bytes, en otros micros más pequeños supongo que serán páginas de 1K o menos, yo hace muchos años que solo trabajo con PIC32, en cualquier caso la flash no se puede borrar por dirección, hay que borrar obligatoriamente un bloque de memoria, el tamaño de ese bloque ya dependerá de si el micro es de 8, 16, 32 bits...
2. En tu idea del bootloader, en sí el bootloader no puede ser cambiado ¿o sí?
Podría, pero es peligroso, si no se hace bien el PIC se quedaría bloqueado.
Aunque en principio parece algo absurdo, si que me lo planteé hace tiempo, para el caso de que algún fabricante (chino) me hackease alguna de mis placas, para esos casos liberar un firmware que regrabase el bootloader, se puede hacer, es decir que en vez de ser el bootloader el que actualiza el firmware, fuese el firware el que actualizase el bootloader. Siempre que no pises y borres la página en la que en ese momento se está ejecutando el programa, lo puedes hacer.
3. Para la modificación del área de programa el origen de la información ¿es siempre externo?
Es que interno, no tiene mucho sentido, una zona de la flash que actualice otra zona de la flash, ¿ para que quieres hacer eso ?.
Otra cosa es utilizar la flash para guardar variables que se conserven tras quitar alimentación al micro, en caso de que no tengas eeprom, como ocurre con los PIC32.
De hecho mi duda general parte de la última pregunta ya que es en sí lo que no me puedo imaginar. Que un programa en ejecución se pueda modificar a sí mismo partiéndo de las propias condiciones que encuentre.
Es que eso solo suele ocurrir en dos casos, un bootloader para actualizar fimware, y usar la flash simulando una eeprom, aunque en este segundo caso es para guardar datos, no programa.
Lo he visto en técnicas de AI (inteligencia artificial). El caso más clásico es en los algoritmos genéticos y evolutivos, pero no se me ocurre en un microcontrolador sobre todo porque dichas técnicas corren en ram y memoria secundaria (disco duros, etc.).
Ya, pero es que con los microcontroladores, jugamos con muy poca memoria, no se pueden aplicar algoritmos complejos para que el micro decida autoreprogramarse cuando quiera, reprogramar la flash desde el propio programa solo suele ser necesario en los bootloader, o cuando quieres usar la flash como memoria no volatil para guardar variables.
-
Gracias planeta9999. Duda aclarada.
-
Lo estabas haciendo en proteus no?? Porque no miras que valor contiene la rom en la direccion que escribiste? A ver si el problema es que no escribe, o que no lee.
Si utilizo proteus .... pero tengo el problema que al parecer mikroe c no esta dentro de la lista de compiladores que soporta proteus y no consigo hacer debug.
:? :? :? :? :? :?
-
te aparece el mensaje ese de que no tienes cargado el coff?? Para ello en vez del .hex debes seleccionar el coff que te genera y asi tienes debuger, yo cuando usaba mikroc+proteus podia debugear de esta forma. Ahora no recuerdo si el mikroC te generaba el coff o habia que elegir alguna opcion para que lo hiciese, en cualquier caso posible es porque yo lo usaba asi.