Autor Tema: memoria ROM insuficiente  (Leído 17836 veces)

0 Usuarios y 1 Visitante están viendo este tema.

Desconectado vasconinicolas

  • PIC16
  • ***
  • Mensajes: 124
Re: memoria ROM insuficiente
« Respuesta #30 en: 04 de Julio de 2008, 22:43:18 »
Si, digamos que el codigo esta adentro de un bucle for infinito.. se llama la funcion cada vez que las variables se ponen a 0, es una forma de retardo que uso para no perjudicar la interrupcion del TMR1, que tambien uso para otras funciones del programa que son mas prioritarias...
Espero explicarme bien..
Saludossssss

"No hacen ciencia los países ricos,
Son ricos los países por hacer ciencia"

Desconectado firepic

  • Colaborador
  • PIC24H
  • *****
  • Mensajes: 1130
    • JC Servicios
Re: memoria ROM insuficiente
« Respuesta #31 en: 04 de Julio de 2008, 22:44:44 »
Vasco, no creo que esa información que proporcionas sea suficiente para detectar dónde esta el problema. Habría que ver el código completo.
A veces los errores estan por donde uno menos está buscando.
Te recomiendo que hagas lo que te digo, trabaja con el ccs pero desde mplab. Allí puedes simular línea por línea y ver los valores de todos los registros y las variables del programa. Para mí es la mejor forma de trabajar en C.
Saludos, nos leemos!  :mrgreen:
"Por la presunción solo se ocasiona una lucha, pero con los que consultan juntos hay sabiduría" (Proverbios 13:10).
Visita Mi Sitio Web

Desconectado Gonzalo_BlackHawk

  • Colaborador
  • PIC24F
  • *****
  • Mensajes: 519
Re: memoria ROM insuficiente
« Respuesta #32 en: 04 de Julio de 2008, 22:45:35 »
Hola a todos.

Totalmente de acuerdo con Jfh900, la mayoria de la gente da por sentado muchas veces ciertos bugs del compilador cuando en realidad son errores de inherentes al código y no al programa que lo compila. Es una tipica conducta humana de justificar cosas a algo que nos evita la responsabilidad y en la mayoria de los casos no entendemos. Para citar un ejemplo, pasa lo mismo con los fenomenos paranormales, ahora tratan de explicarlos haciendo alarde de la mecánica cuántica, cuando en realidad nada tiene que ver y que la mayoria de la gente no tiene los conocimientos suficientes como para comprenderla. No lo tomes a mal vasco, no te estoy echando la culpa de nada, hoy es Viernes y me la agarro con la sociedad que a veces me irrita :D :D. Mil perdones si te he ofendido.

Bueno, me fui del tema. Desde mi experiencia, he visto solo 2 o 3 bugs comprobados del CCS y todos se han corregidos o se esta trabajando en ello, creo que el problema con CCS en realidad radica en el pobre manual que incluye y con él, es imposible aveces conocer los alcances y funcionamiento de las funciones built-in que trae y por lo tanto uno las utiliza para algo que no fueron diseñas y ahi mete la pata. Eso sería un bug? No lo creo, es simplemente una mala aplicación del código, en tal caso seguiria siendo culpa de la persona que escribe el programa, pero como ya dije, con un manual tan pobre como el que trae CCS es imposible saber con certeza como va a responder el código. Gracias al foro oficial de CCS, este foro y el MPLAB uno pude conocer un poco más acerca de como "piensa" este compilador. Obviamente CCS nunca puede llegarle al C18, por el simple hecho de que el segundo lo hizo la misma empresa que fabrica los microcontroladores, no hace falta decir más.

Yo todavia no agoto el CCS, pero con el C18 se puede hilar mucho más fino y es extremadamente potente is estas utilizando los PIC18xxxx.
Tengo entendido que el C18 solo compila para esta gama de PICs y si tu estas trabajando con PIC16xxxx vasco no se si servirá. Microchip habia lanzado un compilador C16 pero luego lo discontinuo, no se que habrá pasado. Además C18 no tiene soporte para punto flotante asi que manejar floats no debe ser tan sencillo. Tal vez Maunix o algun otro experto en C18 se pueda extender más que yo.

printf("Saludos"); :mrgreen:
"Siempre piensa si el jugo vale la exprimida..."

"La muerte esta tan segura de vencer que nos da toda una vida de ventaja."

