Suerte espero tener yo también,aunque ningún problema...eso es...imposible.Ya los estoy teniendo y sólo estoy trabajando en una emulación software,sin hardware ninguno implicado,pero bueno,todo se andará
Volviendo al tema del bootloader...
Supongamos que no hay bootloader,como en el caso de ese programita que no consigues hacer funcionar.
Cuando el micro es reseteado o cuando le conectas la alimentación,él empieza la ejecución en la dirección 0 de la memoria de programa,es decir,en tu caso ejecutaría la instrucción:
goto empieza ; DE AHI QUE VAYA PRECEDIDA POR "org 0",PARA QUE SEA UBICADA EN ESA DIRECCION
...y acto seguido se pondría a ejecutar la rutina "empieza".
Previamente a todo esto,has necesitado programar el pic de alguna forma,ya sea con un programador o mediante ICSP, con el objetivo de que tu pic pueda correr la aplicación que has escrito y después le has transferido a su memoria de programa.
Ahora vamos a hacerlo con un bootloader.
Cada bootloader tiene sus peculiaridades y no todos tienen por qué comportarse exactamente de la forma que voy a detallar,pero para que le pilles mejor el rollo a como funciona el asunto,demos por hecho que sí.
Un bootloader es una aplicación,como puede serlo la tuya,pero con unas características y una misión concretas.Este bootloader se escribe en asm,C o en el lenguaje que sea y después se le transfiere al pic de la misma forma que se hace con cualquier archivo .hex.
Lo que hace especial al bootloader que convivirá con la aplicación es que éste ocupará las primeras posiciones de memoria,incluida la posición 0 (para asegurarse el "mando" del micro tras un reset),y también las últimas (donde está el grueso de su código, qué basicamente consiste en una rutina de manejo del puerto serie y de otra para escribir datos en la memoria de programa).
Ahora bien,todo bootloader que se precie debe estar pensado y desarrollado para funcionar en conjunto con un Downloader,el cual no es mas que una aplicación en el pc que le puedes cargar ficheros .hex para que los transfiera por el puerto serie,de una forma similar a la que midi-ox te permite cargar ficheros (sysex supongo) y mandárselos a tus sintes.
Vamos a suponer,por decir un número,que el bootloader ocupa las 10 primeras posiciones de memoria de programa del micro y las 100 últimas.
Pues bien,al hacerle un reset al pic,se empezaría a ejecutar el bootloader,que lo primero que haría sería preguntar por puerto serie "hey downloader, ¿estás ahí?" ,en el caso de no recibir respuesta,automáticamente el bootloader cedería el paso a la aplicación,haciendo por ejemplo un "goto 10",posición a partir de la cual debería estar la aplicación,que no soltaría los mandos del micro hasta el supuesto de producirse un nuevo reset.
Si al llamar a su downloader,el bootloader recibe respuesta,entonces se iría al grueso de su código en las última posiciones de memoria del micro y se quedaría en un bucle esperando órdenes de dicho downloader.Y la orden estrella sería "atento,que te envío byte a byte un archivo .hex para que lo vayas escribiendo en la memoria de programa".
Evidentemente,a la hora de escribir tu aplicación en el compilador o ensamblador,debes hacer uso de las directivas "org" para asegurarte de que dicha aplicación será colocada a partir de la posición 10 de memoria y no machaques el bootloader,si no,se jode el invento.
La comparación con una bios es perfecta,al arrancar o resetear un pc,quien primero entra en juego es la bios,si no recibe el estímulo a través del teclado para entrar en su menú,se quita de enmedio y deja paso al sistema operativo,quien se encargará de gestionar el hardware del ordenador y pemitir a los programas que puedan interaccionar con él,haciendo de intermediario.
De ahí que me refiriese a MIOS como un bootloader de dos niveles...
El primer nivel sería el encargado de hacer la primera llamada al donwloader (MIOS host) y llevar a cabo una posible reprogramación del micro con una nueva aplicación,o bien,si no recibiese respuesta a su llamada,se encargaría de dar paso,si no me equivoco,al segundo nivel,lo que sería el sistema operativo.Este sistema operativo implementaría el protocolo para poder comunicarse también con MIOS host,el cual, además de permitir la reprogramación del micro a través del primer nivel del bootloader,implementa unas pocas más de funcionalidades que pueden proporcionar versatilidad a las aplicaciones.De todo esto deduzco,y creo que no voy mal encaminado,que el sistema operativo no suelta el control del micro en ningún momento,digamos que lo comparte con la aplicación,ya que todos los datos,sean mensajes midi o sysex,pasan a través de él.Y en un momento dado una cadena sysex entrante podría ser perfectamente un comando enviado por MIOS host,por lo que el sistema operativo debe estar ahí atento para tomar las riendas o para dejar pasar los datos a la aplicación.
Agusto me he quedao con el tostón que he soltao
