...
¿Os podéis creer que si le quito ese delay_ms(10) me hace los cálculos mal y me devuelve resultados aleatorios.
Pregunta tonta: alguno de los valores de las variables dentro de ese bucle ¿cambia por alguna interrupción o un DMA o algo parecido?En teoría no, don Diego, porque si miras el fuente, el cálculo sólo se hace cuando capturado=1, mientras que el array se modifica en la interrupción del Timer cuando capturado=0.
:shock: ¿Podés subir un bloque "compilable" donde haga el error?Aquí va:
Llevo dándole vueltas un buen rato a un bucle donde calculo la corriente consumidaCódigo: C
¿Os podéis creer que si le quito ese delay_ms(10) me hace los cálculos mal y me devuelve resultados aleatorios.
....:shock: ¿Podés subir un bloque "compilable" donde haga el error?Aquí va:Código: C
Deberías dejar a un lado los "delays" y programar en estados de máquina (o máquina de estados). Te permite aislar los procesos en tareas independientes y la búsquedas de errores se simplifica.
Aunque también, ese tipo de errores en el CCS no me sorprende en ese compilador.
Mirá, cuando simulo ese código veo que el índice IndMuestra alcanza el valor 58 antes de resetearlo --> Como muestra[] es de 50 elementos se está escriibiendo sobre las variables que hay después --> resultado impredecible.
.... Si le inyectas una señal cuadrada de 50Hz por la interrupción externa, IndMuestra no pasa de 50.Le inyecte un pulso de 50hz duty 5%, y llegaba a 58.
...
.... Si le inyectas una señal cuadrada de 50Hz por la interrupción externa, IndMuestra no pasa de 50.Le inyecte un pulso de 50hz duty 5%, y llegaba a 58.
...
Deberías dejar a un lado los "delays" y programar en estados de máquina (o máquina de estados). Te permite aislar los procesos en tareas independientes y la búsquedas de errores se simplifica.
Aunque también, ese tipo de errores en el CCS no me sorprende en ese compilador.
Pero si precisamente lo que quiero es eliminar el delay_ms. Está puesto ahí artificialmente porque de lo contrario los cálculos no funcionan bien. No es una tarea síncrona; todo lo contrario.
No sé por qué pero me da que tiene algo que ver con las operaciones matemáticas con los float; ¿pudiera ser que se ejecutan en segundo plano y sólo tiene tiempo de realizarlas cuando meto delays en el bucle principal?
Hola, ya va por la version 5.109.... :D
capturado=0;al final del cálculo, aunque no es del todo prolijo porque en #INT_TIMER2 se sigue haciendo conversiones.
IndMuestra=0;
El problema está en el reset de las variables Indmuestra y capturado.
Cuando terminás el cálculo activás calculado, pero capturado se resetea recién con #la INT_EXT --> Iniciará otro cálculo, pero como la interrupción e #INT_TIMER2 le alterarán Indmuestra hará cualquier cosa.
Lo solucionás agregandoCitarcapturado=0;al final del cálculo, aunque no es del todo prolijo porque en #INT_TIMER2 se sigue haciendo conversiones.
IndMuestra=0;
Con el delay de 10ms andaba porque la #INT_EXT reseteaba capturado antes del primer cálculo.
....No, la desacticación es/era un bug de CCS con algunos micros, en este caso no se desactivan.
En pocas palabras. Usar un delay, desactiva todas las interrupciones (bandera GIE = 0) hasta finalizar el retardo. Sin el delay, la interrupción sucede mucho más antes que 10 ms y aparece el problema.
¿Estoy en lo correcto?
Acá pasa que cuando termina de hacer el cálculo, como capturado sigue activado se ejecuta de nuevo. Pero como las interrupciones te cambian Indmuestra el for se termina donde lo agarre.
Con el delay de 10ms , llegaba antes la interrupción externa y resetea capturado.
Perdón, señores del CCS. Esta vez la culpa no fue vuestra :D