Desconectado vasconinicolas

  • PIC16
  • ***
  • Mensajes: 124
Re: memoria ROM insuficiente
« Respuesta #33 en: 04 de Julio de 2008, 23:30:33 »
Gonzalo, totalmente de acurdo contigo jejeje, esto del viernes nos pega a varios y el cansancio acumulado de la semana piorrrrr.. jaja. En fin, mi pequeñisima experiencia con programas de nivel mas bajo como estos me trajo aparejado complicaciones por desconocimiento de la misma herramienta tal cual decis vos.. Tengo el manual en español pero es pobre y falto de ejemplos lo que ayuda a meter una y otra vez la pata. Quiza un poco mas en frio, despues de tomar un descanso, admito que de ningun modo he agotado el CCS... Y volviendo a seguir tus consejos voy a revisar otra vez el codigo para tratar de ver que esta pasando alli...
Aprovecho tu amable intervencion para consultarte a cerca de la instruccion #separate, que me incluiste en el codigo que desbordaba la memoria ROM.. Como funciona esa instruccion? Sabes que, si la comento, sigue compilando bien, muy seguramente porque has ordenado el codigo declarando las variables en ese archivo .h que creaste... Por cierto, Que diferencia hay en crear las variables dentro del codigo o en ese archivo .h??
Se que son muchas preguntas pero creo que pueden ser de utilidad para muchos entusiasmados como yo que se ven frenados por no conocer a fondo la herramienta..
Lejos de ofenderme, pido disculpas por mi calentura jajajaja y muchas gracias por su tiempo...
Nos leemos..
"No hacen ciencia los países ricos,
Son ricos los países por hacer ciencia"

Desconectado Gonzalo_BlackHawk

  • Colaborador
  • PIC24F
  • *****
  • Mensajes: 519
Re: memoria ROM insuficiente
« Respuesta #34 en: 05 de Julio de 2008, 08:21:06 »
Hola vasco, mira, yo cada vez que tengo que utilizar algo en CCS que no conozco o bien algo no funciona como me gustaria me echo una pasadita por el foro oficial de CCS (Sin animo de despreciar a todopic, por favor). Ahi seguramente alguien ha tenido la misma duda o bien una parecida, hay muchisimos ejemplos, y si realmente te parece que descubriste un bug, lo posteas y te responden si esto puede ser asi o si te has equivocado tu. Obviamente esta en el idioma anglosajón. Otra forma de descubrir como funciona CCS es agarrando MPLAB, tal como te lo ha dicho Fire. Otra forma es revisando la lista C/ASM  (el archivo con el formato .lst) que genera el compilador junto al .hex. Es un archivo que puedes abrir en el mismo CCS y que contiene el ASM del programa para cada parte del mismo, verás primero el lenguaje en C en forma de comentario y luego las lineas de ASM que lo representa, es muy útil, sobre todo para optimización.

las directivas #separate y #inline no forman parte del programa en sí que se va a ejecutar en el PIC, sino que le indican al compilador como generar el .hex. Las funciones que tu escribes pueden compilarse en forma INLINE, es decir, dos o más funciones se ejecutan como una sola, solo se utiliza un nivel de stack, estas se ejecutan más rápido y si deben llamarse más de una vez durante el programa el compilador simplemente copia y pega el código de estas cuantas veces se necesite. Salta a la vista que aunque este método ahorra stack y tiempo, no hace lo mismo precisamente con la ROM.

La contraparte son las funciones separadas (Que se definen con la directiva #separate), que se ejecutan en niveles diferentes de stack, y por lo tanto se pueden lograr funciones más pesadas en código que si son inline, para que te des una idea, el código dentro de las interrupciones serían funciones #separate por defecto ya que el programa tiene que saltar hacia otro nivel de stack para ejecutarlas, una vez que termina de ejecutarse la interrupción, el contador del programa vuelve el mismo hacia la función donde estaba y sigue ejecutandose con normalidad.

Ahora bien, te preguntarás ¿Porque a mi CCS nunca jamas me pidio definir como se compilan las funciones? ¿Porque habria de interesarme si yo escribo solo las funciones y el código se compila correctamente? ¿Entonces el código se compila siempre inline, o siempre separate?  :-) . Bueno, en realidad, por defecto, el compilador lo hace automáticamente, es decir, lo decide por él mismo. Supongamos dos funciones:

