TODOPIC
Microcontroladores PIC => dsPIC => Mensaje iniciado por: togarha en 15 de Enero de 2007, 09:17:55
-
Buenas!!!
Alguien ha desarrollado un bootloader en C30?? Estoy interesado en implementarlo, puesto que necesita algunas funciones especiales. La idea del bootloader es que si a medias de reprogramarse se corta la comunicacion, y por tanto el programa queda corrupto, el bootloader pueda reponer el programa que tenia anteriormente. Para esto habia pensado en que el pic tenga una memoria externa, lo primero que haga cuando se quiera grabar un programa nuevo sea copiar el suyo viejo a la memoria externa y despues reciba los datos de programacion nuevos. Si no acaba de recibir todos los datos, el pic vuelve a leer la memoria externa y vuelve a programarse con el programa que tenia anteriormente...
Bueno, se acepta cualquier idea o cualquier ayuda de alguien que quiera unirse al proyecto...
Un saludo,
-
Buennass:
Me parece interesante la idea Torgarha, yo he utilizado una memoria spi, la 25LC256 de 256 K, de microchip con el C30, así que si necesitas información la compartiremos,
saludos,
-
Buenas,
Yo en principio voy a usar una memoria dataflash (por otras cuestiones) en concreto al AT45DB21 (2Mb) que es SPI tb, pero bueno, eso es lo de menos, el codigo principal puede ser el mismo y la funcion de leer/grabar en la memoria distinta.
Un saludo,
-
¿Y no se podría utilizar la propia memoria RAM del dsPIC para hacer una copia de seguridad de la Flash mientras se reprograma?
-
Buenas!!!
Es cuestion de capacidad nocturno, ten en cuenta que cuando programas un nuevo codigo no sabes lo que ha cambiado respecto al anterior (si te pones en el peor caso cambia todo), entonces, si tu flash es de 128kb (por ejemplo) y tu ram es de 16kb, no puedes guardar toda la flash en la ram por si se produce un error en cualquier momento...
saludos
-
Obvio :lol:
-
Buenas de nuevo,
En microchip he encontrado el ejemplo de codigo: "CE209 - Flash RTSP code example" que es un ejemplo de como escribir una pagina de flash en C30 en un PIC24H y/o dsPIC33F, me pregunto si valdra tambien para PIC24F.
Quizas es una manera de empezar...
-
Buenas!!!
Es cuestion de capacidad nocturno, ten en cuenta que cuando programas un nuevo codigo no sabes lo que ha cambiado respecto al anterior (si te pones en el peor caso cambia todo), entonces, si tu flash es de 128kb (por ejemplo) y tu ram es de 16kb, no puedes guardar toda la flash en la ram por si se produce un error en cualquier momento...
saludos
Solo una humilde sugerencia.
Si bien no he programado los dspic aún (me pedí unos samples, ya veré cuando me llegan!), sí lo he hecho con los pic18.
El punto está en que siempre siempre tendremos más memoria flash que ram, esto es bastante obvio por multiples razones que no viene al caso mencionar pero sino fijarse en su PC a ver cuanto de RAM tiene y cuanto de Disco Duro. :)
El punto es que un bootloader, puede funcionar tranquilamente si solamente verifica por páginas. En los 18F (en los 18FxxJxx la cosa cambia) se puede escribir de a cada 64 bytes por vez. Entonces la técnica consiste en grabar 64 bytes y verificarlos ahi mismo. Eso permite que con poca RAM se pueda leer/verificar toda la flash. Y eso que la flash puede llegar hasta los hay 128Kbytes.
Otra forma sería grabar todo lo que haga falta y luego con intervención de la pc nuevamente, verificar su contenido.
A lo que voy es que no hace falta tener 2 copias de la flash para hacer una actualización/verificación. De hecho en los 18F está previsto (supongo que en los dspic también) que el sector de bootloader esté protegido para lectura/escritura con lo cual si algo sale mal, la lógica del mismo software podría actuar en consecuencia.
Saludos
-
Buenas maunix,
Creo que no has entendido la cuestion de grabarlo en una memoria externa...
Ya sabemos que se puede verificar sea por pagina o cada 64bytes, pero que pasa si envias 3 bloques de 64bytes y el 4º no llega bien y ya pierdes la comunicacion con el programador? Sigue funcionando el pic? la respuesta es no, porque para que funcionase cada bloque deberia ser totalmente independiente del otro en cuanto a funcionalidad, la cuestion de este bootloader es que en caso de que se corte la programacion a mitad, este recupere todo su programa anterior (si solo recuperas un bloque de 64bytes no tendra la funcionalidad correcta el pic, a no ser que los cambios entre versiones sean minimos...)
Espero haberme explicado....
Un saludo, y gracias por la observacion de todos modos...
-
togarha, creo que si te he entendido, el punto es que yo analizo la funcionalidad de otra forma, déjame reexplicar mi punto a ver si me puedo dar a entender o realmente estoy muy fuera de foco y no lo veo.
1. El bootloader no se borrará con lo cual el pic no queda acéfalo nunca. El pic sigue funcionando. No hablo de un simple bootloader que reciba bytes y los guarde, sino que haya una interacción 'inteligente' con la PC.
2. En un bootloader no hay "programador" sino precisamente una PC u otro microcontrolador, con lo cual "la pérdida de comunicación con el programador" estaría en el terreno de lo que al hardware corresponde. Una transferencia/grabación de esta índole no debiera llevar más que un minuto.
En este punto, si hablamos de una comunicación serie o usb, no debiera haber mayor problema. Es más si hay un corte en la comunicación el software del lado de la PC debiera advertir al usuario para repetir la acción. Precisamente por eso hablamos de un bootloader, donde el usuario puede estar ahí viendo qué ocurre.
3. El pic revisa todo lo programado y en cuyo caso si algo falta o falla (sea el bloque 3, 4, o cualesquiera), volverá a pedir al PC o al microcontrolador externo que le vuelva a enviar el paquete en cuestión.
Lo único que veo en contra del punto 2 y 3, es si la comunicación la pretendes hacer por algún medio inalámbrico donde no tengas total control del medio físico.
Hace tiempo diseñé una autoactualización por memoria flash externa i2c pero era para otro caso diferente en que el usuario se llevaba la memoria en cuestión y podía actualizar su equipo sin necesidad de tener una pc u otro hardware extra. Tal vez por esa razón me vi movido a hacer un humilde aporte, sumado a que pienso en el plazo cercano meterme con los dspic.
i) El pic comprobaba si su versión era diferente a la de la memoria, en cuyo caso hacia el upgrade.
ii) El bootloader nunca se borraba.
iii) El pic no queda acéfalo porque si algo falla vuelve a reintentar y a reintentar hasta mostrar un mensaje de error, en cuyo caso el operario deberá reintentar la operación o bien poner la memoria anterior. Esto es algo simple y todo ocurre en solo unos segundos, lo peor que podía pasar eran 2 cosas.
iii.a) pérdida de comunicación con la memoria i2c por algún problema de hardware.
iii.b) error de checksum en la memoria.
Ambas opciones las tuve que provocar intencionalmente porque no me había pasado que efectivamente ocurran.
Espero haber aclarado mi punto.
En resumen, no digo que la solución sea mala , solamente digo que para un bootloader con estas características donde en definitiva hay una pc presente del otro lado, no es necesario ese control por la memoria flash, pero sí es útil cuando el usuario no sabe ni jota de usar una pc o realmente no tiene porqué lidiar con todo ese hardware y simplemente se lleva la memoria y hace la actualización.
Saludos
-
Buenas maunix,
Vamos acercando posturas ;). Te pongo un poco más al dia para que puedas entenderlo. En realidad mi idea es que no haga falta el pc, luego hacer un programador independiente que pueda guardar el codigo nuevo y se lo remita al pic mediante rs-485 y/o bluetooth (poco a poco). Entonces, quiero hacer el codigo para que luego pueda adaptarlo tal cual sin modificar el bootloader. Pero como el dispositivo estaria en un sitio "poco accesible" pues si se rompe la comunicacion a mitad (sea el motivo que sea) pues que el dispositivo quede funcionando con el codigo antiguo:
- supongamos que tenemos un logger de temperatura en la casa de campo, hacemos cualquier mejora en el codigo y queremos actualizar el codigo, pero a mitad de actualizar se rompe la comunicacion y no tenemos manera de volver a comunicarnos (porque se nos haya roto el programador y no podemos arreglarlo in-situ), pues por lo menos que siga tomando datos hasta que podamos volver a ir con el programador arreglado para programar las mejoras.
Estaba contemplando una solucion similar a la que tu has comentado, en vez de copiar el codigo de programa interno a la memoria, y luego programar on-line, habia pensado en copiar el codigo nuevo a la memoria y una vez copiado correctamente (teniendo en cuenta checksums, etc), entonces resetear el pic y en el inicio que compruebe si tiene que actualizarse leyendo de la memoria...
Esta claro que si la comunicacion con la memoria es defectuosa no podemos hacer nada, se trata de evitar simplemente los mayores problemas posibles...
Mi memoria seria SPI como ya he comentado, una AT45DB (las i2c tipo 24lcxx tampoco tienen bastante capacidad para los dspic de mayor memoria flash)...
Saludos
PS: Mi idea era hacerlo en C por las facilidades a la hora de leer la memoria y demas, pero al final igual me toca hacerlo en ensamblador (sugerencia continua en los foros de microchip).
-
togarha, ahora que has aclarado bien el escenario entiendo tu punto y coincido con que es la mejor opción. 8) 8)
Lo de la sugerencia del assembler, es entendible desde el punto de vista de que tu código se haces más inmune , independiente y versátil a los cambios que quieras en el C30 en tus futuros software.
Por ejemplo si tu código depende de una cierta configuración del stack y en algún firmware eso debe cambiar por alguna razón... estas en problemas.
En cambio al hacerlo en assembler, tú comandas las cosas, usas lo que te plazca y donde te plazca y voilá! funcionará de maravillas seguramente.
Lo del tamaño de la memoria es entendible, yo tenía que actualizar 32KB nomás y no me preocupaba por la 2da copia :) :) por eso el i2c me permitia la comunicación con solo 2 pines (tenía el 100% de los pines ocupados).
Espero te salga todo muy bien.
-
Buenas,
maunix:
El bootloader desde memoria i2c que hiciste, lo hiciste en C o en asm? Si fuese en C me interesaria informacion, si es posible, pues no creo que el C18 (el cual no he usado nunca) se diferencie mucho del C30 (que llevo poco tiempo usando, pero por lo menos lo he usado...)
Un saludo,
-
Buenas,
maunix:
El bootloader desde memoria i2c que hiciste, lo hiciste en C o en asm? Si fuese en C me interesaria informacion, si es posible, pues no creo que el C18 (el cual no he usado nunca) se diferencie mucho del C30 (que llevo poco tiempo usando, pero por lo menos lo he usado...)
Un saludo,
Lo diseñé en C18 porque era siempre para el mismo equipo, es decir que nunca cambiaría radicalmente el sistema.
Tampoco tuve oportunidad de probarlo ya que fue un diseño pero no lo llevé a cabo porque el proyecto quedó 'para después'. De todas formas lo tengo por ahí dando vueltas (a la papeleta), así que si quieres podríamos ver de hacer algo para los dspic.
Tengo rutinas hechas para grabar la flash (que no son ninguna maravilla técnica pero funcionan) y rutinas para verificar la flash. Estas rutinas supongo que diferirán ya que se ajustan mucho a los registros de un C18 pero lo importante en esto creo que es la IDEA del funcionamiento más que el código en si.
Es importante conocer algunas limitaciones como la de que se actualizaba cierta funcionalidad pero otras no. Al estar protegido el área de booteo (que es la primer página) no se podría modificar/actualizar dicho área con lo cual la referencia a interrupciones debía quedar en llamadas 'afuera' de la zona de la primer página. Esto se logra manejando el archivo linker y obligando a que ciertas rutinas estén en ciertos lados de la memoria de programa.
Luego de eso aprendí unas cuantas cosas mas del C18 y mis softwares fueron mutando , tanto así que fue cuando comprendí que un bootloader 'genérico' debía estar hecho en ASM para evitar tener que lidiar con las particularidades de cada código en C que hiciese.
También me interesa aprender de C30 ya que en breve tendré algún dspic para "cacharrear" como dicen los amigos ibéricos, si no es práctico hacerlo enC30 podríamos intentar hacerlo en ASM :? , aunque tal vez se haga mas tedioso y largo de lo que esperamos jeje.
En cuanto a tiempo ahora dispongo de bastante poco pero como te dije puedo ayudar con la IDEA más que con la codificación.
-
Buenas,
Yo de bootloaders nada de nada, pero sobre lo que dices de que esta en la primera pagina y por tanto hay que modificar las referencias a las interrupciones (si digo alguna barbaridad no me lo tomes en cuenta), hay posibilidad de poner el bootloader al final del codigo de programa asegurando que la primera instruccion siempre sea una llamada a la direccion del bootloader?
Otra cosa, el Code Protection del PIC24F (es el que he mirado) solo es un bit, no va por zonas de memoria, que permite o prohibe la lectura externa, pero creo que desde codigo de programa es todo viable, entonces quizas el problema de las interrupciones sea menos no?
No se, son todo IDEAS como tu has dicho, porque no tengo ni idea de bootloaders, aunque me interesa bastante...
Un saludo,
-
Si te sirve de ayuda y/o inspiración, aquí hay un Bootloader para dsPIC con código abierto:
http://www.ingenia-cat.com/es/downloads.php
-
togarha es viable ubicarlo en otra posición de la memoria, el tema es que del micro que yo hablaba es un 18F y cómo dije antes debiera ponerme a ver bien la arquitectura de un dsPIC para darte una respuesta en concreto.
el bootloader lo puedes poner donde te plazca, pero quieras o no los pics (salvo los extremadamente viejos) arrancan o inican el Program Counter de la posicion 0x0000.
Entonces, en los 18F la región BOOT está en la primer página.
Esta región tiene protección de lectura (para evitar que algún vivo lea nuestro código) pero también protección de escritura, para evitar que el PIC se autoescriba en esa región.
Otra cosa que se puede hacer para evitar sobreescritura es que el mismo bootloader controle el rango de posición de memoria de programa que recibe para que evite grabar sobre donde está ubicado.
-
Wenas!!!
Nocturno:
Gracias por la informacion, ya la conocia, pero como ves cambian un poco los requisitos, y por tanto la programacion (aparte de tener que aprender asm30, que cambia bastante respecto al asm de la serie 16 que es el unico que conozco)...
La idea no es recibir los datos via puerto serie, sino ir leyendo de una memoria externa... Quizas esto no es mucho, pero quizas es bastante (tanto por tamaño como por desarrollo en asm...)
maunix:
La idea seria que el pic controlase la direccion de memoria y evitase programar encima de algo que no queremos...
Saludos,
PS: Parece que esto se anima, se animara del todo???
-
Buenas,
Ya casi tengo implementado el bootloader, al final ha sido en asm :s y es para PIC24F. No es compatible con dsPIC y no estoy seguro de que lo sea de PIC24H (en ambos por temas de registros y demas...)
Cuando avance un poco mas lo publicare, pero sera en un tema distinto, ya que al final no es en C, sino en ensamblador, y este post tiene mas divagaciones que otra cosa ;)
Gracias a todos, no se si realmente alguno estubo interesado, pero espero que si y que siga interesado en ello...
Un saludo,
-
Buennass:
Claro que si, bienvenida sea toda la información, además puede ser la excusa perfecta para empezar con los pic24,
suerte con ello,
saludos,
-
Cuando me dijeron que tenía que trabajar con PIC18f8722, una de las cosas que más me llamó la atención fue la opción del bootloader, sin embargo, de lo que aprendí en la carrera y lo que plantea en este hilo, me preocupa más el diseño de un equipo que haga uso de esta potencialidad que la programación en sí de código en el bootloader que permita actualizar nuestro firmware.
Hay varias formas de diseño que se me ocurren al especto y en todas ellas lo que menos me llama la atención es cargar con un programador hasta donde está el equipo para meterle el código. Si yo tuviese que molestarme en ir a algún lugar, probablemente lejano, para actualizar el programa de un equipo: además de un programador, multímtero, ..., cargaría con una copia de la tarjeta a cambiar con el programa bien quemado, y si no tuviese esa tarjeta o el equipo no permitiese ese cambio, sencillamente que se quede sin actualizar. Es mejor un equipo funcionando que uno que no lo hace y todo eso donde el diablo dio las tres voces y nadie lo escuchó.
Sin embargo el poder de los bootloader lo veo en el caso donde la actualización se hace desde un terminal remoto, conectado por ejemplo a una LAN a través de algún dispositivo de red. En ese caso yo no tendría que moverme de mi puesto para actualizar el equipo remoto, aquí es donde entra a jugar el bootloader y la opción de copiar el programa en una memoria de espaldo es muy buena opción y se utiliza mucho. Mi PC tiene una opción de actualziar el BIOS desde Internet, pero si la actualización falla, se carga nuevamente desde una memoria ROM con la versión original de la tarjeta, nosotros por supuesto podemos utilizar una FLASH en lugar de la ROM, para tener la versión del sw n-1.
Otra versión del asunto, es el caso en que no hay una red, pero tenemos un montón de tipos que tienen que actualizar este programa en unos equipos regados por la ciudad, entonces le damos una memoria flash. Parecidas a las que usamos para llevar y traer nuestros datos y música. En este caso el tipo (que no sabe nada microcontroladores), llega al lugar conecta su memory flash al equipo y aprieta un botón, se actualiza el programa y se enciende un led verde diciéndole todo OK. Si la cosa falla, cargamos el programa de bakUp y encendemos un led naranja, para que el tipo cuando regrese me diga que vaya a arreglar yo el asunto. En este caso nos ahorramos el programador porque el propio PIC puede escribir en su memoria de programas SIN PROGRAMADOR.
Otro caso es un equipo conectado a una PC, y el usuario descarga de INTERNET, la última actualización del firmware, se conecta por puerto serie o USB y manda a actualizar, si todo está bien se le notifica OK, pero si no es así le decimos que lo intente y lo intente ... hasta que se convenza de botar el aparato y comprarse otro nuevo.
Como pueden ver en ningún caso tiene sentido el uso de un programador, de ninguna clase, y el objetivo fundamental es implementar mecanismos de actualización remota o semi-remota. Con esto quiero hacerles ver que antes de afrontar cualquier diseño lo primero que tenemos que evaluar es cómo va a funcionar el tareco, porque amigos, en este mundo todo tiene un costo, desde el tiempo hasta los circuitos y un diseño cuidadoso vale más que un programa que haga a un equipo sacar la lengua y chiflar.
Por otro lado estos mecanismos son bastante confiables y es por eso que una de las cosas que más tenemos que plantearno es si vale la pena meter una memoria de respaldo, si va a ser flash (más costosa) o ROM (una quilera), etc.
-
Buenas!
Lo primero siento si esto puede llegar a ofender a alguien...
reiniertl:
Me parece que no he entendido tu divagación. No me refiero que no entienda lo que estas diciendo, sino porque lo estas diciendo. El tema consiste en implementar un bootloader para PIC24 no en si es conveniente hacerlo. La conveniencia de ponerlo o no en un equipo tiene que evaluarla cada desarrollador, pero en el caso final que se decida poner, porque no tenerlo?
Creo que el uso que tu estas haciendo de la palabra programador, no es el mismo que puede haberse llegado a tratar en el post. Tu usas programador como el aparato que es capaz de hacer una programacion ICSP tipica de microchip, mientras que en el post se ha usado el termino programdor como el aparato que es capaz de enviar el codigo de programa al microcontrolador que se tiene que actualizar a si mismo en la forma en que este lo requiera.
Bueno, lo dicho, siento si alguien se ha podido sentir ofendido...
Un saludo,
-
Hola a todos, a ver si esta sugerencia os puede ayudar.
Yo programa un bootloader para un micro de la casa ATMEL y para evitar el problema del corte a mitad hice lo siguiente.
Cree un programa capaz de leer por la uart los datos y grabarlos en la memoria de programa del micro.
Antes de empezar a grabar nada, como el micro cuando hacia un reset iba directamente a la posición 0000h lo primero que hacia era grabar el codigo de un salto incondicional a la posición de memoria donde estaba en bootloader, luego grababa todo el codigo y al final le añadia lo que tenia que grabar en la posición 0000h.
De esta forma si se cortaba en cualquier momento la comunicación, apagando y volviendo a encender el programa que se ponia en marcha era el bootloader, siempre podia volver a intentar la grabación, y si se habia grabado bien, funcionaba el programa nuevo.
No se si me he explicado, pero realmente funciona bien. Ahora solo falta aplicarlo a la tecnologia de microchip.
Espero que os ayude la idea.
CheKeBo.
-
Hola a todos, a ver si esta sugerencia os puede ayudar.
Yo programa un bootloader para un micro de la casa ATMEL y para evitar el problema del corte a mitad hice lo siguiente.
Cree un programa capaz de leer por la uart los datos y grabarlos en la memoria de programa del micro.
Antes de empezar a grabar nada, como el micro cuando hacia un reset iba directamente a la posición 0000h lo primero que hacia era grabar el codigo de un salto incondicional a la posición de memoria donde estaba en bootloader, luego grababa todo el codigo y al final le añadia lo que tenia que grabar en la posición 0000h.
De esta forma si se cortaba en cualquier momento la comunicación, apagando y volviendo a encender el programa que se ponia en marcha era el bootloader, siempre podia volver a intentar la grabación, y si se habia grabado bien, funcionaba el programa nuevo.
No se si me he explicado, pero realmente funciona bien. Ahora solo falta aplicarlo a la tecnologia de microchip.
Espero que os ayude la idea.
CheKeBo.
Hola buenos dias , y disculpa lo tarde en este tema se que ya tiene mucho tiempo sin tocarlo pero lo que entiendo de usted es que con atmel cuando va actualizar ya no le importa la version anterios lo que le importa es realmente que actualice asi que si en el proceso de actualizacion se corta por cualquier razon cuando se restaure la cosa que entre nuevamente en bootlader y cargar la actualizacion y listo. en fin es bastante logico de hecho lo que se quiere es eso que se actualice, malo seria que luego que se corte el proceso ya el micro no entre mas en modo bootalder y asi se perderia todo.
Saludos y estamos en contacto.
Atten.
Alexander Santana.
Venezuela-Barcelona.