Será por las interrupciones?

[Enigma]

pero como usas esta instruccion:
void deshatodas(void)
   {
      disable_interrupts(global);                     // Deshabilito todas las interrupciones
   }

el bit que deberia cambiar es GIE/GIEH, a cero si deshabilitas

bueno haber como va en la depuracion  suerte

un saludo

Exacto, ese bit permanece en cero (GIE/GIEH).... pero aun estando el desactivado, cuando presiono el pulsador de RB0 para la interrución uno, este bit el INT0IF cambia a 1, y no deberia puesto que he desactivado ñlas interrupciones globales.... o si deberia cambiar????

Jejeje gracias por el cursillo de proteus, me ha servido un montón... Eres el mejor!!!! 

Atte: Enigma... La llanerita de Guayana 

[Enigma]

el que puse como 2do lo utilizo como breakpoint (en realidad es eso, jeje), en cualquier linea me posiciono y le doy click ahi, y se pone una bolita roja que indica que ahi se detendrá la ejecución del programa en modo PLAY, si clikeas otra vez la bolita solo se pone rojo en el borde, y nose para que servira, pues tb hace un breakpoint, y si haces click otra vez en la bolita (icono 2º) la bolita roja se borra

Como se activa la bolita roja??? a mi no se me coloca.... lo simulo, y le doy pause y solo me aparece el cuadro pero con ese icono que denotas como segundo desactivado mira:




Atte: Enigma... La llanerita de Guayana

[poseidon20]

Exacto, ese bit permanece en cero (GIE/GIEH).... pero aun estando el desactivado, cuando presiono el pulsador de RB0 para la interrución uno, este bit el INT0IF cambia a 1, y no deberia puesto que he desactivado ñlas interrupciones globales.... o si deberia cambiar????

Jejeje gracias por el cursillo de proteus, me ha servido un montón... Eres el mejor!!!! 

Atte: Enigma... La llanerita de Guayana 

Lo que sucede con las interrupciones es que si activas el habilitador global GIE/GIEH, entonces cuando se produsca una interrupcion el PC saltara al vector de interrupcion y se pondra a 1 el flag de la interrupcion correspondiente, pero si no habilitas el GIE igualmente los flags de las interrupciones se colocaran en 1 pero como tienes deshabilitada el GIE tu PC no saltara al vector de Interrupcion. Una cosa son los habilitadores de las interrupciones y otras los flags de las mismas.Ojala pueda haber contribuido a despejar esa duda  .

[Enigma]

Ojala pueda haber contribuido a despejar esa duda  .

Que si la despejaste!!! más claro no pudo quedar!!! quede clarita como el agua!!! Más fiiiino! .... Gracias Poseidon20, eres es el mejor! Muy convincente y clara tu explicación..

Atte: Enigma... La llanerita de Guayana

[sander]

Primera observación:
Cuando via dipswith deshabilito las interrupciones; pues  el MCLR, el WDT y el teclado matricial funcionan correctamente, a que me refiero con esto: Bueno, aprieto el teclado y los números se me ven en el display, el WDT se me desborda a los 2:12 (excelente) y cuando le doy al pulsador del MCLR, se me reinicia el programa apareciendo la C de Clear (todo bello ) todo chevere (Ojo esto con el dipswith puesto en bajo, es decir, sin interrupciones habilitadas)

Y aqui has probado primero esperar el reset del watchdog y luego apretar el reset del MCLR?


Segunda Observación:

