TODOPIC
Microcontroladores PIC => Lenguaje C para microcontroladores PIC => Mensaje iniciado por: angelmt en 05 de Octubre de 2008, 15:48:59
-
Hola
Por favor ayudadme porque de esta no se salir:
Resulta que quiero generar una tabla con 90 numeros de tipo int8 y los quiero almacenar en una matriz que este almacenada en la memoria de datos de un PIC16F72 que tiene 128 bytes, bueno pues mi sorpresa viene que declaro la matriz y una declaracion de interrupcion externa, pero ni siquiera he puesto codigo aun y al compilar me dice que no tengo suficiente RAM, como es posible si este microcontrolador tiene 128 bytes?
Ayudadme!!!!
Muchas gracias
os pongo el codigo que tengo:
#include "C:\Documents and Settings\Angel\Escritorio\Bingo\f72\main.h"
#int_EXT
void EXT_isr(void)
{
}
int8 numeros_salidos[90];
void main()
{
setup_adc_ports(NO_ANALOGS);
setup_adc(ADC_OFF);
setup_spi(SPI_SS_DISABLED);
setup_timer_0(RTCC_INTERNAL|RTCC_DIV_1);
setup_timer_1(T1_DISABLED);
setup_timer_2(T2_DISABLED,0,1);
enable_interrupts(INT_EXT);
enable_interrupts(GLOBAL);
}
-
Hola.
Algunas de las funciones buil-in que estas usando usan RAM tambien, por lo que puede ser por eso.
Saludos
-
Creo que al ponerlas como gobales el compilador hace algo mas de codigo que quiza contenga mas ram q cuando los pones como locales.
Salu2.
-
¿Qué tienes en ese main.h?
-
En main.h no creo que sea importante para el problema de la ram, tengo esto:
#include <16F72.h>
#FUSES NOWDT //No Watch Dog Timer
#FUSES RC //Resistor/Capacitor Osc with CLKOUT
#FUSES NOPUT //No Power Up Timer
#FUSES NOPROTECT //Code not protected from reading
#FUSES BROWNOUT //Reset when brownout detected
#use delay(clock=20000000)
-
CCS no deja crear variables que ocupen por sí solas un cierto porcentaje de la ram.
El motivo,pues no lo se. Pero es así.Posiblemente se salvaguarde espacio para cambios de contexto y tal.
Si bajas el tamaño del array por ejemplo a 50, posiblemente compile.
-
Hola
En la hoja de características el PIC16F72 tiene 128bytes de ram, pero hay que considerar que existen 96 bytes en el banco 0 y 32 bytes en el banco 1, la ram no es continua como en otros micros.
Si quisieras apuntar a 90bytes del banco 0, estando en el banco 0, tendrías solo 6 bytes de ram para trabajar con esos apuntadores, seguramente por eso CCS no puede compilar.
Es mejor que cambies de PIC y busques uno que tenga 90bytes en cualquier banco y unos 20 ó 30 bytes extras en ese mismo banco, es cuestión de hacer la prueba.
La otra opción es partir el arreglo en 2 partes en el mismo pic: 70 bytes en un arreglo y 20 bytes en el otro, talvez así CCS sí pueda manipularlos en bancos separados.
-
Tal y como está tu programa, no admite un array de más de 82 bytes. Con 83 ya salta el error.
Sin embargo, con 82 bytes el % de RAM ocupado según el compilador es únicamente el 76%.
Por tanto, he podido crear otro array con 31 elementos que ocupa el resto de RAM y se compila al 100%.
Así que se confirma la explicación de Modulay:
CCS no deja crear variables que ocupen por sí solas un cierto porcentaje de la ram.
-
CCS no deja crear variables que ocupen por sí solas un cierto porcentaje de la ram.
El motivo,pues no lo se. Pero es así.Posiblemente se salvaguarde espacio para cambios de contexto y tal.
Si bajas el tamaño del array por ejemplo a 50, posiblemente compile.
Ummmm ... no tenía ni idea ... y sin embargo en mi programa del hilo Detectando Flancos de subida (y de bajada) con un 18F4550 (http://www.todopic.com.ar/foros/index.php?topic=23020.0) acabo de subir el Array de structs (4 bytes por struct) hasta unos espeluznantes 480 registros lo que supone el 92% de la memoria RAM del 4550 y no se ha quejado para nada. :shock:
-
Muchas gracias a todos, lo que hare al final sera crear dos matrices para poder llegar a los 90 bytes.Ya se una nueva cosa con la administracion del ccs en la memoria de datos.
Nocturno, muchisimas gracias por tomarte el interes de ir probando la matriz y compilarlo,etc
-
Es que en los 16F con el CCS simplemente no se puede, recuerdo que leí un post por allí donde decian que cambiando una directiva, creo que era poner Device= *16 o algo asi , le decian al compilador que hiciera el "acomodo" del arrays en los bancos, pero no funciona.
la forma es partiendo el array y con #reserve seleccionas la dirección en el banco respectivo.
-
Es que en los 16F con el CCS simplemente no se puede ...
Ahhh, Pedro, entonces me explico que yo si pueda superarlo, estoy con un 18F. Muchas gracias por tu comentario.
-
La explicación del porqué no en los 16F y familias inferiores(como 12X) y el porqué sí en las familias superiores es sencilla:
Las familias más antiguas poseen la memoria de datos(y programa) paginada. Esto hace muy complejos(y, de lograrlo, lentos) los algoritmos necesarios para gestionar un array que tenga variables en más de uno de los bancos de memoria. Esta paginación no exíste en los 18F y familias superiores, por lo que el compilador no tiene en problema en utilizar arrays de casi la totalidad de la memoria disponible.
Saludos.
-
No termino de ver el por qué de la paginación en unos sí y en otros no.
Los 16F, al menos los que yo he usado, precisan de la gestión de los bits RPX (RP0 y RP1 en el caso del 16F84) para acceder en cada momento al banco en el que se encuentra el registro buscado.
Si cuando hablais de paginación os estais refiriendo a eso, es algo que también precisan micros de la gama 18F (18F452 por ejemplo), con la diferencia de que el 452 lleva un registro llamado BSR, que se debe escribir con el valor del banco al cual se va a acceder.
No tengo en estos momentos el compilador a mano,pero apostaría a que ccs hace la gestión necesaria para acceder al banco que sea, tanto en 16F como en 18F, y ya sea para acceder variables simples o de tipo compuesto y ubicadas,en este último caso, en más de un banco de forma simultánea.
-
No tengo en estos momentos el compilador a mano,pero apostaría a que ccs hace la gestión necesaria para acceder al banco que sea, tanto en 16F como en 18F, y ya sea para acceder variables simples o de tipo compuesto y ubicadas,en este último caso, en más de un banco de forma simultánea.
Lo que comentas es altamente probable usando el direccionamiento indirecto de los pic16, usando los registros INDF y FSR.
-
No tiene mucho sentido que esa sea la explicación, puesto que en el ejemplo anterior se puede crear un array de 82 bytes y compila sin problemas. Si el pic tiene 128 bytes de RAM, necesariamente estará poniendo algunos bytes en un banco y el resto en el otro.
-
No tiene mucho sentido que esa sea la explicación, puesto que en el ejemplo anterior se puede crear un array de 82 bytes y compila sin problemas. Si el pic tiene 128 bytes de RAM, necesariamente estará poniendo algunos bytes en un banco y el resto en el otro.
No necesariamente Manolo. Fijate que tu primer array posee 82 elementos, los cuales pueden ser ubicados en el banco0(de 96 bytes disponibles) y el otro 31 elementos, los cuales pueden ser ubicados en el banco1(de 32 bytes disponibles).
Si quieren taparme la boca, pos una forma sería haciendo dos arrays de, por ejemplo, 50 elementos cada uno. Si permite ambos arrays en este PIC, entonces sí.Mi teoría es errónea.
Modulay, tenés razón en lo que decís. Vamos a interiorizar y debatir que esto me interesa :)
Saludos.
-
Pues me retracto: efectivamente he probado lo que dices Bruno, y no admite dos arrays de 50 posiciones.
Yo daba por hecho que los dos bancos de memoria son del mismo tamaño; esto de no leer el datasheet :?
-
BrunoF no creo que esa sea la explicacion porque haz la prueba con un 16F747 que solamente el primer banco tiene 96 bytes y el resto son de 80 bytes y lo compila sin problemas, y necesariamente tiene que dejar la matriz dividida en dos bancos.
#include "C:\Documents and Settings\Angel\Escritorio\Bingo\f74\main.h"
int8 matriz[96];
int8 matriz1[96];
void main()
{
setup_adc_ports(NO_ANALOGS|VSS_VDD);
setup_adc(ADC_OFF|ADC_TAD_MUL_0);
setup_psp(PSP_DISABLED);
setup_spi(SPI_SS_DISABLED);
setup_timer_0(RTCC_INTERNAL|RTCC_DIV_1);
setup_timer_1(T1_DISABLED);
setup_timer_2(T2_DISABLED,0,1);
setup_comparator(NC_NC_NC_NC);
setup_vref(FALSE);
//Setup_Oscillator parameter not selected from Intr Oscillator Config tab
// TODO: USER CODE!
}
-
Hola angel!
Casi...:D pero NO. El 16F747 posee 368 bytes de memoria y recién acabo de ver su datasheet y posee: 3 bancos de 96 bytes(bancos 0,2 y 3) y uno de 80 bytes(banco1).
Y si te fijas, nuevamente sucede lo que digo. Intentá declarar un array de 97 bytes y el compilador ya te dice que no hay memoria para tantas variables.
Parecería que por un lado lo que digo puede guardar cierta verdad, pero por otro lado no. Como dijo modulay: no veo bien la diferencia entre la paginacion de las flias 10,12 y 16 y la seleccion mediante el BGR en los 18F por ejemplo. Tampoco entiendo por que el CCS no utiliza el direccionamiento indirecto para poder hacer esto como migsantiago ha dicho. Y tampoco me cierra otra cosa mas que ya me olvide mientras escribía esto.... :(
-
Bien. He estado meditandoló. Y la respuesta a las ambas preguntas que me he estado haciendo es la mísma:
La principal diferencia entre los 16F y los 18F que está relacionada con este problemita de los tamaños de los arrays, no tiene que ver tanto con la paginación sino con la distribución de los GPRs y FSRs. Si se fijan en cualquier 16F o anterior, los GPRs y los FSRs están mezclados. Es decir, si van recorriendo la memoria de datos, probablemente encuentren algo así(en un 16F8747 ya que estamos)
FSRs, GPRs,FSRs, GPRs,FSRs, GPRs,FSRs, GPRs.
Si lo queremos usar direccionamiento indirecto para poder armar un array que ocupe(o cruce) dos o mas bancos, en los 16F entonces habría que andar "saltando" a los FSRs. Tarea no tan sencilla como los 18F que poseen toda la memoria GPRs al inicio y recién al final los FSR...
Tal vez por esto Microchip los haya reorganizado de esta manera, eh? :)
Entonces, parecería que no tiene tanto que ver con el tamaño, sino que con que todos los elementos puedan ser ubicados consecutivamente. Es decir, de manera contínua para que el CCS pueda utilizar apuntadores sencillos.("la continuidad de los parques" :mrgreen:)
A ver qué les parece mi nueva hipótesis.
-
Sea como sea,si el motivo por el que el compilador no deja compilar es el cambio de banco, es una carencia como una casa de grande.
Propongo una sentada reivindicativa pro bug-fix en las puertas de los cuarteles generales de CCS :D
-
Sea como sea,si el motivo por el que el compilador no deja compilar es el cambio de banco, es una carencia como una casa de grande.
Propongo una sentada reivindicativa pro bug-fix en las puertas de los cuarteles generales de CCS :D
Ja, ja, ja :D :D :D hace viente años que no oía una propuesta de sentada ja, aj, ja :D :D :D me apunto ja, ja ja, :D :D :D
-
Yo me llevo las cervecitas...tu encárgate de los bocatas.Del resto, que cada uno se apañe lo suyo :)