Código: C
  1. void Inicio() {
  2.    // Codigo.
  3. }
  4.  
  5. void Main() {
  6.    Inicio();
  7.    // Sigue el codigo.
  8. }

Si no incluimos en la linea anterior a la declaración de la función Inicio ni #separate ni #inline, el compilador se hace cargo de definir si la función será inline o separada, y como lo hace?, bueno, el algoritmo que decide esto lo desconozco, pero sé por experiencia que se rige bajo ciertas reglas básicas: Si la función Inicio solo se llama una vez durante todo el código es probable que el compilador decida hacerla inline, porque siendo separate no se hace más que desperdiciar tiempo y no se ahorra memoria.
Si la función se llama X veces durante el código, entonces es más factible que el compilador la defina separada, porque de lo contrario hay que utilizar aproximadamente X veces más ROM que la que necesita Inicio(), pues el compilador no hace más que repetir en memoria el código original.

En forma explícita, nosotros podemos indicarle si queremos compilar las funciones como inline (colocando #inline antes de la declaración de la función) o como separada (colocando #separate antes de la declaración de la función), con todos los riesgos que esto supone. Cuando yo definí una de las funciones en tu código como #separate, lo hice sabiendo que el compilador la estaba poniendo inline al procedimiento main y que ambas dos sumadas consumian una cantidad de ROM que te estaba desbordando la capacidad del PIC (Me di cuenta muy rapido mirando el call tree). Colocandola separadas, tendrías mucho mas margen antes de obtener el error al generar el .hex.
Entonces, porque ahora quitas el #separate y el programa sigue funcionando bien?, bueno, eso es porque has optimizado el código lo suficiente como para que ambas funciones sean inline y aun ási te sobre ROM.  Dado el caso, entonces no hay razón alguna para dejarla #separate, quita esta directiva y ahorraras un nivel de pila.

Ojo con implementar los #separate por solo el gusto de utilizarlos cada vez que nos falta ROM. El compilador te va a separar las funciones por mas que no tengas stack para hacerlo, eso lo aclara CCS en una parte de su manual. Primero optimiza y si no queda más remedio ahi usas el #separate.

Sigo en otro post el tema de los archivo header. No me tardo. :mrgreen:
"Siempre piensa si el jugo vale la exprimida..."

"La muerte esta tan segura de vencer que nos da toda una vida de ventaja."

Desconectado Gonzalo_BlackHawk

  • Colaborador
  • PIC24F
  • *****
  • Mensajes: 519
Re: memoria ROM insuficiente
« Respuesta #35 en: 05 de Julio de 2008, 08:45:33 »
Con respecto a tu pregunta sobre el archivo .h, utilizar este formato de archivo es más bien una convención que una necesidad para el PIC. El PIC solo entiende el hex asi que definir variables dentro de un archivo .c o .h es indiferente a nivel de micro, si dos variables son del mismo tipo y tienen el mismo alcance en un archivo .c que en uno .h el PIC no reconoce la diferencia. Lo respondo de esta forma porque tal vez puede suponerse que el uso de .h radica por su simple defínición en un comportamiento distinto del micro. Esto no es cierto.

¿Por que hay que utilizar los archivos de cabecera (header o .h)?? Para mantener el código organizado. Yo no lo hice en tu programa, solo cree el .h, pero lo correcto es colocar en uno o varios archivos .h todas las definiciones necesarias para tu programa que se van a utilizar en varios .c o en todos. Por ejemplo es lo mejor definir todas las variables globales, los fuses, los registros especificos y los pines del micro y hasta funciones generales (funciones de manejo de formato o de perifericos) que vamos a utilizar en archivos .h(si te fijas bien, los archivos que incluyen todas las constantes y definiciones para cada uno de los modelos del micro son archivos header, por ejemplo "16F628A.h").
Una vez creado el .h o los .h los colocas en los .c que los vas a utilizar mediante la directiva #include. Ahora bien, podría pensarse con mucha lógica que colocar los header en cada uno de los .c es una forma bastante creativa de desperdiciar memoria ROM, pero en realidad al compilar el programa CCS elimina las librerias que estan duplicadas y por lo tanto no ocupan ROM extra y su alcance sigue siendo para todas las unidades donde has colocado el #include.

En realidad el tema no es tan simple y no se si me he explicado bien, los .h se rigen más bien por convenciones de programación y puedes obtener los mismo resultados sin utilizarlos, aunque yo no lo recomiendo por un tema de prolijidad y orden a la hora de programar. Yo siempre los uso y cuando te acostumbras realmente simplifica mucho la organización del código.

Espero haber sido claro. Saludos.



"Siempre piensa si el jugo vale la exprimida..."

"La muerte esta tan segura de vencer que nos da toda una vida de ventaja."

Desconectado firepic

  • Colaborador
  • PIC24H
  • *****
  • Mensajes: 1130
    • JC Servicios
Re: memoria ROM insuficiente
« Respuesta #36 en: 05 de Julio de 2008, 11:27:16 »
Recontra claro! Gonzalo, gracias por la explicacion!
Saludos, nos leemos!  :mrgreen:
"Por la presunción solo se ocasiona una lucha, pero con los que consultan juntos hay sabiduría" (Proverbios 13:10).
Visita Mi Sitio Web

Desconectado vasconinicolas

  • PIC16
  • ***
  • Mensajes: 124
Re: memoria ROM insuficiente
« Respuesta #37 en: 06 de Julio de 2008, 14:07:22 »
Gonzalo, como siemple, un maestro. Admiro tu dedicación, vocación, experiencia y el hecho de volcarlo hacia la comunidad desinteresadamente. Soy de los que le gusta construir las cosas con sus propios recursos y no comprar hecho aunque esto ultimo sea mas facil. Estoy en algunos foros de aficionados (a la astronomia), y promulgamos esto, aunque la mayoría habla de las características de los instrumentos comprados, nosotros seguimos luchando por construir. Sobre todo para aprender.
Voy a revisar mi codigo para ver si encuentro el error y cuando lo haga, reporto aquí por si sirve a otros..
Hasta pronto, nos leemos  :-)
"No hacen ciencia los países ricos,
Son ricos los países por hacer ciencia"