Cuando habilito las interrupciones, estás funcionan de maravilla(es decir, si aprieto el pulsador RB0(primera interrupción) me aparece el 1 y si aprieto el segundo pulsador (interrupción por RB1) me aparece el 2.... pero el MCLR, el WDT y el teclado no funcionan correctamente, me explico: Habilito via dipswith cada interrupción por separado y funcionan fino, le doy al teclado y funciona también, muestra los números, todo esto sin haber resetado via MCLR, pero cuando ahora le doy al pulsador del MCLR pues este me manda la causa del reset al display, es decir una C, como deberia ser, pero se queda pegado allí, el teclado no reacciona, lo único que funcionan son las interrupciones que cuando apriento el pulsador me aparece correctamente que fue la primera interrupción, y cuando apreto el segundo pulsador pues me aparece el 2, todo fino con ellas... Ahora con respecto al WDT, este se activa despues de 2:31 minutos, (mucho más tarde) y aparece la P de perro(lo que deberia hacer), pero cuando aprieto el pulsador del MCLR, no me aparece la C que deberia aparecer, sino que sigue la P del WDT allí pegada, y cuando le doy al pulsador de las interrupciones cada una sirve por separado (mostrando 1 o 2 dependiendo de cual active), pero cuando reseteo de nuevo por MCLR, pues sigue apareciendo la P del WDT en vez de la C del MCLR.

Este es mi dilema pergunta muchachos-.... que creen que pueda ser...

Les voy a anexar el codigo a ver si le quieren echar una ojeada...

Atte: Enigma... La llanerita de Guayana

Rarisimo lo que comentas, ya he leido estos tus problemas varias veces y aun no me imagino que podria ser podrias subir el archivo de simulacion que usaste? me gustaria hacer unas pruebas. Ademas que version del Proteus estas usando ? y que version del CCS?

Saludos

[Enigma]

Y aqui has probado primero esperar el reset del watchdog y luego apretar el reset del MCLR?

Si ya lo probe, deje que se desbordara el WDT, aparecio la P de perro y pues le di al pulsador del MCLR, y siguio la P pegada allí....

El  programa en C, lo puse en el primer post!!!! y el DSN te lo dejo en el .rar

Atte: Enigma... La llanerita de Guayana

[sander]

Y aqui has probado primero esperar el reset del watchdog y luego apretar el reset del MCLR?

Si ya lo probe, deje que se desbordara el WDT, aparecio la P de perro y pues le di al pulsador del MCLR, y siguio la P pegada allí....

Lo sospeche desde un principio... ..  .Cuando lei la primera vez tu post tenia una teoria que recien ahora la pude comprobar, leyendo el datasheet claro. bueno y es que el registro RCON  contiene los bits que indican los diferentes tipos de reset, el bit que controla el reset por watchdog es el TO, del cual se dice lo siguiente

_TO

1 = Set by power up ,CLRWDT instruccion , or SLEEP instruccion
0 = A WDT timeout ocurred

Como veras este bit es activo en bajo y no vuelve a uno a no ser que se encienda el PIC se resetee el watchdog o se lo ponga  a dormir , el reset por MCLR no lo afecta.
 
En tu programa la primera causa de reset que revisas es la del WDT, cuando este se produce _TO = 0  y como no pones en uno este bit despues de reconocer el reset, la resetear por MCLR  el programa  te dice que la causa fue la del WDT, porque despues del MCLR _TO sigue en cero,  entonces la solucion es que cuando detectes esta causa de reset debes de limpiar el WDT para poner este bit en uno y asi poder detecar el reset de MCLR.

La segunda parte de tu problema aun me parece rarisima.
 
y que version del proteus usas?
y del CCS?

Saludos

[Enigma]

Lo sospeche desde un principio... ..  .Cuando lei la primera vez tu post tenia una teoria que recien ahora la pude comprobar, leyendo el datasheet claro. bueno y es que el registro RCON  contiene los bits que indican los diferentes tipos de reset, el bit que controla el reset por watchdog es el TO, del cual se dice lo siguiente

_TO

1 = Set by power up ,CLRWDT instruccion , or SLEEP instruccion
0 = A WDT timeout ocurred

Como veras este bit es activo en bajo y no vuelve a uno a no ser que se encienda el PIC se resetee el watchdog o se lo ponga  a dormir , el reset por MCLR no lo afecta.
 
En tu programa la primera causa de reset que revisas es la del WDT, cuando este se produce _TO = 0  y como no pones en uno este bit despues de reconocer el reset, la resetear por MCLR  el programa  te dice que la causa fue la del WDT, porque despues del MCLR _TO sigue en cero,  entonces la solucion es que cuando detectes esta causa de reset debes de limpiar el WDT para poner este bit en uno y asi poder detecar el reset de MCLR.

Coye!!! berro, yo había leido lo del RCON en el datasheet, pero no sabia que había que volver a poner en 1 el flag del perro Guardian... chanfle ahora si funciona.... Dios como se aprende en este foro gracias a personas como ustedes!!! jejejeje...

Muchas Gracias de pana!! Sander!

Si lo de la segunda parte es bien rara!!!  es como si se quedará sólo en la rutina de chequeo del dpswitch y de las interrupciones, como sino pasará por la rutina del teclado!!!!! Ya he hecho de todo de pana!, 

Atte: Enigma... La llanerita de Guayana

[sander]

Y bueno, luego de estar jugando un rato con el proteus 7.2 SP0 , es el que tengo yo descubri el segundo error , pero segun yo es error del proteus. resulta que despues de un reset el valor de PIE2 es B'00100000', esto que quiere decir , que se habilita la interrupcion USBIE, y en el PIR2 casualmente tenemos USBIF = 1    lo cual segun la hoja de datos no deberia pasar por lo menos en la version que tengo, ya mas rato chequeo la errata,  entonces cuando llegas a habilitar todas las interrupciones (por cierto que tambien se habilitan las interrupciones perifericas ), vas al vector de interrupcion a atender la interrupcion del USB ,la cual obviamente no atiendes y todo el tiempo quedas dando vueltas entre la interrupcion y la instruccion siguiente a habilitar todas las interrupciones por lo cual nunca vuelves a leer el teclado.

Resumiendo despues de un reset el proteus 7.2 SP0 para el PIC18F4550 hace USBIE = 1 y USBIF = 1, solucion, por software yo hice :

definimos los registros que habiltan interrupciones perifericas

#byte    PIE1 = 0xF9D
#byte    PIE2= 0xFA0


y antes de habilitar todas las interrupciones:

            PIE1 = 0x00;
            PIE2= 0x00;
            enable_interrupts(global);                //Habilita máscara global de int.
poniendo los registros que habilitan interrupciones en el valor teorico despues del reset 0x00

Bueno eso es en simulacion, en la practica segun mi teoria eso no deberia pasar , a ver si alguien lo prueba.

Saludos

[Enigma]

 

Rayos!!! me has dejado atonita!!!! 

Jamás en la vida hubiese descubierto eso.... ... Muchacho Dios te bendiga tu experiencia y sabiduria!!!

Lo único que vi, eso si me di cuenta fue lo de los perifericos, esa si me di cuenta que se habilitaban porque chequee el registro INTCON, pero jamás se me hubiese ocurrido cheear el registro del USB.....

Naguara quien lo diria... Me habían dicho que está versión de poteus daba problemas, pero no hice caso! .... Está experiencia me ha hecho reflexionar y me ha hecho llegar a 3 conclusiones:

1) Este foro es increible!, Gracias a ustedes he aprendido demás...
2) Tengo que revisar todos los registros, cuando vaya a simular
3) Sigo prefiriendo el ASM jijijiji

