¿Cual es el máximo tamaño de código que almacena un PIC?

[Hiddenfreak]

Hola a todos.
Soy nuevo con el tema de los PIC's.
Estoy haciendo un programa en un 16F876A para automatizar una sierra de corte y llegué al punto en que el compilador (CCS) me tira error de ROM y no me deja compilar.

Depuré el programa y lo pude solucionar, pero al querer agregarle una función mas, me vuelve a tirar el mismo error sin dejarme avanzar. Pareciera que me quedé sin espacio.
El datasheet dice que el PIC tiene "Up to 8Kx14 words of Flash Program Memory"; pero el archivo .hex ocupa 22kb.
No entiendo como es el asunto de la capacidad.

¿Se puede saber cuanto ocupa el código a medida que se escribe para poder ir especulando qué mas se puede agregar y qué no?

Desde ya, muchas gracias a todos. Aprendí mucho con este foro.

Saludos.

 

[Miembro eliminado 356005]

Bienvenido a los foros de electrónica, Hiddenfreak.

8K x 14 words quiere decir que hay 8K palabras de 14 bits, que es la longitud de la palabra en un PIC16F876A.

No te fíes del tamaño del archivo hex. Es un formato de texto. Fíjate más en el informe del compilador CCS, cuando termina de compilar tu programa. Ahí vendrá el tamaño ocupado por el programa.

Si, suponemos que de media, cada dos bytes del archivo hex equivale a una palabra del PIC... sí que estás en el límite.

 

[TRILO-BYTE]

una vez estaba fabricando un dispositivo X que estoy diseñando aun.

y vi que muchos de estos dispositivos X tenian el pic 16f886

asi que decidi hacer un clon de ese dispositivo X.

¿que paso cuando lo hise en CCS?
que se me acabo la memoria y generaba errores

la solucion fue quitar todos los delay que pude solo quedandome con el timer0 y en lugar de usar int
debi usar char con signo pues si los usaba sin signo se me desbordaba la memoria.
cosa que uno no se da cuenta.

tambien el uso indiscriminado de IF
son un lio ocupan mucha memoria en este caso tube que usar switch case
tambien el uso indiscriminado de los "printf" o "sprintf"
nimodo a jugar con las cadenas de caracteres.

en fin hay que tratar de ahorrar mucha memoria
cuando compilas te dice que tanto de la ROM y la RAM se esta usando

trata de comentar codigo que no es tan ecencial y ver que hace y que genera
trata de ir comentando lo que cres que haga fallos

 

[Miembro eliminado 356005]

Como se dice en Informática: hay que optimizar cuando el programa se haya entregado al cliente.

Eso quiere decir que Hiddenfreak debe ocuparse primero de terminar el programa, y luego, al ver lo que ocupa, buscar un PIC con la suficiente memoria como para poder almacenarlo.

 

[TRILO-BYTE]

andale eso , no me di a entender

la optimización de un programa creo que es la parte mas dificil, pues hay que jugar con la RAM y el contenido de la ROM.

muchas veces ayuda usar las funciones logicas del CPU como AND ,OR ,XOR ,NOR ,Rotar a la izquierda o a la derecha.

porque el usar funciones como multiplicar ,restar o cualquier otro algoritmo para multiplexar o desplazar un Bit es mas rapido con funciones propias del CPU.

otra cosa

mezclar floats con int ,int16 ,int32 y char es valido una a talvez 4 veces
no pasa nada pero ya mezclar mas de 5 el compilador empieza a mandar errores de compilacion.

ami me paso con mezclar los char con los int ambos son de 8 bits pero el compilador me empezo a dar errores de compilacion y del ROM.

 

[Miembro eliminado 356005]

La optimización de un programa creo que es la parte más difícil, pues hay que jugar con la RAM y el contenido de la ROM.

En efecto, es donde demuestras tu conocimiento del entorno.

En ocasiones, puedes pedirle al jefe que quieres un microcontrolador con más memoria, y si acepta, pues bien. Y si no, pues entonces tendrás que agarrar el calzador y apretar. O pasarte al ensamblador. Hasta que consigas meterlo, o el jefe se dé cuenta de que no, que no cabe. O te despida y contrate a otro que demuestre que sí.

mezclar floats con int ,int16 ,int32 y char es válido una a tal vez 4 veces no pasa nada pero ya mezclar más de 5 el compilador empieza a mandar errores de compilación.

A mi me pasó con mezclar los char con los int. Ambos son de 8 bits pero el compilador me empezó a dar errores de compilación y de ROM.

Lo que hay que hacer en esos casos es un cast (Conversión de tipos) para que la operación se realice bien.

Por ejemplo, si en la operación, el resultado va a ser un flotante, entonces convertimos los tipos de las otras variables a float. Ejemplo:

resultado = variable / 3.0;

No es lo mismo que poner

resultado = variable / 3;

Si el compilador no se da cuenta, podría estar realizando una operación entera (3 es entero) por lo que perderíamos mucha precisión. Entonces lo ponemos en notación de un flotante, y ya el compilador sabe que debe hacer una operación en flotante.

En el caso de una variable de otro tipo, por ejemplo int o long:

resultado = (float)var1_long / (float)var2_int;

que no es lo mismo que haber hecho

resultado = var1_long / var2_int;

En este segundo caso, se realizaría una división entera, y el resultado se almacenaría como flotante. En cambio, en el primer caso, estamos convirtiendo las variables a flotante, y ya el compilador sabe que debe hacer una división así, con el resultado también en el mismo tipo, y sin pérdida de precisión.

Con esto, sí que es posible mezclar cualquier tipo de variable con otras, las veces que quieras.