Desconectado vasconinicolas

  • PIC16
  • ***
  • Mensajes: 124
Re: memoria ROM insuficiente
« Respuesta #38 en: 08 de Julio de 2008, 10:28:55 »
El problema me parece que viene por la cantidad de IF anidados. Alguien podria decirme si existe un limite a nivel de instrucciones IF o simplemente a nivel de la pila del micro, y en todo caso como puedo "visualizar" la pila para tener en cuenta estos detalles en la programacion??
Muchas gracias..
vasco
"No hacen ciencia los países ricos,
Son ricos los países por hacer ciencia"

Desconectado firepic

  • Colaborador
  • PIC24H
  • *****
  • Mensajes: 1130
    • JC Servicios
Re: memoria ROM insuficiente
« Respuesta #39 en: 08 de Julio de 2008, 10:52:07 »
Vasconi, en ese trozo de código no más tienes un If dentro de otro, no creo que sea ese el problema. Yo he tenido dos anidados dentro de otro y me ha funcionado al pelo. Aunque siempre trato de minimizar la cantidad de if usando dos condiciones dentro de un mismo if, con las sentencias AND u OR.... por ejemplo:
Código: C
  1. if(condicion1&&condicion2) //usando AND
  2. if(condicion1||condicion2)//usando OR
Pero es no más mi modo de trabajar, para tener más organizadito el código.
De verdad no creo que sea ese el problema, aunque si estoy en un error algún experto ya me corregirá. Por cierto, seguiste mi sugerencia de usar el MPLAB? Alli puedes simular paso por paso, es un tiro!
Ok saludos, nos leemos!  :mrgreen:
"Por la presunción solo se ocasiona una lucha, pero con los que consultan juntos hay sabiduría" (Proverbios 13:10).
Visita Mi Sitio Web

Desconectado vasconinicolas

  • PIC16
  • ***
  • Mensajes: 124
Re: memoria ROM insuficiente
« Respuesta #40 en: 08 de Julio de 2008, 12:14:29 »
Fire, gracias por tu pronta respuesta. He leido tus aportes y me parecen muy buenos. Voy a trabajar con los AND y OR para economizar IF jeje.. Por otro lado te comento que, si bien como vos decis, solo tengo un if dentro de otro, este último tiene metido adentro una funcion "reloj_progresivo()" que es a su vez:

void reloj_progresivo(void)
{
   if(seg>60)
   {
      seg=seg-60;
         if(min==59)
         {
            min=0;
            if(hor==23)
            {
               hor=0;
               min=0;
            }
            else
            {
            hor++;
            }
         }
         else
         {
         min++;
         }
   }
   else
      seg=seg+sspp;
}

