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.