berro de pana gracias chamo, eres el mejor oyó!!!, y deja que yo misma soy la que hará el montaje! hago el circuito y les digo!

Ahora una preguntica y disculpa el abuso no, pero podrías explicarme este pedacito, es que me hizo ruido!

vas al vector de interrupcion a atender la interrupcion del USB ,la cual obviamente no atiendes y todo el tiempo quedas dando vueltas entre la interrupcion y la instruccion siguiente a habilitar todas las interrupciones por lo cual nunca vuelves a leer el teclado.

Sabia que se quedaba pegado por allá en el vector de interrupción pero no entendi las ultimas líneas!!!

Mil Gracias de nuevo!!! Espero la explicación... y disculpa de nuevo!!

Atte: Enigma... La llanerita de Guayana

[Cryn]

Segun entendi la ultima linea que explica sander quiere decir que cada vez qeu una interrupocion ocurre el micro chequea el vector de interrupciones (veamos al vector como el que contiene los flag bits que le corresponde a cada interrupcion) y el micro esta viendo activo el flag del usb entonces supone que ha ocurrido una int por usb, lo cual en tu programa no sucede, y se queda como trabado ahi y de ahi que se qeuda con la P del perro qeu desborda y desborda, entonces ello lo soluciono con el codigo que te dejo para que no vea mas a ese int del usb. bueno al menos pienso que es eso, sino sander me corrige

aunque es raro ello ya que nunca habilitas int por usb, lo que con el global deberia mantenerse inactivo, muy raro, pueden ser problemas del compilador, lamentablemente el ccs trae muchos bugs (errores) en varias ocasiones ha sacado canas a muchos muchachos de aca, y pues ni modo, seria bueno cambiar de lenguaje, pero nose, hay tantas cosas, haber pues....

Como se activa la bolita roja??? a mi no se me coloca.... lo simulo, y le doy pause y solo me aparece el cuadro pero con ese icono que denotas como segundo desactivado

umm eso esta un poco raro.... talvez sea necesario integrar tu proteus con ccs

y aca lo que a mi me aparece con mi 7.1 sp4 de proteus, cuando le pongo el .cof y pause a una simulacion:


entonces lo que hago es posicionarme con el raton a cualquier linea del codigo, a la que quiera hecharle la mirada a fondo (despues de pausar "0º" ) click en el icono de breakpoint, y se qeuda marcada la linea, y por ultimo play para continuar, y la simulacion se pausará cuando el codigo llegue a la linea de breakpoint y te mostrara otra vez el codigo pausado en la linea donde pusiste la bolita, jeje, puedes poner varias bolitas donde quieras


qeudaron feitas las letras, jeje, esque despues del festejo de año nuevo, me quedo medio malo el pulso

espero te sirva un saludo, y que bueno que sander haya dado con el problema que pasaba

[Enigma]

