Fichero .hex grande !!!

[halowin]

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

[rivale]

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

[halowin]

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.

[rivale]

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

[halowin]

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.

[rivale]

tambien el hitech  o cx8 es libre, seria otra opcion si el sdcc no te lo permite

[AngelGris]

  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.

[pajaro]

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.

[BrunoF]

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.

[halowin]

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.

[halowin]

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--;
    }
}


[halowin]

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 ?????

[pajaro]

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

[AngelGris]

  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.

[pajaro]

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