TODOPIC

Microcontroladores PIC => Lenguaje C para microcontroladores PIC => Mensaje iniciado por: halowin en 17 de Julio de 2012, 06:01:51

Título: Fichero .hex grande !!!
Publicado por: halowin en 17 de Julio de 2012, 06:01:51
Hola a todos.

Estoy iniciandome en SDCC y para hacer una prueba he creado un pequeño programa tipico que enciende un led, espera 500 milis y lo apaga en un bucle infinito.

Lo compilo con SDCC y me genera un .hex de 2346 bytes, esto es una pasada ¿no? , es tan grande que no cabe en un Pic16f84a con sus 1024 palabras de 14 bits????

Este programa en ensamblador no creo que llegara nia 100 palabras.

Un saludo
Título: Re: Fichero .hex grande !!!
Publicado por: rivale en 17 de Julio de 2012, 06:59:09
no conozco ese compilador, pero estas seeguro de que el archivo que mide eso es el .hex?, el que suele medir esos tamaños es el .cof, que se usa para debuggear en proteus
Título: Re: Fichero .hex grande !!!
Publicado por: halowin en 17 de Julio de 2012, 07:40:46
no conozco ese compilador, pero estas seeguro de que el archivo que mide eso es el .hex?, el que suele medir esos tamaños es el .cof, que se usa para debuggear en proteus

Hola rivale, pues si, seguro.
Lo he compilado dos veces porque no me lo creia, una desde la linea de comando y otra desde el entorno de desarrollo Piklab de Linux.

Si eso va a ser asi pues lo tengo crudo, porque si ese miniprograma ocupa eso, quería hacer uno un poco mas complejo pero veo que va a ser imposible programar en C (para ese pic) , y es que lo tengo que hacer en C porque necesito calculos con numeros reales y en ensamblador sería complicadisimo.

Gracias.
Título: Re: Fichero .hex grande !!!
Publicado por: rivale en 17 de Julio de 2012, 07:45:15
prueba con CCS, es muy facil y nunca me ha generado una archivo tan grande.
podrias subir el archivo que te crea para darle un vistaso
Título: Re: Fichero .hex grande !!!
Publicado por: halowin en 17 de Julio de 2012, 07:50:06
prueba con CCS, es muy facil y nunca me ha generado una archivo tan grande.
podrias subir el archivo que te crea para darle un vistaso

El CCS es comercial y paso de él, me he ido a SDCC porque es libre como todo lo de Linux.

A la tarde subo el fuente.
Título: Re: Fichero .hex grande !!!
Publicado por: rivale en 17 de Julio de 2012, 08:04:01
tambien el hitech  o cx8 es libre, seria otra opcion si el sdcc no te lo permite
Título: Re: Fichero .hex grande !!!
Publicado por: AngelGris en 17 de Julio de 2012, 09:56:39
  Yo uso PikLab y pasé de usar SDCC por el mismo motivo. Me generaba HEX grandes (no tanto) apenas unos bytes mayor a los que genera HiTech.
Título: Re: Fichero .hex grande !!!
Publicado por: pajaro en 17 de Julio de 2012, 10:57:31
Hola
amigo algunos compiladores tiene cargados en los includes librerias que no usan y engrandecen
el fichero verifica que librerias le incluyes.

¿Puedes poner el codigo que usas?,
 eso tiene toda la pinta de ser las librerias de cargado.
No lo estaras cargando con modo depuracion ..¿verdad?

ese problema de engrandecer el binario o el exe soli pasar con el devc++ en linux o un win
con la plantilla de por defecto, por que cargaba librerias visuales y otras gaitas que no se usaban.

Espero que nos cuentes más.

Un saludo.

Título: Re: Fichero .hex grande !!!
Publicado por: BrunoF en 17 de Julio de 2012, 12:12:09
Hola.

No confundas el tamaño del fichero .hex con la cantidad de instrucciones útiles en él. El .hex tiene siempre un tamaño mayor comparado con la cantidad de instrucciones de programa en él, ya que no es un fichero binario, sino uno que es legible para el software programador.