Hola Cryn, gracias por responder, los manuales están excelentes, mis felicitaciones para el autor--- Pero no se creo que esto no actua sobre Proteus 7.2... ya que sigue los pasos al pie de la letra y pues nada, me sigue apareciendo el cuadro vació....

Si alguien tiene proteus 7.2 y logro hacer está adaptación... Pues aviseme y digame como lo hizo... porque el mio nada de nada... y cuando me voy al cuadro de Source - Define Code Generation tools y reviso los datos,. pues todos se me cambian a como estaban originalmente!!!! no se quedan quietos!!!!

Atte: Enigma... La llanerita de Guayana

[Cryn]

umm talvez talvez.... pues como te mencione en el privado no pude probar bien la 7.2 pues no me corria a gusto, se em salia, y de ahi liado con el tiempo no me di para tratar de verle mas a detalle el asunto

haber los que tengan la 7.2 haganse notar

[Enigma]

Si vale que mal que esta versión de proteus no acepte eso.... porque creo que es la única que tiene el 18F4550......

Señores que tengan PROTEUS 7.2 diganme, han podido adaptar C con PROTEUS????

Atte: Enigma... La llanerita de Guayana

[sander]

Bueno vamos por partes

Primero en la version  del proteus que tengo la 7.2 SP0 si pude cargar el codigo en C para simularlo y funciono bien, exceptuando la parte del reset claro.

aunque es raro ello ya que nunca habilitas int por usb, lo que con el global deberia mantenerse inactivo, muy raro, pueden ser problemas del compilador, lamentablemente el ccs trae muchos bugs (errores) en varias ocasiones ha sacado canas a muchos muchachos de aca, y pues ni modo, seria bueno cambiar de lenguaje, pero nose, hay tantas cosas, haber pues.... Mr. Green

Sobre esto que puso cryn  , a mi parecio que es error del proteus porque cuando hize el reset del MCLR el proteus habilito la interrupcion del USB , estoy seguro de esto porque revise el codigo en ensamblador que genera el CCS, al principio tambien pense que era un error del CCS, a mi tambien me dio muchos dolores de cabeza, pero resulto que no.

Sobre la ultima parte que puse en el anterior post , tiene que ver justamente con el vector de interrupcion, me explico , cuando revise el codigo en asm que genera el CCS note lo siguiente

Al momento de habilitar las interrupciones despues de revisar el dipswitch el CCS usa el siguiente codigo en asm

enable_interrupts(global);                //Habilita máscara global de int.
movlw    0xC0
iorwf      INTCON,F
bra        0x26C

la direccion 0x26C corresponde al inicio del ciclo infinito que enigma utiliza, bueno como puede verse el CCS ademas de habilitar la interrupcion global (bit 7), tambien habilita las interrupciones perifericas , esto ultimo en este caso en particular no es necesario, una vez actualizado el registro INTCON se deberia ejecutar el salto al inicio del ciclo infinito, pero como misteriosamente los bits USBIE y USBIF estan en 1 despues de un reset por MCLR o WDT (error del proteus segun yo), el microcontrolador va al vector de interrupciones donde sucede algo como lo siguiente :

en la posicion 0x08

//Primero el CCS guarda las variables de contexto y luego revisa las fuentes de interrupcion


0x04C    btfss     0xFF2.4           ;Revisa si la INT0 esta habilitada
0x04E    goto     0x058
0x052    btfsc     0xFF2,1          ;Revisa si produjo la INT0 (INT0IF = 1)
0x054    goto     0x0AA            ;Si se produjo va a atender esta interrupcion
0x058    btfss     0xFF0.3           ;Revisa si la INT1 esta habilitada
0x05A    goto     0x064
0X05E    btfsc     0xFF0,0          ;Revisa si produjo la INT1 (INT1IF = 1)
0x060    goto     0x0B6            ;Si se produjo va a atender esta interrupcion

//Despues el CCS recupera las variables de contexto y termina con el clasico

           retfie
En las rutinas de interrupcion que genera el CCS, este se encarga de poner en cero los bits INT0IF e INT1IF, para poder volver a la ejecucion normal del programa, el problemas es que al no esperarse la interrupcion por USB ,ya que no deberia pasar,el CCS no genera codigo para atender esta interrupcion entonces USBIE y USBIF estan siempre en 1 por lo que luego del retfie siempre se retorna al vector de interrupcion ya que USBIF y USBIE estan en 1. Entonces la solucion es deshabilitar por software de alguna forma la interrupcion por USB, pero solo para la simulacion, ya que segun la hoja de datos despues de un reset por MCLR o por WDT estas interrupciones estan deshabilitadas. pero esto ultimo aun hay que probarlo.

Saludos