PIC 18f4550 y CCS compiler

[navegante 420]

Pordonad, es que estoy tan agoviado con esto que ya pierdo el oremus, teoricamente deveria de funcianar el miercoles y veo que no me va a ser posible.....

Lo de los dos niveles lo tenia claro, pero al usar dos interrupciones lo que no tenia nada es donde manda cada una, y claro si no os pongo el texto poco podeis ver, XD.

Os dejo el texto y haber si puedes oscar ponerme eso que dices de dedactivar las interrupciones manualmente, o si por el contrario esta to mal, que no me extrañaria lo mas minimo.


#include "F:\puente definitivo\gestorcarreras.h"
#use fast_io(D)


#int_RB
void RB_isr(void)
{
if(input(pin_B4)==0) //Botón de programación
{
output_high (pin_D2);
delay_ms(500);
output_low (pin_A4);
}
if(input(pin_B5)==0) //botón inicio de carrera
{
output_high (pin_D3);
delay_ms(500);
output_low (pin_D3);
}
if(input(pin_B6)==0) //cuenta vueltas coche 1
{
output_high (pin_D4);
delay_ms(500);
output_low (pin_D4);
}
if(input(pin_B7)==0) //cuentavueltas coche 2
{
output_high (pin_D5);
delay_ms(500);
output_low(pin_D5);
}
}

#int_COMP
void COMP_isr(void)
{
if (C1OUT==0) output_high (pin_D0); Seguidor de tension coche1
if (C1OUT==1) output_low(pin_D0);

if (C2OUT==0) output_high (pin_D1); seguidor de tension coche 2
if (C2OUT==1) output_low(pin_D1);
}