Título: Re: Fichero .hex grande !!!
Publicado por: halowin en 17 de Julio de 2012, 17:31:06
Hola y gracias por contestar a todos.

Os dejo el fuente:

Código: [Seleccionar]
//#include <stdlib.h>
//#include <stdio.h>
#include <pic16f84a.h>
#include <delay.h>


//unsigned int i;

/* define selected target processor */
//#define __16F84A

void main(void) {

  // ambos puertos de salida
  TRISA = TRISB = 0;

  // saco un 0 por todos los bits de ambos puertos
  PORTA = 0;
  PORTB = 0;

  // bucle infinito
  while(1) {
    PORTB = 0b00000001;  //enciendo el led del pin 0
    delay_ms(500);
    PORTB = 0b0;  //apago el led del pin 0
    delay_ms(500);
  }
}

Ahora si compilo el programa en consola, el .hex ocupa 2436 bytes y si lo compilo con Piklab el .hex ocupa 2536.

He comentado los dos primeros includes y no ha variado en absoluto el tamaño.

Gracias de nuevo.




Título: Re: Fichero .hex grande !!!
Publicado por: halowin en 17 de Julio de 2012, 17:34:08
El fichero delay.h es esto:

Código: [Seleccionar]
#ifndef FREQ
    #define FREQ 4000
#endif

#define escala_ms  FREQ/4000;

void pausa( unsigned char pausa_ciclos )            //tiempo = (4 * pausa_ciclos + 1)µs , para 4MHz ;
{    pausa_ciclos;                                  // pausa_ciclos debe ser >=2
    __asm                                            // "pausa_ciclos" ya está en w
    sublw 1   
    bucle_pausa:
    addlw 1
    btfss STATUS,0
    goto bucle_pausa
    __endasm;
}

void delay_ms( unsigned int valor_ms )              // delay en milisegundos
{
    valor_ms = valor_ms * escala_ms;
    while (valor_ms > 0 )
    {
        pausa(247);
        valor_ms--;
    }
}
Título: Re: Fichero .hex grande !!!
Publicado por: halowin en 17 de Julio de 2012, 18:48:09
A ver, aqui veo una cosa un poco rara:

En el entorno Piklab si muesto el fichero .hex veo que llega hasta '0x01b4' que eso son 436 bytes en decimal, pero el fichero en disco tiene 2436 bytes ?????


