Fichero .hex grande !!!

[AngelGris]

   Exactamente Pajaro!!! ese es el artículo al que me refiero.

[halowin]

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

[diguito_69]

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.

[halowin]

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'.