TODOPIC
Microcontroladores PIC => Primeros pasos - Iniciación a los microcontroladores => Mensaje iniciado por: RedOni12 en 13 de Mayo de 2022, 02:26:13
-
Cordial saludo, he estado trabajando en el desarrollo de un frecuencímetro haciendo uso del PIC18F4550, estoy trabajando con el oscilador interno a 8Mhz, sin embargo tengo un error al momento de que la simulación concuerde con el resultado esperado en el montaje físico, puesto que mientras que en la simulación me entrega el valor esperado, en físico me entrega valores muy altos, por ejemplo en la imagen con una frecuencia de 1KHz en físico me entrega una frecuencia de 48076.92 en el LCD, adjunto el codigo
#define LCD_RS_PIN PIN_D0
#define LCD_RW_PIN PIN_D1
#define LCD_ENABLE_PIN PIN_D2
#DEFINE LCD_DATA4 PIN_D3
#DEFINE LCD_DATA5 PIN_D4
#DEFINE LCD_DATA6 PIN_D5
#DEFINE LCD_DATA7 PIN_D6
#define INDI PIN_A1
#include <lcd.c>
int8 cont;
int1 BITS[32]; //Tiene 16 bits
int16 Tia,Tib,Temp;
float peri,frec,T;
#INT_EXT
void RB0(void){
Tia=get_timer1();//Obtiene el valor del timer1, que otorga valores de hasta 63940
Temp=Tia-Tib;
Tib=Tia;
void main()
{
lcd_init();
SET_TRIS_A(0x00);
enable_interrupts(INT_EXT);
enable_interrupts(GLOBAL);
SETUP_TIMER_1(T1_INTERNAL|T1_DIV_BY_8);
EXT_INT_EDGE(L_TO_H);
while(TRUE){
T=4*8.0/20000000.0;
peri=T*Temp;
frec=(1/peri);
lcd_gotoxy(1,1);
printf(lcd_putc,"F=%f"frec);
while(TRUE){
T=4*8.0/20000000.0;
peri=T*Temp;
frec=(1/peri);
lcd_gotoxy(1,1);
printf(lcd_putc,"F=%f"frec);
lcd_gotoxy(1,2);
printf(lcd_putc,"Start=%u",BIT_INIC);
}
-
amigo un saludo, y por experiencia trabajando con frecuencias seria siempre con su cristal externo ya que en fisico si hay detalle a la hora de las mediciones y con el cristal se soluciona, y con respecto a la lectura de tu lcd puedes poner un pot a una entrada analógica para que sirva de ajuste ya que hay tiempos internos que hacen que cuente diferente y hay que tomarlos en cuenta.
-
amigo un saludo, y por experiencia trabajando con frecuencias seria siempre con su cristal externo ya que en fisico si hay detalle a la hora de las mediciones y con el cristal se soluciona, y con respecto a la lectura de tu lcd puedes poner un pot a una entrada analógica para que sirva de ajuste ya que hay tiempos internos que hacen que cuente diferente y hay que tomarlos en cuenta.
Buenas, muchas gracias por la respuesta! Y comprendo, esa fué una de las soluciones que implementé, pero aún así no se soluciona :/, conecté el cristal de cuarzo de 20MHz en los pines 13 y 14 que serían respectivamente OSC1 y OSC2, lo que si observo es que aumenta el valor apreciado en el LCD, por ejemplo si inyecto una frecuencia de 100 Hz por el pin RB0 obtengo una frecuencia de 2k en el LCD.
-
T=4*8.0/20000000.0
Ésta línea debería calcularse sólo una vez. Ya que desperdicias mucho tiempo en cálculo! Considerando que es un número float.
Por lo que veo, T no cambia de valor durante todo el proceso.
Lo puedes declarar como constante.
-
T=4*8.0/20000000.0
Ésta línea debería calcularse sólo una vez. Ya que desperdicias mucho tiempo en cálculo! Considerando que es un número float.
Por lo que veo, T no cambia de valor durante todo el proceso.
Lo puedes declarar como constante.
No creo que esté calculando ha cada instante esa línea de código el procesador, un buen compilador , y me imagino que si lo es el CCS, convierte esa línea en una constante.
Lo que si se puede ver que esa forma de programar el código está algo, digamos desordenada.
Respecto al problema que tiene, me inclino a pensar que está mal configurado la frecuencia de sistema (que es función del cristal o el oscilador interno) y en el simulador toma por defecto otro valor. Por eso ahí le funciona.
-
T=4*8.0/20000000.0
Ésta línea debería calcularse sólo una vez. Ya que desperdicias mucho tiempo en cálculo! Considerando que es un número float.
Por lo que veo, T no cambia de valor durante todo el proceso.
Lo puedes declarar como constante.
No creo que esté calculando ha cada instante esa línea de código el procesador, un buen compilador , y me imagino que si lo es el CCS, convierte esa línea en una constante.
Lo que si se puede ver que esa forma de programar el código está algo, digamos desordenada.
Respecto al problema que tiene, me inclino a pensar que está mal configurado la frecuencia de sistema (que es función del cristal o el oscilador interno) y en el simulador toma por defecto otro valor. Por eso ahí le funciona.
Me estás queriendo convencer de que T se calcula una sóla vez, cuándo ese cálculo está dentro de un while, y cada vez que comienza el bucle lo vuelve a calcular!
-
T=4*8.0/20000000.0
Ésta línea debería calcularse sólo una vez. Ya que desperdicias mucho tiempo en cálculo! Considerando que es un número float.
Por lo que veo, T no cambia de valor durante todo el proceso.
Lo puedes declarar como constante.
No creo que esté calculando ha cada instante esa línea de código el procesador, un buen compilador , y me imagino que si lo es el CCS, convierte esa línea en una constante.
Lo que si se puede ver que esa forma de programar el código está algo, digamos desordenada.
Respecto al problema que tiene, me inclino a pensar que está mal configurado la frecuencia de sistema (que es función del cristal o el oscilador interno) y en el simulador toma por defecto otro valor. Por eso ahí le funciona.
Me estás queriendo convencer de que T se calcula una sóla vez, cuándo ese cálculo está dentro de un while, y cada vez que comienza el bucle lo vuelve a calcular!
El compilador, cuando crea el ensamblador reduce el código lo máximo posible, y operaciones como esa las convierte en una constante.
Has una prueba y mira como queda el ensamblador.
-
....
Me estás queriendo convencer de que T se calcula una sóla vez, cuándo ese cálculo está dentro de un while, y cada vez que comienza el bucle lo vuelve a calcular!
Pero es así . Como 4*8.0/20000000.0 es una constante (1.6e-6) asigna a T directamente el resultado.
Lo si es desperdiciar recursos, dado que las operaciones en punto flotante se hacen por software, es hacer:
T=4*8.0/20000000.0; // Una asignación
peri=T*Temp; // Una multiplicacion en punto flotante
frec=(1/peri); // Una division en punto flotante
en lugar de hacer:
frec=20000000.0/(4*8.0)/Temp ; // Una division en punto flotante
pues genera
frec=.0000016/Temp ;
Esto último es lo que "debería" un compilador que optimice "de verdad" si las variables T y peri no se usaran en otra parte del programa.
-
....
Me estás queriendo convencer de que T se calcula una sóla vez, cuándo ese cálculo está dentro de un while, y cada vez que comienza el bucle lo vuelve a calcular!
Pero es así . Como 4*8.0/20000000.0 es una constante (1.6e-6) asigna a T directamente el resultado.
Lo si es desperdiciar recursos, dado que las operaciones en punto flotante se hacen por software, es hacer:
T=4*8.0/20000000.0; // Una asignación
peri=T*Temp; // Una multiplicacion en punto flotante
frec=(1/peri); // Una division en punto flotante
en lugar de hacer:
frec=20000000.0/(4*8.0)/Temp ; // Una division en punto flotante
pues genera
frec=.0000016/Temp ;
Eso no es el código en lenguaje ensamblador.
-
....
Me estás queriendo convencer de que T se calcula una sóla vez, cuándo ese cálculo está dentro de un while, y cada vez que comienza el bucle lo vuelve a calcular!
Pero es así . Como 4*8.0/20000000.0 es una constante (1.6e-6) asigna a T directamente el resultado.
Lo si es desperdiciar recursos, dado que las operaciones en punto flotante se hacen por software, es hacer:
T=4*8.0/20000000.0; // Una asignación
peri=T*Temp; // Una multiplicacion en punto flotante
frec=(1/peri); // Una division en punto flotante
en lugar de hacer:
frec=20000000.0/(4*8.0)/Temp ; // Una division en punto flotante
pues genera
frec=.0000016/Temp ;
En la respuesta #20 de este hilo te indica como obtener el ensamblado del código.
http://www.todopic.com.ar/foros/index.php?topic=51187.15 (http://www.todopic.com.ar/foros/index.php?topic=51187.15)
Mira como queda T=4*8.0/20000000.0;
-
....
Me estás queriendo convencer de que T se calcula una sóla vez, cuándo ese cálculo está dentro de un while, y cada vez que comienza el bucle lo vuelve a calcular!
Pero es así . Como 4*8.0/20000000.0 es una constante (1.6e-6) asigna a T directamente el resultado.
Lo si es desperdiciar recursos, dado que las operaciones en punto flotante se hacen por software, es hacer:
T=4*8.0/20000000.0; // Una asignación
peri=T*Temp; // Una multiplicacion en punto flotante
frec=(1/peri); // Una division en punto flotante
en lugar de hacer:
frec=20000000.0/(4*8.0)/Temp ; // Una division en punto flotante
pues genera
frec=.0000016/Temp ;
El código en ensamblador es algo similar a esto:
(https://pbs.twimg.com/media/FRyNLxvXIAIbuoG?format=png&name=medium)
-
....
Eso no es el código en lenguaje embalador.
Me refiero a que las dos generan lo mismo.
-
T=4*8.0/20000000.0
Ésta línea debería calcularse sólo una vez. Ya que desperdicias mucho tiempo en cálculo! Considerando que es un número float.
Por lo que veo, T no cambia de valor durante todo el proceso.
Lo puedes declarar como constante.
No creo que esté calculando ha cada instante esa línea de código el procesador, un buen compilador , y me imagino que si lo es el CCS, convierte esa línea en una constante.
Lo que si se puede ver que esa forma de programar el código está algo, digamos desordenada.
Respecto al problema que tiene, me inclino a pensar que está mal configurado la frecuencia de sistema (que es función del cristal o el oscilador interno) y en el simulador toma por defecto otro valor. Por eso ahí le funciona.
Cordial saludo
Efectivamente, sospecho que de alguna manera no está trabajando a la frecuencia indicada :/ pero no sé como comprobarlo
Saludos.
-
T=4*8.0/20000000.0
Ésta línea debería calcularse sólo una vez. Ya que desperdicias mucho tiempo en cálculo! Considerando que es un número float.
Por lo que veo, T no cambia de valor durante todo el proceso.
Lo puedes declarar como constante.
No creo que esté calculando ha cada instante esa línea de código el procesador, un buen compilador , y me imagino que si lo es el CCS, convierte esa línea en una constante.
Lo que si se puede ver que esa forma de programar el código está algo, digamos desordenada.
Respecto al problema que tiene, me inclino a pensar que está mal configurado la frecuencia de sistema (que es función del cristal o el oscilador interno) y en el simulador toma por defecto otro valor. Por eso ahí le funciona.
Cordial saludo
Efectivamente, sospecho que de alguna manera no está trabajando a la frecuencia indicada :/ pero no sé como comprobarlo
Saludos.
Pon un while con dos delay que cambien de estado un puerto y lo miras con el osciloscopio. Ya sabras con eso si el oscilador es o no correcto.
-
T=4*8.0/20000000.0
Ésta línea debería calcularse sólo una vez. Ya que desperdicias mucho tiempo en cálculo! Considerando que es un número float.
Por lo que veo, T no cambia de valor durante todo el proceso.
Lo puedes declarar como constante.
No creo que esté calculando ha cada instante esa línea de código el procesador, un buen compilador , y me imagino que si lo es el CCS, convierte esa línea en una constante.
Lo que si se puede ver que esa forma de programar el código está algo, digamos desordenada.
Respecto al problema que tiene, me inclino a pensar que está mal configurado la frecuencia de sistema (que es función del cristal o el oscilador interno) y en el simulador toma por defecto otro valor. Por eso ahí le funciona.
Me estás queriendo convencer de que T se calcula una sóla vez, cuándo ese cálculo está dentro de un while, y cada vez que comienza el bucle lo vuelve a calcular!
El compilador, cuando crea el ensamblador reduce el código lo máximo posible, y operaciones como esa las convierte en una constante.
Has una prueba y mira como queda el ensamblador.
Si ésto es como dices. Entonces depende del tipo de compilador.
-
....
Si ésto es como dices. Entonces depende del tipo de compilador.
Por supuesto, además del tipo de compilador, del nivel de optimización seleccionado.
Por ejemplo, en un código como éste:
char testeo(void) {
char t ;
char x=5 ;
char y ;
y=2*5+1 ;
t=x ;
x=y*y+4 ;
y=t ;
return x;
}
void main(void){
testeo() ;
while(1);
}
Ahí CCS solo te toca la línea con y=2*5+1 ; , donde optimiza asignando directamente 11 a y.
Pero como se puede ver, hay mucho código inútil, asignaciones que se pierden por ser variables locales y un valor de retorno no se usa.
Eso compilado con gcc para AVR (https://godbolt.org/z/GKqf9znaf) te elimina casi todo (activando las optimizaciones por supuesto). En la función elimina todo y devuelve 125 y en main ni siquiera llama la función.
Este es nada mas un ejemplo, porque la utilidad real de reemplazarte una operación es que se vea de donde sale el número y el cálculo te lo haga el compilador.
-
Gracias por eso dato Eduardo, realmente NO lo sabía.
-
T=4*8.0/20000000.0
Ésta línea debería calcularse sólo una vez. Ya que desperdicias mucho tiempo en cálculo! Considerando que es un número float.
Por lo que veo, T no cambia de valor durante todo el proceso.
Lo puedes declarar como constante.
No creo que esté calculando ha cada instante esa línea de código el procesador, un buen compilador , y me imagino que si lo es el CCS, convierte esa línea en una constante.
Lo que si se puede ver que esa forma de programar el código está algo, digamos desordenada.
Respecto al problema que tiene, me inclino a pensar que está mal configurado la frecuencia de sistema (que es función del cristal o el oscilador interno) y en el simulador toma por defecto otro valor. Por eso ahí le funciona.
Cordial saludo
Efectivamente, sospecho que de alguna manera no está trabajando a la frecuencia indicada :/ pero no sé como comprobarlo
Saludos.
Pon un while con dos delay que cambien de estado un puerto y lo miras con el osciloscopio. Ya sabras con eso si el oscilador es o no correcto.
Cordial saludo, efectivamente realicé el montaje con el pic16f877A y funciona correctamente el código, realizaré las verificaciones como mencionas a ver como está trabajando el PIC18F4550