(http://)
Título: Re: Fichero .hex grande !!!
Publicado por: pajaro en 17 de Julio de 2012, 18:52:23
Hola amigo

yo hice el mismo programa con ccs y
el tamaño me lo da de 1k
tambien me dice cuanto ocupa de ram y de rom 7% en ambos
.
otra cosa..prueba a quitale el retardo.
¿cuanto te ocupa?
hay alguna diferencia..
Título: Re: Fichero .hex grande !!!
Publicado por: AngelGris en 17 de Julio de 2012, 20:16:58
  Halowin, ten en cuenta que a veces aparece un espacio vacío y luego siguen los datos en lo visualizado desde PikLab.

  En cuanto a lo que ocupa el HEX, prestale atención a lo comentado por BrunoF, puesto que en dicho fichero se incluyen otros datos... De hecho podés buscar aquí en el foro que hay un artículo muy bueno que explica el formato del archivo HEX.
Título: Re: Fichero .hex grande !!!
Publicado por: pajaro en 18 de Julio de 2012, 08:24:29
hola

El enlace al que se refiere AngelGris creo que es este:

El Fichero .HEX explicado

http://www.todopic.com.ar/foros/index.php?topic=23342.0

Un Saludo
Título: Re: Fichero .hex grande !!!
Publicado por: AngelGris en 18 de Julio de 2012, 11:00:07
   Exactamente Pajaro!!! ese es el artículo al que me refiero.
Título: Re: Fichero .hex grande !!!
Publicado por: halowin en 18 de Julio de 2012, 12:23:17
Hola amigo

yo hice el mismo programa con ccs y
el tamaño me lo da de 1k
tambien me dice cuanto ocupa de ram y de rom 7% en ambos
.
otra cosa..prueba a quitale el retardo.
¿cuanto te ocupa?
hay alguna diferencia..

Como me pediste, he comentado el include del delay.h y ,claro, las dos llamadas a las dos pausas de 500 milis y el resultado es:

El .hex ha pasado a ocupar (visto desde desde Piklab) 0x00E6 palabras = 230 bytes (o palbras no lo tengo muy claro que es eso) y en disco ha pasado a ocupar 1300 bytes (esto si son bytes) de lo que se deduce que ese fichero delay.h ocupa 206 (palabras) en la memoria o al menos en el .hex.

Saludos






Título: Re: Fichero .hex grande !!!
Publicado por: diguito_69 en 18 de Julio de 2012, 18:40:49
El archivo .hex no sirve para "medir" el código compilado, ya que este incluye información adicional.

Por ejemplo en una linea de una archivo .hex de 43 caracteres, que serian igual a 43 bytes, solo se representan 16 bytes de codigo, que serian unas 8 instrucciones de ensamblador.

Si queres saber cuanto ocupa el código compilado tendrías que ver al final de los archivos .asm para saber cuanto ocupa un archivo compilado en particular.
Y el mapa de memoria, archivo .map, para saber el total de bytes a grabar en el pic.

Esto aparece al final del archivo .asm generado al compilar tu código:
Código: ASM
  1. ;       code size estimation:
  2. ;          54+    8 =    62 instructions (  140 byte)

Como ves ocupa solo 140 bytes una vez compilado el codico c que pusiste.

En el archivo .map aparece esto:
Código: [Seleccionar]
Program Memory Usage
                               Start         End
                           ---------   ---------
                            00000000    0x000001
                            0x000144    0x000181
                            0x0000f5    0x000143
                            0x00009e    0x0000f4
                            0x0001be    0x0001be
                            0x000002    0x00009d
                            0x000182    0x0001b5
                            0x0001b6    0x0001bd
 
                            447 program addresses used

Como ves 447 bytes ocupa en total el programa, este incremento se debe a que la función delay_ms utiliza multiplicación y división entera.

Saludos.

Título: Re: Fichero .hex grande !!!
Publicado por: halowin en 19 de Julio de 2012, 04:41:08
El archivo .hex no sirve para "medir" el código compilado, ya que este incluye información adicional.

Por ejemplo en una linea de una archivo .hex de 43 caracteres, que serian igual a 43 bytes, solo se representan 16 bytes de codigo, que serian unas 8 instrucciones de ensamblador.

Si queres saber cuanto ocupa el código compilado tendrías que ver al final de los archivos .asm para saber cuanto ocupa un archivo compilado en particular.
Y el mapa de memoria, archivo .map, para saber el total de bytes a grabar en el pic.

Esto aparece al final del archivo .asm generado al compilar tu código:
Código: ASM
  1. ;       code size estimation:
  2. ;          54+    8 =    62 instructions (  140 byte)

Como ves ocupa solo 140 bytes una vez compilado el codico c que pusiste.

En el archivo .map aparece esto:
Código: [Seleccionar]
Program Memory Usage
                               Start         End
                           ---------   ---------
                            00000000    0x000001
                            0x000144    0x000181
                            0x0000f5    0x000143
                            0x00009e    0x0000f4
                            0x0001be    0x0001be
                            0x000002    0x00009d
                            0x000182    0x0001b5
                            0x0001b6    0x0001bd
 
                            447 program addresses used

Como ves 447 bytes ocupa en total el programa, este incremento se debe a que la función delay_ms utiliza multiplicación y división entera.

Saludos.



Muy intersante, nunca me había fijado en eso.

Gracias por la info 'diguito'.