Bootloader y Mikroc

Buenos dias estimados, después de mucho buscar eh decidido hacerles la consulta.

Estoy intentando programar mis PIC con algún bootloader por puerto serial, intente programar un 16f88 con el bootloader de tiny pero sin mucho exito, luego intente con el bootloader de microchipc.com sobre un 16f877A y nuevamente no tuve mucho éxito.

En ambos caso el inconveniente fue que desconozco como se debe empezar el programa para que al inicio salte hasta la subrutina del bootloader. En el caso del tiny pude bajar el programa pero me pisa las primeras lineas y no lo puedo programar mas.

Cualquier experiencia que tengan con Mikroc y bootload me encantaría escucharla.

Gracias!! ...
 
En general depende, pero....
Un programa se compila desde la dirección 0h de la memoria.
Un bootloader puede estar al inicio o final de la memoria.
En caso de estar al inicio, el código que se quiere grabar por bootloader debe de estar compilado por sobre el código del bootloader, es decir que no se debe de compilar desde 0h, si no desde otra dirección mayor...

En MikroC creo que se puede establecer usando la directiva ORG o #pragma orgall, busca como usarlo.

Saludos
 
Funciono !

Mi experiencia para quien le sirva: Cuando trabajen con Mikroc y Bootloader se debe anteponer al inicio del programa antes de cualquier declaraciòn #pragma orgall 0x0004, esto hace que el programa que compilemos comience desde la linea de memoria 0x0004 y no "pise" el salto de nuestro bootloader que se aloja desde 0x0000 hasta 0x0003.

Pude solucionar el inconveniente para ambos PIC y ambos bootloader.


Código:
#pragma orgall 0x0004

void main() {

Trisa = 0;
Trisb = 0;
Trisc = 1;
Trisd = 0;

while (1){

UART1_Init(38400);
Delay_ms(100);
UART1_Write_Text("forosdeelectronica");
portd.f0 = 0;
portd.f1 = 0;
Delay_ms(700);
portd.f0 = 1;
portd.f1 = 1;

}
}

Gracias ByAxel
 

Adjuntos

  • orgall.txt
    403 bytes · Visitas: 15
Última edición:
Bien!!!... solo un detalle cuando trabajes con interrupciones, recuerda que una interrupción tiene cierto vector o dirección en la memoria donde siempre va... y no se como controle esto MikroC.... ante ese detalle es mejor colocar un valor correcto a #pragma orgall.... ya que con #pragma orgall 0x0004 se está pisando el vector de interrupción, si se trata de un PIC de gama media claro...

Saludos.
 
Respecto al Tiny Bootloader lo estuve probando hace poco en un PIC18F4550 vía serial, por estas fechas ando embuido en probar bootloaders, al cargarle el firmware del bootloader compilado al PIC corriendo a 115200 baudios ocurre que al enviarle el código de un programa por ejemplo un simple Blink de parpadear un led se lo carga y funciona bien como se espera , pero al hacerlo nuevamente ya no deja subir el programa, volví a cargar el firmware bootloader de cero e hizo las pruebas y otra vez al segundo o tercer intento deja de funcionar el tiny bootloader y de nuevo a cargarle el firmware , asi estuve un buen rato intrigado del porque deja de funcionar el bootloader a los pocos intentos de usarlo.

En la siguiente falla saque el PIC y lo puse en un PICKIT 3 para leerlo y exportar a un HEX, me dispuse a hacer la comparaciones y allí estaba a la vista la falla, había alteración o corrupción del código enviado y por eso el tiny Bootloader deja de funcionar a la primera o despues de varios intentos de enviar el código de un simple blink, a veces solo se alteraba el word de salto de la direccion 0000 o incluso los siguientes bytes también con lo cual el bootloader perdía la brújula y se plantaba, algo bueno que tiene el Tiny bootloader es su pequeño tamaño de 100 words y velocidad de subida pero creo que allí puede estar el problema que el envió sea tan rápido desde la aplicación y el firmware no hace comprobaciones mas exhaustivas que se termina corrompiendo el dato al recibirlo y grabarlo en el PIC, por si acaso le baje la velocidad de trasmisión de 115200 a 9600 baudios y obtuve el mismo resultado de corrupcion de datos, así que concluyo que la aplicación y el firmware del Tiny Bootloader no son del todo estables para usarlos y ojala su creador pudiera corregirlas así aumente de tamaño el firmware.

Ahora estaba probando con el Bootloader del MikroC por la via Serial en el mismo PIC18F4550 y el envió ya también es lentísimo como 5 minutos que parece que enviara todo el contenido de los 32 Kbytes innesesariamente, le aumente la velocidad de 9600 baudios a 115200 baudios y el mismo resultado, la subida muy lenta del programa blink que es pequeño, así que tuve que cambiar a la versión USB y allí si es como un rayo en el envió del hex del blink, asi que para este PIC es preferible usarlo en ese modo USB pero también me fije que el bootloader del MikroC para USB pesa como 6 Kbytes aproximadamente.

Estaba probando también el Mplab v5.xx con el XC8 para un simple proyecto de un blink y note en el archivo resultante HEX, que el programa del parpadeo me lo ubica a partir de la dirección 0802H, porque lo manda a partir de esa direccion? o es asi como siempre lo hace? , no he configurado nada de ubicaciones en propiedades del proyecto, en todo caso como puedo decirle al XC8 que quiero que mi programa lo ubique en la dirección 0000H o 001CH? o en otra direccion a conveniencia?
 
El bootloader tiene un espacio asignado, del cual se le debe indicar al programa que deseas subir a partir de qué direccion puede escribir.
Creo que se debe incluir un archivo del bootloader para tal efecto, o hacerlo manualmente.
Lamentablemente nunca tuve la oportunidad de usarlo, pero sé que es así...

Sube los archivos que utilizas, incluyendo el famoso blink...
 
Atrás
Arriba