De modo que hay unos cuantos if en todo el asunto.. quiza venga por aca la macana...
Con respecto al MPLAB, lo estoy por probar ahorita mismo como simulador.
Saludosssss
"No hacen ciencia los países ricos,
Son ricos los países por hacer ciencia"

Desconectado firepic

  • Colaborador
  • PIC24H
  • *****
  • Mensajes: 1130
    • JC Servicios
Re: memoria ROM insuficiente
« Respuesta #41 en: 08 de Julio de 2008, 12:29:26 »
Vasco, a veces no es necesario anidar tanto. No he podido analizar completamente tu código, pero si lo que quieres es hacer un reloj, se me ocurre algo así:
Código: C
  1. void reloj()
  2. {
  3.     seg++;
  4.     if(seg==60)
  5.     {
  6.           seg=0;
  7.           min++;
  8.     }
  9.     if(min==60)
  10.     {
  11.          min=0;
  12.          hora++;
  13.     }
  14.     if(hora==24) hora==0;
  15. }

Lo único que tendrías que hacer sería llamar a la función cada vez que pase un segundo, bueno o lo que quieras que haga. Nota que no estoy anidando ningun if, sino todos en secuencia. Claro que tendrías que inicializar las variables y demás. Entonce, si el segundo llega a 60, se hace cero y a la vez incrementa el minuto... si el minuto estaba en 59 se incrementa y llega a 60, entonces entra en el otro if, se hace cero e incrementa la hora... y así sucesivamente. Ojalá esto te ayude.

Un cordial saludo!  :mrgreen:
« Última modificación: 08 de Julio de 2008, 12:32:26 por firepic »
"Por la presunción solo se ocasiona una lucha, pero con los que consultan juntos hay sabiduría" (Proverbios 13:10).
Visita Mi Sitio Web

Desconectado vasconinicolas

  • PIC16
  • ***
  • Mensajes: 124
Re: memoria ROM insuficiente
« Respuesta #42 en: 08 de Julio de 2008, 13:03:49 »
Una masa fire, ya lo cambie y ahora lo pruebo para ver los resultados je.. En el simulador anda de lujo, vamos a ver el el protoboard.
vasco
"No hacen ciencia los países ricos,
Son ricos los países por hacer ciencia"

Desconectado vasconinicolas

  • PIC16
  • ***
  • Mensajes: 124
Re: memoria ROM insuficiente
« Respuesta #43 en: 08 de Julio de 2008, 14:09:59 »
Perdon Fire, una consulta, Estoy usando el CCS para compilar, como lo abro con el mplab para simular? Abris el .hex? y en ese caso, como me oriento? me refiero adentro del .hex para saber donde estoy parado..
Graciassss
vasco
"No hacen ciencia los países ricos,
Son ricos los países por hacer ciencia"

Desconectado firepic

  • Colaborador
  • PIC24H
  • *****
  • Mensajes: 1130
    • JC Servicios
Re: memoria ROM insuficiente
« Respuesta #44 en: 08 de Julio de 2008, 14:19:34 »
Vasco no hace falta, puedes usar directamente el mplab con editor de C. Así lo uso yo.
Creas un proyecto nuevo, y antes de adicionar el archivo fuente, le das en "Project>Select language toolsuite" y en "active toolsuite" seleccionas CCS Pic Compiler. Más abajo, en "location" colocas la dirección en tu pc donde tienes el CCS, específicamente el ejecutable CCSC.EXE
Para estar más seguro, le das en "Project>select language tool location" y nuevamente eliges CCS, y verificas si en el "ejecutable" está configurado el CCSC.EXE que colocaste anteriormente.
Y eso es todo. Adicionas al proyecto el archivo fuente .c y podrás editar el archivo. Luego con el MPLAB SIM puedes simular el código línea por línea, ver los registros, etc.
Ok saludos, nos leemos!  :mrgreen:

EDITO: Olvide mencionarte que haciéndolo así puedes compilar desde mplab el archivo en c, pues lo que haces es llamar al compilador CCS (el ccsc.exe) que tienes en la pc. Lo que no vas a usar es el editor que trae el CCS. Para compilar le das F10 y listo.
« Última modificación: 08 de Julio de 2008, 14:24:20 por firepic »
"Por la presunción solo se ocasiona una lucha, pero con los que consultan juntos hay sabiduría" (Proverbios 13:10).
Visita Mi Sitio Web