void main()
{
set_tris_D(0x1F);
setup_adc_ports(NO_ANALOGS|VSS_VDD);
setup_adc(ADC_CLOCK_DIV_2);
setup_psp(PSP_DISABLED);
setup_wdt(WDT_OFF);
setup_timer_0(RTCC_INTERNAL);
setup_timer_1(T1_INTERNAL|T1_DIV_BY_1);
setup_timer_2(T2_DISABLED,0,1);
setup_timer_3(T3_DISABLED|T3_DIV_BY_1);
setup_vref(VREF_LOW|15);
setup_comparator(A0_VR_A1_VR);
enable_interrupts(GLOBAL);
enable_interrupts(INT_RB);
enable_interrupts(INT_COMP);
setup_oscillator(OSC_8MHZ|OSC_TIMER1|OSC_31250|OSC_PLL_OFF);

// TODO: USER CODE!!

 

[Aunolose]

Bueno, con algo más de tiempo.

Resulta que estas haciéndolo con el CCS, no me acordaba... y mira el titulo del hilo , con este hace tiempo que no trabajo, pero creo que el orden de prioridad será el que orden en que pongas las rutinas de interrupción, también me suena algo de poner números para hacerlo pero mejor que lo mires antes.

Las interrupciones del puerto B se activan por cambio de nivel, es decir, que se activan tanto cuando suben como cuando bajan, lo del flanco, si no recuerdo mal, es para las interrupciones-interrupciones, es decir, INT0 e INT1. Como tu solo haces caso cuando el nivel es 0, es como si solo hicieras caso del flanco de bajada. Poner retardos de 500ms (medio segundo) dentro de una interrupción es eliminar la filosofía de las interrupciones, pues durante ese tiempo nadie podrá interrumpir, si da la casualidad que son las cuatro, estás dos segundos sin que se pueda hacer nada en el programa principal, aunque es muy sencillo decirlo y no tanto cambiarlo...

No veo el bucle principal, supongo que lo tendrás en el "todo"... (que para los ajenos al tema es "to do", "por hacer")


Dices que antes funcionaba, pero ahora no, ¿te pasa con las interrupciones del puerto B? lo digo porque son las prioritarias y las que, aunque lento por los 500ms, deberían encender y apagar los bits que tocan. ¿lo hacen? prueba bit por bit, dándole tiempo a los 500ms.

 

[Aunolose]

Para desactivar todas las interrupciones seguramente tendrás un disable_interrupts(GLOBAL) y para desactivar una en concreto será igual, pero en vez de GLOBAL, la que toque. pienso que esto debería hacerlo el compilador, pero lo puedes poner al principio de cada rutina de interrupción, recuerda activarla después al final del cada una también. Como tienes mucho tiempo, no influirá ese poquito que pierdes en hacerlo.

 

[Aunolose]

Las interrupciones del comparador ¿cuando se producen? ¿al cambiar también?

aquí en vez de

if (C2OUT==0) output_high (pin_D1); seguidor de tension coche 2
if (C2OUT==1) output_low(pin_D1);

podrías poner

if (C2OUT==0) output_high (pin_D1)
else output_low(pin_D1 ; seguidor de tension coche 2

lo digo por evitar una comparación, también sirve para C1OUT

en otros compiladores esto también serviría.

pin_D1= !C2OUT;

pero es mejor no jugársela hasta comprobar que todo funcione... además que pierde claridad.

 

[navegante 420]

Jejeje, pues si, vaya, poner delays en interrupciones, jejejeje,

Se trata solo de estructura básica, osea, de ver si las interrupciones las detecta o no, y en este caso es que no.

Obviamente la estrucctura del programa, en caso de que consiga que funcione, no incluye delays en la interupccion, si no una serie de comprobaciones para saber de donde viene y que es lo que ha pasado, para modicar el valos del swicth.


El programa principal sera swich (select) con todos los case que tengamos.

LAs interrupciones de rb efectivamente soloo me interesan en el franco de bajada, ya que no dejan de ser interruptores que estan a 1 y que cuando se activan pasa a 0.

El comparador efectivamente me interesa saber tanto el franco de subida como el de bajada, ya que es el seguidor de tension de los coches y me indican si estan moviendose o no.

 

[Gerard-2]

FLANCOS: Si, solo para RB0(Int0) y RB1(Int1).
-------------------------------

Cualquier modificacion sobre los pines RB7:4 -> pone RBIF a 1 en el reg INTCON.0

Su posterior lectura lo resetea. Se entiende que se va a leer para procesar que bit a sido afectado y proceder con la isr.

- - - - - - - - - - - --

Permiso de int sobre RB7:4 en RBIE de INTCON.3

 

[Gerard-2]

Continuo a nivel de asm, por si hay que revisar el codigo generado o monitorizar paso a paso.
La prioridad se determina por el bit RBIP sobre el reg INTCON".0
---------
Respecto al C, aunque solo sea a nivel 'formal' no me gusta ver que se configura algo de un osc despues !!! de configurar el timer ¿?
mucho menos que se habilite la int GLOBAL !!! antes de que se habiliten las ints individuales, nos puede dar problemas a la primera vuelta de prog. por ejemplo, no lo haria en asm, mucho menos compilando C.

 

[Gerard-2]

Interrupcion del comparador segun el man:

The comparator interrupt flag is set whenever there is
a change in the output value of either comparator.
Software will need to maintain information about the
status of the output bits, as read from CMCON<7:6>, to
determine the actual change that occurred

Dejo este apunte respecto a forzar la isr del comparador escribiendo un 1 en el flag CMIF en PIR2.6, para forzar una actualizacion desde la primera vuelta de programa, por ejemplo.

The CMIF bit (PIR2<6>) is the Comparator Interrupt Flag. The CMIF bit must be reset by clearing it. Since it is also possible to write a ‘1’ to this register, a simulated interrupt may be initiated.
_________________

Recordar, para afinar posteriormente ,que se dispone de:

• INT_COMP
• INT_COMP FAST

• INT_COMP HIGH

igual que para las otras int's.
______________________

Como siempre si las int's de RB vienen de interruptores, los rebotes pueden durar mas que la misma isr.
Y puestos a reflexionar hacemos la accion ... al pulsar?, ...al soltar ? o solo activo un flag y una sbr controlada por un timer 50 veces por segundo se encarga de hacer cada una de las acciones finales y borrar los flags dejados por la isr de los pulsadores...
Nos acercamos al rtos

 

[Aunolose]

En el PIC la gestión de las interrupciones en ensamblador no son tan fáciles como con el 8051, no hay una pila para guardar cosas, y es complicado guardar hasta la palabra de estado. En C el compilador lo hace todo, incluso puedes usar el ensamblador ya en la rutina de interrupción, pero esa parte te la ahorras (la de guardar el estado). Otro problema es que solo hay dos niveles de interrupción (en estos PIC, en otros ni eso) entonces todas van a parar al mismo sitio y tienes que averiguar cual es la que se ha producido, con C solo tienes que colocar donde toca la rutina y él lo gestiona, el compilador debe incluso borrar el bit asociado, aunque si el tiempo no es crítico, prefiero borrarlo yo para no dejar cabos sueltos.

Ya me costó que navegante se pasará al C, no me lo líes ahora otra vez

Otro detalle importante es que un buen compilador de C genera el mismo o mejor código que un programador mediocre de ensamblador, aunque eso aquí no lo podemos aplicar porque no somos mediocres, si no "la leche de güenos"


Lo que comentas de activar las interrupciones, antes o después no creo que sea mucho problema, pues cuando se active la global, saltará primero la de más prioridad y después la otra, para estos casos ni usaría los niveles, pues el tratamiento no es crítico, da igual cual se trate primero, lo que es importante es que todo esté en su sitio antes de que se pueda producir una.

En lo de los rebotes si tienes mucha razón, quizá por eso puso los 200 ms, para eliminarlos , también pienso que los pulsadores normales se pueden mirar perfectamente en el bucle principal, siempre es más lento el dedo que el programa... y a poco que sea lento, él solo se carga los rebotes. Si hay algún pulsador crítico, tipo "reset software", se le puede dedicar una patilla de interrupción, y si no, una resistencia y condensador adecuado en cada uno.

Lo que has puesto en ingles quiere decir que sí es necesario por software el bit de interrupción del comparador

 

[navegante 420]

En el PIC la gestión de las interrupciones en ensamblador no son tan fáciles como con el 8051, no hay una pila para guardar cosas, y es complicado guardar hasta la palabra de estado. En C el compilador lo hace todo, incluso puedes usar el ensamblador ya en la rutina de interrupción, pero esa parte te la ahorras (la de guardar el estado). Otro problema es que solo hay dos niveles de interrupción (en estos PIC, en otros ni eso) entonces todas van a parar al mismo sitio y tienes que averiguar cual es la que se ha producido, con C solo tienes que colocar donde toca la rutina y él lo gestiona, el compilador debe incluso borrar el bit asociado, aunque si el tiempo no es crítico, prefiero borrarlo yo para no dejar cabos sueltos.

pues no se porque me da a mi que por ahi van los tiros con mi programa.

me costó que navegante se pasará al C, no me lo líes ahora otra vez

Oscar no te hagas ilusiones, que en cuanto acabe con esto, me vuelvo a mi ensambler.

detalle importante es que un buen compilador de C genera el mismo o mejor código que un programador mediocre de ensamblador, aunque eso aquí no lo podemos aplicar porque no somos mediocres, si no "la leche de güenos"

Yo si soy la leche en ensambler, en C no tengo ni P idea

que comentas de activar las interrupciones, antes o después no creo que sea mucho problema, pues cuando se active la global, saltará primero la de más prioridad y después la otra, para estos casos ni usaría los niveles, pues el tratamiento no es crítico, da igual cual se trate primero, lo que es importante es que todo esté en su sitio antes de que se pueda producir una.

En lo de los rebotes si tienes mucha razón, quizá por eso puso los 200 ms, para eliminarlos , también pienso que los pulsadores normales se pueden mirar perfectamente en el bucle principal, siempre es más lento el dedo que el programa... y a poco que sea lento, él solo se carga los rebotes. Si hay algún pulsador crítico, tipo "reset software", se le puede dedicar una patilla de interrupción, y si no, una resistencia y condensador adecuado en cada uno.

Lo que has puesto en ingles quiere decir que sí es necesario por software el bit de interrupción del comparador

 

[Gerard-2]

Entiendo perfectamente lo del asm, nos ha pasado a todos los que hemos empezado desde abajo, a los informaticos de gestion, que estan en la nube, y nunca mejor dicho, no los pasa, les pasa otras cosas por que no bajan al hardware.

A lo que iba, que cuesta mucho empezar con el C, pero luego te das cuenta que para mover mucha info, o prog complejos en asm no terminas nunca, es imposible, reaprovechar, repasar y depurar codigo no es tan complicado, y lo digo yo que en esto voy justito. Pasar del asm al C NO TIENE VUELTA ATRAS !!! lo siento navegante no te resistas, siempre queda paris, alguna rutinita superrapida en asm para quitar el quoquilleo, es muy raro que haga falta en un micro rapido.

____________________

Lo de la gestion de las INT, ya lo tengo claro, hay dos vectores en la 8 y 18h, tambien he visto que por defecto, un bit a cero de reset, quedan todas al mismo nivel para compatibilidad descendente, si se quieren dos niveles hay que forzar un bit de config para ello.
_______________________

Respecto al manual de microchip, The comparator interrupt flag is set whenever there is a change
entiendo que decimos lo mismo: Se activa el flag de la INT del COMP cuando hay un cambio, este flag desencadena la llamada de la int a nivel de hard si esta permitida a todos los niveles, si queremos supervisar por soft, podemos consultar como esta el flag en cuestion, si queremos forzar la INT, es mas elegante poner el flag a 1 y dejar que se genere la INT solita.

 

[Aunolose]

Me comí una palabra, puse "es necesario por software el bit..." y debería poner "es necesario borrar por software el bit..." vamos que si se activa la interrupción (de una manera u otra) y no borras el bit correspondiente antes de salir de la rutina, en cuanto salgas, se vuelve a producir y ya tienes el lío.

 

[Gerard-2]

Vale, es que no estaba seguro de entenderte el sentido. Si, segun el man indica que 'debe borrarse el bit' , que lo deja a cargo del programa. Queda la duda de si el compilador tendra la gentileza de ahorrarnos este paso o mejor, lo que dices de forzarlo a reset y olvidarse del problema.

 

[Aunolose]

Exacto, eso es lo que quería decir.

Mirad lo que he encontrado en el MCC18

When an interrupt occurs, a low priority interrupt saves only the PC (Program Counter
register). For high priority interrupts, the PIC18XXXX core automatically saves the PC,
WREG, BSR and STATUS registers.
6.8 MATH

Cuando ocurre una interrupción, una interrupción de baja prioridad solo salva el PC (Contador de Programa)
Con interrupciones de alta prioridad el núcleo de los PIC18 salva automáticamente el PC y los registros WREG, BSR y STATUS.

Esto es nuevo para mi, se ve que espabilaron de anteriores modelos, el caso es que el compilador tiene menos que hacer, voy a seguir leyendo.

 

[navegante 420]

Eso, Oscar, haber si una vez que he salido de mi error, crei que el miercoles que viene era 25, consigo que funciones este programa, si hace falta te pago una comida el sabado donde me dias.

 

[navegante 420]

Bueno vamos por faena seria, que me queda 1 semana para solucioner el tema.

Este es el último codigo que he montado.

#include <18F4550.h>
#FUSES NOWDT //No Watch Dog Timer
#FUSES WDT128 //Watch Dog Timer uses 1:128 Postscale
#FUSES INTRC_IO //Internal RC Osc, no CLKOUT
#FUSES NOPROTECT //Code not protected from reading
#FUSES NOBROWNOUT //No brownout reset
#FUSES BORV20 //Brownout reset at 2.0V
#FUSES NOPUT //No Power Up Timer
#FUSES NOCPD //No EE protection
#FUSES STVREN //Stack full/underflow will cause reset
#FUSES NODEBUG //No Debug mode for ICD
#FUSES NOLVP //No low voltage prgming, B3(PIC16) or B5(PIC1 used for I/O
#FUSES NOWRT //Program memory not write protected
#FUSES NOWRTD //Data EEPROM not write protected
#FUSES IESO //Internal External Switch Over mode enabled
#FUSES FCMEN //Fail-safe clock monitor enabled
#FUSES PBADEN //PORTB pins are configured as analog input channels on RESET
#FUSES NOWRTC //configuration not registers write protected
#FUSES NOWRTB //Boot block not write protected
#FUSES NOEBTR //Memory not protected from table reads
#FUSES NOEBTRB //Boot block not protected from table reads
#FUSES NOCPB //No Boot Block code protection
#FUSES MCLR //Master Clear pin enabled
#FUSES LPT1OSC //Timer1 configured for low-power operation
#FUSES NOXINST //Extended set extension and Indexed Addressing mode disabled (Legacy mode)
#FUSES PLL12 //Divide By 12(48MHz oscillator input)
#FUSES CPUDIV4 //System Clock by 4
#FUSES USBDIV //USB clock source comes from PLL divide by 2
#FUSES VREGEN //USB voltage regulator enabled
#FUSES ICPRT //ICPRT enabled

#use delay(clock=8000000)
#use i2c(Master,Fast,sda=PIN_B0,scl=PIN_B2)
#use fast_io (A)
#use fast_io (B)
#use fast_io (C)
#use fast_io (D)

int configsaa[7];

void write_saa1064 ()
{
i2c_start();
i2c_write(configsaa[0]); //direccion
i2c_write(configsaa[1]); //registro de control
i2c_write(configsaa[2]); //luminosidad,funcionamiento
i2c_write(configsaa[3]); //display 4
i2c_write(configsaa[4]); //display 3
i2c_write(configsaa[5]); //display 2
i2c_write(configsaa[6]); //display 1
i2c_stop();
}

#int_RB
void RB_isr(void)
{
if(input(pin_B4)==0)
{
output_high (pin_D0);
delay_ms(500);
output_low (pin_D0);
}
if(input(pin_B5)==0)
{
output_high (pin_D1);
delay_ms(500);
output_low (pin_D1);
}
if(input(pin_B6)==0)
{
output_high (pin_D2);
delay_ms(500);
output_low (pin_D2);
}
if(input(pin_B7)==0)
{
output_high (pin_D3);
delay_ms(500);
output_low(pin_D3);
}
}

/*#int_COMP
void COMP_isr(void)
{
if(C1OUT==1)output_high (pin_D4);
else output_low (pin_D4);
if(C2OUT==1)output_high (pin_D5);
else output_low (pin_D5);
}*/



void main()
{
set_tris_D (0b11000000);
set_tris_A (0b11111111);
set_tris_B (0b11111100);

setup_timer_0(RTCC_INTERNAL);
setup_timer_1(T1_INTERNAL|T1_DIV_BY_1);



//setup_vref(VREF_LOW|15);
//setup_comparator(A0_VR_A1_VR);

enable_interrupts(GLOBAL);
enable_interrupts(INT_RB);
//enable_interrupts(INT_COMP);

setup_oscillator(OSC_8MHZ|OSC_TIMER1|OSC_31250|OSC_PLL_OFF);

// TODO: USER CODE!!

}

en el que el comparador pasa de mi, no hace na de na. Buen si me pasa la tension de un lado al otro.

las interrupciones de rb, van, bueno van pero con pequeños saltos, y algun que otro error de detección,

Para solucioner esto ultimo, habia pensado que en vez de que compruebe puerto por puerto en busca de com estan, hacer una captura de los 4 bits y ver lo que ha paso desde esa captura, que os parece?????

lo del comparador, no tengo ni idea, y eso que he probado un monton de convinaciones.

 

[Aunolose]

A ver lo que te puedo decir,
-es normal que "vayan a saltos", has puesto 500 ms de retardo, es decir, cuando pulsas uno, hasta medio segundo después no mira el siguiente, y si en ese tiempo pulsas, no hará caso, pues cuando salga, borra la interrupción, pulsa los botones cada ¿2 segundos? y comprueba si se enciende y apaga el led correspondiente

-supongo que sabes que tienes comentado el tema del comparador, pero cuando lo "descomentes" recuerda borrar el bit de interrupción del comparador, que ahora no sé cual es, pero que debes hacerlo por software, como hemos dicho por arriba, justo antes de salir de la rutina de interrupción, antes del corchete "}"

 

[Gerard-2]

solo es una pregunta, te han impuesto la condicion de poner las int sobre la botonera?

No me gusta que los programas se detengan en algun proceso, incluso para ver si el pulsador realmente se ha pulsado, por descontado que los delays hay que hacerlos con una base de tiempos generada desde un timer y quiza una isr asociada de conteo sobre un byte o word si es demasiado rapido. Si el t no es critico el prog principal puede gestionar estos tiempos supervisando un reg descontador precargado. Con un timer de 10mS +1 Byte tengo para 2,5 seg, i con el mismo timer y otro byte tengo otro retardo de 2,5 seg. Si es distinto de 0 esta haciendo un retardo, si ha alcanzado le 0 ya ha finalizado, de cero no tiene que bajar, la gestion la lleva la int del timer, main secuencialmente solo verifica como esta y actua si hace falta.

Cuando pueda me miro las configs, que voy colgado en ese tema.
Donde estan declarados los 7 valores de configsaa? o viene en otro fichero?

 

[navegante 420]

A ver lo que te puedo decir,
-es normal que "vayan a saltos", has puesto 500 ms de retardo, es decir, cuando pulsas uno, hasta medio segundo después no mira el siguiente, y si en ese tiempo pulsas, no hará caso, pues cuando salga, borra la interrupción, pulsa los botones cada ¿2 segundos? y comprueba si se enciende y apaga el led correspondiente

-supongo que sabes que tienes comentado el tema del comparador, pero cuando lo "descomentes" recuerda borrar el bit de interrupción del comparador, que ahora no sé cual es, pero que debes hacerlo por software, como hemos dicho por arriba, justo antes de salir de la rutina de interrupción, antes del corchete "}"

Ok ahora miro lo del comparador.

en cuanto a lo de los saltos de las interrupciones de RB solo me pasa con los detectores de paso de los coches.
Si solo funciona el coche 2 va de PM,
Si funciona solo el coche 1 alguna vez se despista y me cuenta como si pasara el coche 2.
Si corren los dos, lio, aveces detecta bien a los dos coches, aveces detecta a los cos como si fueran el coche 2 y habeces sin pasar ninguno, cuenta como si pasara el coche 2.

 

[navegante 420]

solo es una pregunta, te han impuesto la condicion de poner las int sobre la botonera?

No me gusta que los programas se detengan en algun proceso, incluso para ver si el pulsador realmente se ha pulsado, por descontado que los delays hay que hacerlos con una base de tiempos generada desde un timer y quiza una isr asociada de conteo sobre un byte o word si es demasiado rapido. Si el t no es critico el prog principal puede gestionar estos tiempos supervisando un reg descontador precargado. Con un timer de 10mS +1 Byte tengo para 2,5 seg, i con el mismo timer y otro byte tengo otro retardo de 2,5 seg. Si es distinto de 0 esta haciendo un retardo, si ha alcanzado le 0 ya ha finalizado, de cero no tiene que bajar, la gestion la lleva la int del timer, main secuencialmente solo verifica como esta y actua si hace falta.

Cuando pueda me miro las configs, que voy colgado en ese tema.
Donde estan declarados los 7 valores de configsaa? o viene en otro fichero?

Supongo que lo de la botonera como interrupciones es cuestion de mania mia, seguramente por falta de practica, que se supone que tendria que haber cogido en clase. Lo cierto es que no me fio de hacer un bucle en el programa principal, porque tengo la sensacion de que algun cambio de estado se le puede escapar, sobre todo el contador de paso de vueltas. Y si lo pongo en interrupciones, pues eso, ya no se escapan.

 

[navegante 420]

Os subo un esquemita del tema para que lo veais.

 

[navegante 420]

Oscar tienes un e-mail,

 

[Aunolose]

Ok ahora miro lo del comparador.

en cuanto a lo de los saltos de las interrupciones de RB solo me pasa con los detectores de paso de los coches.
Si solo funciona el coche 2 va de PM,
Si funciona solo el coche 1 alguna vez se despista y me cuenta como si pasara el coche 2.
Si corren los dos, lio, aveces detecta bien a los dos coches, aveces detecta a los cos como si fueran el coche 2 y habeces sin pasar ninguno, cuenta como si pasara el coche 2.

Antes de nada, bucle tienes que hacer, si no ¿que va a hacer cuando acabe las instrucciones del main? si vas mal de tiempo (para hacer el proyecto), mira allí los botones de programación y de inicio por lo menos.

Lo que cuentas tiene toda la pinta de ser lo que te digo, los 500ms, imagina que pasa el coche 1, se activa la interrupción enciende el led y se espera medio segundo, en ese tiempo pasa el coche 2, pero no hace ni caso, por que está en la interrupción... hasta el bit estará aún activo, cuando acaban los 500ms, sale del retardo, el coche dos ya ha pasado y la pata está a 1, no se activa, cuando acaba la rutina, si el compilador la borra (y parece que si, o tendrías un bucle infinito) el coche dos ha pasado y no se ha enterado...

Lo mismo pasa si el primer coche que pasa es el 2, solo funcionará bien si los coches pasan con más de 500ms de diferencia o si da la casualidad de que, justo cuando lo mira, es cuando está a nivel bajo.


¿Has mirado lo del comparador?

¿Por separado todo-todo funciona bien, incluido el comparador? esto sería raro, ya que el problema de no borrar la interrupción también lo tienes cuando está ella sola, aunque como no tienes bucle principal (puedes ponerlo vacío) no sabemos si se reinicia el solo...

Revisa el correo...

 

[navegante 420]

ya esta visto y contestado

 

[Gerard-2]

mañana me lo miro un poco, pero una cosa son pulsadores manuales y otra los de paso de vehiculos con acionamientos y gestion mucho mas rapida.

Me gustaria saber que tiempo puede estar accionado un detector como minimo, tienes alguna idea? velocidad maxima (+/-) de los vehiculos y longitud real de acionamiento sobre el detector? hay que dar un toque de seriedad al tema, no? jaja eso permite evaluar el tiempo minimo de ciclo de la vuelta del programa por ejemplo y justificar el algoritmo escogido.

Por los comentarios de Aunolose, tendrias que activar la temp desde la int y liberar las interrupciones, pero la temp tiene que ir por otro lado, la int no puede esperar a que acabe la temp.
Cuando se acaba la temp puede llamar su propia int para ejecutar lo que sea, si el ciclo de main es rapido este podria hacerse cargo y no sobrecargar gratuitamente la gestion de int's---------parece un telegrama, no? jaja supongo que se entiende la idea, hablo a nivel abstracto por que no me quiero mojar con concreciones, que no controlo el pic y seria peor.