TODOPIC
Microcontroladores PIC => Almacén del Assembler => Mensaje iniciado por: groundman en 13 de Febrero de 2010, 11:35:02
-
hola.queria abrir este tema no para explicar su funcionamiento.si no,para crear un debate al respecto de funciones que tiene el pic y que no solemos utilizar por el desconociminto de estas.que estan relacionadas con el reseteo del pic.
la mayoria de estas estan en la palabra de configuracion:como el BODEN ,PWRTE,WDT y otros.
quiero empezar por comentar algunas dudas sobre el watchdog:
es la primera vez que estoy usando el WDT y segun el datasheet hay unas lineas que no comprendo del todo.
son para cambiar del WDT -> TMR0 y del TMR0 ->WDT
en estas lineas se realiza el cambio del prescaler de TIMER0 a WDT
bcf STATUS,RP0 ;Bank 0
clrwdt ;Clear WDT
clrf TMR0 ;Clear TMR0 and prescaler
bsf STATUS,RP0 ;Bank 1
movlw b’00101111’ ;Required if desired
movwf OPTION_REG ; PS2:PS0 is
clrwdt ; 000 or 001
movlw b’00101xxx’ ;Set postscaler to
movwf OPTION_REG ; desired WDT rate
bcf STATUS,RP0 ;Bank 0
las dudas que tengo al respecto son:
segun lo de "required if desired" a mi entender dice que si la configuracion del prescaler es 000 o 001 forzosamente tendremos que borrar el WDT.
y que si es una configuracion diferente,no hace falta borrar el WDT.
o quedra decir que si la configuracion del prescaler es 000 o 001 tenemos que borra el WDT,y que posteriormente tenemos que volver a configurar el prescaler?
haber si alguien me puede aclarar esta duda.
respecto al cambio de WDT a TIMER0,no veo ninguna duda.
clrwdt ;Clear WDT and postscaler
bsf STATUS,RP0 ;Bank 1
movlw b’xxxx0xxx’ ;Select TMR0 prescale and
movwf OPTION_REG
bcf STATUS,RP0 ;Bank 0
otra duda que tengo respecto al seguimiento del WDT en el PMLAB.es que no veo ningun registro relacionado con el WDT.y no se cuando poner un clrwdt para ajustarlo lo mejor posible.
-
Hola groundman, no logré ubicar ese parte de "required if desired" en el datasheet, pero como yo lo entiendo, asignes o no asignes el prescaler al WDT, si lo habilitas (en la palabra de configuración), tienes que borrarlo de vez en cuando, si no, este generara el reset respectivo.
otra duda que tengo respecto al seguimiento del WDT en el PMLAB.es que no veo ningun registro relacionado con el WDT.y no se cuando poner un clrwdt para ajustarlo lo mejor posible.
Bueno, eso es por que el WDT es un temporizador físico al que no se tiene acceso ni de escritura ni de lectura, a lo mucho podrás asignarle el prescaler para retardar su cuenta. Respecto a donde ubicar mejor la instruccion clrwdt, eso es criterio propio del firmware, es decir, si le asignas prescaler o no, dependera cada cuanto tiempo borres el WDT, o si un proceso en especial se tiende a quedar en un bucle infinito por razones X.
Respecto al tema, sería interesante escuchar las experiencias de otros al usar estos recursos de la palabra de configuración y aprovechar de esa forma su potencial al máximo. Yo por ejemplo, siempre habilito el PWRT, para dar estabilidad al oscilador y esperar la linealidad de la fuente, el BODEN casi nunca lo uso, y el LVP, si no me equivoco es para habilitar el ICSP a 5 voltios, bueno, eso creo, porque solo lo eh leído, nunca lo he utilizado, corrijame alguién si me equivoco por favor.
un saludo y chao.
-
.
Es muy buena tu pregunta, yo nunca me había fijado en ese detalle. Me fijé en el datasheet, y a mi entender estas líneas:
movlw b’00101111’ ;Required if desired
movwf OPTION_REG ; PS2:PS0 is
clrwdt ; 000 or 001
Son requeridas si el valor que queremos ponerle es 000 ó 001. Aunque la gran intriga es.. ¿POR QUÉ? :huh:
Y ahora que lo pienso.. ¿Cuántos ciclos hacen falta para hacer saltar el WDT?
-
pues no sabia que al activar el WDT en la parabra de configuracion,habia que borrarlo aunque el prescaler estubiera asignado al TIMER0.
he hecho una pruevas y me he dado cuenta de que el reseteo del pic por no borrar el WDT sin que este asignado a este.es de 17742 ciclos de reloj despues de ejecutar el borrado del watchdog.
lo he calculado configurando TMR1 para que empieze a contar desde cero.despues de un clrwdt.en el MPSIM.
lo del requerimiento del datasheet habra que esperar a que algun guru nos lo aclare.
-
he hecho una pruevas y me he dado cuenta de que el reseteo del pic por no borrar el WDT sin que este asignado a este.es de 17742 ciclos de reloj despues de ejecutar el borrado del watchdog.
Hola groundman, supongo que cuando mencionas esto te refieres a que no has asignado el prescaler al WDT y que tus resultados de esta configuración dieron 17742 ciclos de instrucción después del último clrwdt. Bueno, eso es correcto, ya que si multiplicas el numero de instrucciones (17742) por el periodo de instrucción (que a juzgar por tus resultados es de 1 useg, debido a un oscilador de 4 MHz) dara como resultado aproximadamente los 18 mseg que tiene temporizado el WDT.
Lo que sucede es que el WDT es un oscilador independiente del oscilador principal, incluso puede seguir funcionando si no existe el oscilador principal, y su cuenta de temporizacion es de 18mseg (tipicamente), tengas un osciladorde 32 KHz o de 20 MHz. Esto se debe a que el WDT debe seguir funcionando incluso si el microcntrolador esta en modo sleep. Ahora supongamos que le asignamos el prescaler, y quieres saber la temporizacion resultante, la fórmula sería así :
TWDT = (PRESCALER)*18 ;el número 18 puede variar según el datasheet
entonces concluimos que la máxima temporización que se le puede asignar al WDT es de 2304 mseg aprox.
Bueno, suerte con tus demás pruebas y chao.
Pdta. sigo sin encontrar esa especificación en el datasheet, no podrías poner la pagina por favor para revisarla?
-
pues balla.hay cosas que no sabia.lo revisare bien.
respecto al datasheet es el del PIC 12F629/675 y esta en la pagina 29 "31 del pdf"
-
exacto JBQ.
he mirado el datasheet y el valor del tiempo en que el pic se resetea activando el WDT esta entre 10 y 25ms a 5V cuando la temperatura esta entre -40 y +85ºC
y de 17ms a temperatura ambiente.
aunque en el proteus he hecho nuevas pruevas.y es lo que tu dices.el WDT salta a los 18ms sin asignar el prescaler al WDT.
y si asignamos el prescaler al WDT tendriamos un maximo de 18ms x 128=2.304 segundos
ya lo he entendido.lo bueno de esto es que si asignamos el prescaler al TMR0.podremos usar el TMR0 y el WDT al mismo tiempo.
solo tenemos que usar un clrwdt en un lugar estrategico.
lo que no entiendo es algo que he visto en algun tema de ajustar el WDT.
creo que esto es bastante dificil si el oscilador principal y el del WDT no estan sincronizados.aunque se aproximan bastante.
porque en 18ms se han ejecutado 17742 instrucciones a 1us por instruccion. 0.018-0.017742= 258us de retarso en el WDT.en este caso significa que
el oscilador del WDT es de 3.875968Mhz
para ajustar el WDT los tiempos de este deberian de poder ser programados con mas exactitud.y decidiendo cuantas instrucciones queremos
que se ejecuten antes de que borremos el WDT para que no salte.
en el caso real tienen que pasar 17742 instrucciones-1 sin prescaler.para borrar el WDT y que no se resetee el pic.siempre y cuando por causas de temperatura
no varie la frecuencia del WDT.
esa seria la forma de ajustar al maximo el WDT.a no ser que ajustar el WDT no signifique esto.
-
.
Según el datasheet del 12F629 (página 64) en el peor de los casos (vdd=min, temp=max, wdt_prescaler=max) toman varios segundos antes de que el wdt se active. A mi me da a entender que el temporizador no se vuelve más rápido por empeorar las condiciones, sino más lento, así que tomar como referencia un valor de aprox 18ms (sin prescaler) pareciera aceptable. Aunque siempre conviene adelantarse un poquito y hacer que sean 15ms ;-)
Por cierto, muy interesantes tus investigaciones. Saludos.
-
gracias mtristan.ya se lo que quieres decir.pero no creo que sea eficaz del todo vajar el voltage y aumentar la temperatura para llegar a tener un desbordamiento
del WDT mas corto.
otra cosa que quiero comentar es que no se puede fiar uno mucho del simulador.ya que el el proteus la simulacion me va perfectamente.pero en el circuito fisico.
he tenido que intercalar un clrwdt.para que el pic no estubiera constantemente reiniciandose.
con esto quiero decir que es mas facil que en el montage fisico.el WDT es mas rapido que en el simulador.
-
.
Una investigación apenas más exhaustiva (página 98 del mencionado datasheet) indica lo siguiente:
Watchdog Timer Time-Out Period (No Prescaler; Vdd=5V; -40ºC<Temp<+85ºC): Min=10ms; Typ(25ºC)=17ms; Max=25ms.
Parece ser que es bastante menos que los 15ms que yo preveía :tongue:
-
de lo que deduzco de unos calculos que he realizado.que el tiempo de variacion es de 120us por grado.
no estoy muy seguro.pero si realizamos un programa con estos datos,es posible que se pueda calcular la temperatura interna del pic.
y visualizarla en un lcd.
-
Hola a todos. groundman, ya encontré esa parte de datasheet que mencionas y procedo a explicarla según mi modesto entender:
Como ya se sabe, el prescaler está compartido entre el TMR0 y el WDT, y su asignación a uno de ellos se hace mediante el bit PSA del registro OPTION_REG.
Lo interesante, es que esto se puede hacer en cualquier momento, es decir, en un mismo firmware puedes asignarle primero al WDT, luego al TMR0. luego al WDT y asi sucesivamente (cosa poco practica y usada según yo creo). Entonces aqui entra a tallar ese detalle, al hacer estos "sucesivos intercambios", no basta con tan solo manipular el bit PSA, se tiene que seguir esta secuencia de instrucciones si se desea que el WDT trabaje correctamente (pero solo si se desea que el WDT trabaje con un prescaler de 1 ó 2).
Me explico mejor: supongamos que el prescaler está asignado al TMR0 y por motivos x del firmware ahora deseas asignarselo al WDT, entonces tendrías que hacer esto:
movlw b'xxxx1xxx'
movwf OPTION_REG
pero esto solo es valido si los bits PS<2:0> estan comprendidos entre los valores 010 y 111. En caso se desee que su valor sea 000 ó 001, la secuencia a de ser la sgte.
movlw b'00101111' ;estas 3 lineas son las requeridas si se desea un
mowf OPTION_REG ;prescaler para el WDT de 1 ó 2 cuando se hace el
clrwdt ;cambio desde el TMR0 al WDT
movlw b'xxxx1xxx'
movwf OPTION_REG
y luego de la secuencia requerida, recién los bits PS<2:0> toman el valor deseado, sea 000 ó 001.
como se podrá observar, esto solo se realiza cuando el prescaler es reasignado desde el TMR0 al WDT, pero que sucede si es al revés, bueno aqui el asunto es más fácil, ya que no hay prerequisitos para la configuración de los bits PS<2:0>, entonces la secuencia sería como sigue:
movlw b'xxxx0xxx'
movwf OPTION_REG
y resulta que esta es la forma que generalmente más se usa, ya que por defecto (es decir, cuando alimentamos el microcontrlador), el prescaler inicia asignado al WDT, oséa el bit PSA seteado, entonces cuando queremos asignar el prescaler al TMR0, solo realizamos la secuencia anterior sin ningun prerrequisito, y si en caso contrario, queremos darle un prescaler de 1 ó 2 o x al WDT, pues ya no es necesario la secuencia requerida ya que el prescaler ya esta asignado al WDT por default.
Bueno, eso es todo, espero haber contribuido en algo, un saludo a todos y chao.
-
muy bien JBQ.mejor no creo que se pueda explicar.lo he entendido a la perfeccion.no sabia que por defecto se asignaba el prescaler al WDT.
lo que no estoy muy seguro es si el valor requerido b'00101111' tiene que ser exactamente este.porque hay bits en este registro que no tienen nada que ver
con el WDT o el TMR0.como son el bit 7 para las resistencias pull-up.y el 6 para la interrupcion por cambio de GP2/tocki.
e incluso el bit 5 y 4 que aunque si trabajan con el TMR0 puede ser que no hubiera que tocarlos.
almenos no hacen falta tocarlos si queremos pasar del WDT al TMR0 y biceversa.cuando no usamos las divisiones 000 y 001.
-
Hola groundman, respecto a si tiene que ser ese valor exacto de b'00101111' en el OPTION_REG, no estoy tan seguro, ya que no he tenido la ocasión de realizarlo, pero ya que lo mencionamos por aqui, me puse a realizar pruebas, y vaya que fueron realmente controvertidas:
Primero, que el valor de los 4bit MSB del OPTION_REG (<7:4>), es sin importancia.
Segundo, es muy importante antes de manipular el OPTION_REG, borrar el TMR0 (clrf TMR0), solo si estas en esta cuestión de cambiar el prescaler desde el TMR0 hacia el WDT.
Bueno esos fueron los resultados, y en conclusión, solo con borrar el TMR0 antes de hacer cambios en el OPTION_REG en los bits PSA y PS<2:0> es suficiente.
Es raro, ya que busque y busque y no encontre ninguna errata con respecto a eso.
Bueno, como te comente antes, eso de de estar intercambiando el prescaler entre el WDT y el TMR0, no es muy practico ni recomendado, ya que al inicio de configuración deregistros en tu firmware, o le asignas el prescaler al WDT o al TMR0, y listo, solo una vez y de la formas que desees, mediante manipulación de bits (bsf bcf), o por registros (movlw movwf).
En fin, eso es lo que dice el datasheet, y no es la primera cosa extraña que encuentro, algo similar me paso con el TIMER1, su datasheet decia una cosa con respecto al bit T1OSCEN del T1CON, pero las pruebas daban otro resultado.
Un saludo y chao.
-
valla.te lo has currao muy bien.siempre hay cosas raras en los microcontroladores.aunque como tu dices.no es muy practico estar cambiando el prescaler para el WDT y el TMR0.prefiero intercalar mas clrwdt entre las lineas del codigo.
-
Hola groundman, que significa "currao"? es un elogio o un peyorativo?.
-
que es un peyorativo? :D
en españa el curro es el trabajo.que la verdad no hay mucho con la crisis.currao es que te lo has trabajado.
saludos.
-
ah, bueno, de todas maneras gracias por la explicación. Entonces sigamos curreando, que todavía hay más por aprender e investigar.... saludos y chao.
-
pues bien.ya que hemos empezado a ablar sobre el WATCHDOG,quiero proseguir.
estoy empezando a usar este dispositivo interno.y me estan surgiendo una serie de problemas al implementarlo en el codigo asm.
el principal problema que se me plantea es naturalmente de que el simulador se resetea continuamente.cosa muy normal ya que el WDT se desborda por no
poner un clrwdt estrategicamente en las lineas del codigo.
una de las primeras cosas que he hecho es poner un BREAKPOIN antes del programa principal,es decir en la parte del codigo donde solo se va a pasar una sola vez.
a no ser que el programa se reinicie.
de esta forma el programa se parara cuando se produzca el desbordamiento del WATCHDOG.esto lo hago porque no se donde esta la opcion en el simulador;
para que el programa se pare nada mas se produzca el reset por WDT.
otra cosa que he aprendido es tener mucho cuidado con los subprogramas que usen retardos.la mayoria de los reseteos se producen en estos.por no poner
un clrwdt adecuadamente.
otro problema esta en los bucles donde se espera a que se produzca un evento.
ejem.
btfss REGISTRO,X
goto $-1
deberiamos poner:
clrwdt
btfss REGISTRO,X
goto $-2
a no ser que sepamos que el evento va a producirse antes de que se desborde el WDT.
usando la opcion de solo activar el WDT descartamos el uso del prescaler para el WDT.y asi poder aprobecharlo para el TMR0.
y con 18ms tenemos un tiempo que nos da mas precision a la hora de reiniciar el pic por un bloqueo de este.
con lo que he expuesto invito a la gente a exponer su experiencia en el tema.y quizas podamos aprender un poco mas sobre este sistema de proteccion.
-
En creación de demoras, el programa que se presenta aquí (http://www.todopic.com.ar/foros/index.php?topic=5968.0) tiene incluido el clrwdt entre sus lineas. ;-)
Saludos!
-
muy bueno.si señor.ya nunca dejare de usarlo.
referente a las precauciones que hay que tomar respecto al uso del WDT.tengo entendido que no es aconsejable este llegue a reiniciarse dentro de un programa
que esta atendiendo a una interrupcion.
esto es cierto?
y tambien es desaconsejable usrar clrwdt dentro de la interrupcion?
que cosas raras pude llegar ha hacer un pic para que no siga su ejecucion normal,y se quede en un bucle infinito ?
podria llegar a darse la casualidad de que este entre en un bucle infinito donde se borra constantemente el WDT.y el pic no se reinicie?
y me refiero a un bucle por fallo.no porque este esperando un evento.
-
Otra cosa muy importante acerca del perro guardián, es que no se trata de poner clrwdt en partes del programa para que el mismo no se resetee, sino que hay que armar el firmware de una manera que, al cabo de un reset, el CP pueda retomar en una rutina segura.
La función principal del perro guardián, es la de desbloquear al CP cuando este queda en un bucle infinito y no hay nada que lo haga salir. Esto se puede dar por la espera de un evento externo que por una causa, jamás llegará.
Por lo tanto, el firmware tiene que tener las siguientes "propiedades":
1. Ser multitarea, para que en el caso de un reset, el CP siga con otra función.
2. Que sea capaz de retomar a una parte del programa seguro para que pueda hacer otra función. En caso de necesitar un evento externo que jamás llega, volverá al reset y comenzará de nuevo.
No obstante, la función de multitarea, va a prevenir que el CP deje de hacer otras funciones necesarias. Supongamos que tiene que hacer 6 tareas diferentes, de las cuales 1 necesitará un evento externo y el dispositivo que entrega el dato está apagado. Cuando se produzca el reset, el CP tiene que ser capaz de seguir con las 5 tareas restantes. No importa si para cumplir las tareas restantes, tenga que resetearse una 10 veces (por poner un ejemplo) pero tiene que ser capaz de hacerlas.
-
no se si te entiendo muy bien.
te refieres a que testeemos los bit del registro STATUS ligados al WDT,para comprovar si se ha produciodo un desbordamiento del WDT.y guardarlos en la memoria para obrar en consecuencia al fallo?
si es asi me parece una buena idea.para que el programa prosiguiera en otro subprograma y este no quede siempre bloqueado.
esto seria util si por ejemplo quisieramos visualizar en una lcd.diferentes lecturas y que si por algun motivo el pic se reiniciara un numero determinado de veces,apareciera un mensage de error.
pero si el problema fuera por una interferencia,que no tubiera que ver con el circuito que maneja.
creo que daria igual tener esta precaucion.ya que el pic seguiria reiniciandose por bloqueo.
supongo que todo depende de en que parte del codigo se bloquee.y como se bloquee.
no es lo mismo que se quede pillado en una instruccion,a que el PC de un salto indeterminado de instrucciones y no se ejecuten
algunas instruciones.
entonces el programa no seguiria su correcto curso.y no hace falta que se reiniciase .porque podria haberse dado el caso de que hubiera pasado por un clrwdt.
supongo que prevenir el comportamiento del pic ante este tipo de fallos no es algo sencillo.
por ejemplo.estoy realizando un programa para regular la intensidad de una lampara de 220v de filamento.en este tipo de lamparas no suelen producirse
interferencias mas alla que la propia conmutacion del triac.pero estas interferencias si se producen al regular las lampara de bajo consumo.ya que internamente
estas trabajan con alto voltage.
las interferencias se suelen producir durante su ajuste.y mas comunmente cuando su iluminacion es menor.
hasta ahora tengo el programa bastante trabajado y me da menos problemas.ya que durante su regulacion,voy grabando en la eepronm de datos interna
el valor de esta.y si se reinicia,se toma el ultimo valor guardado.
pero que pasaria si la interferencia fuera tal que no diera tiempo ni ha guardar el valor en la eeprom.
pues que ya no me serviria ningun tipo de proteccion por sofware.y tendria que aislar el pic de la corriente de la red electrica.
-
Para mi, el wdt no está pensado para el ruido eléctrico porque es como dices tu, si salta a otra parte del programa debido a interferencias, tarde o temprano pasará por un clrfwdt y jamás se reseteará. También está la posibilidad de que no pase por un clrfwdt y se resetee el pic.
te refieres a que testeemos los bit del registro STATUS ligados al WDT,para comprovar si se ha produciodo un desbordamiento del WDT.y guardarlos en la memoria para obrar en consecuencia al fallo?
Si eso mismo. Chequear el bit TO del registro Status para ver si se reseteo el pic por el WDT. Esto es obvio que hay que hacerlo al principio del programa.
-
Hola a todos, de nuevo por estos lares. Respecto a...
y tambien es desaconsejable usrar clrwdt dentro de la interrupcion?
no lo creo, ya que esta instrucción no tiene ningún otro efecto mas que el de resetear la cuenta del WDT y los bit TO y PD.
Si eso mismo. Chequear el bit TO del registro Status para ver si se reseteo el pic por el WDT. Esto es obvio que hay que hacerlo al principio del programa.
Eso es correcto, si su usa el WDT, pero no debemos de olvidar también de volver a configurar los registros del microcontrolador, ya que algunos de estos cambian sus valores luego de haberse dado el reseteo por WDT.
pero que pasaria si la interferencia fuera tal que no diera tiempo ni ha guardar el valor en la eeprom.
pues que ya no me serviria ningun tipo de proteccion por sofware.y tendria que aislar el pic de la corriente de la red electrica.
Si bien es cierto que el bit TO nos indica si ocurrió un reset por WDT o no, también están los bits POR y BOR, que creo también pueden ayudar en estos casos.
De todas maneras, es necesario evitar estos tipos de interferencias con filtros, reguladores, etc.
un saludo a todos y chao.
-
Eso es correcto, si su usa el WDT, pero no debemos de olvidar también de volver a configurar los registros del microcontrolador, ya que algunos de estos cambian sus valores luego de haberse dado el reseteo por WDT.
esto que acabas de decir esta muy bien.no habia caido en eso.pero a que registros te refieres?
el reseteo del pic hace que se vuelvan a configurar todos los registros de nuevo.a no ser que no queramos hacerlo, testando el bit
del suceso de desbordamiento del WDT.pero no creo que esto sea muy recomendable.
el guardar datos en la eeprom de datos.es una opcion si nos interesa dejar funcionando al circuito tal y como estaba funcinando la ultima vez.o almenos salvar datos que se estaban procesando.
aunque esto se hace con los registros de proposito general.y no se debe usar mucho.por el desgaste de la eeprom.
pero claro.todo depende del tipo de programa que estemos realizando.
lo que quiero decir es que no podemos estar guardando por ejemplo un registro que va a estar constantemente variando sus datos.
ya que quemariamos la eeprom de datos.
en este programa que estoy realizando.guardo el valor de regulacion,estado de la lampara on/off y la lampara que estaba encendida.
estos datos puede que se guarden 20 veces al dia.mas o menos.depende si es un salon.un dormitorio o un pasillo.este ultimo si que puede
que se guarde mas veces.
asi que si tenemos una media de 1.000.000 de grabaciones maximo que admite estas eeprom.tenemos 1.000.000/20=136 años de uso del pic.
y si puera el pasillo con una media de 100 pulsaciones diarias.tendriamos 27 años.
ahora.si guardamos un dato que se va a estar actualizando cada segundo.tendriamos 277 horas de funcionamiento.
por eso si pudieras exponer a que registros te refieres.seria de mucha utilidad.
-
el reseteo del pic hace que se vuelvan a configurar todos los registros de nuevo.a no ser que no queramos hacerlo, testando el bit
del suceso de desbordamiento del WDT.pero no creo que esto sea muy recomendable.
el guardar datos en la eeprom de datos.es una opcion si nos interesa dejar funcionando al circuito tal y como estaba funcinando la ultima vez.o almenos salvar datos que se estaban procesando.
aunque esto se hace con los registros de proposito general.y no se debe usar mucho.por el desgaste de la eeprom.
Disculpa pero no entendi nada de lo que quiciste decir aqui.
********************************************
Respecto a los registros que se alteran al producirse el reset, sea por WDT o por cualquier otra fuente de los servicios de reset del microcontrolador, puedes darle un vistazo al datasheet respectivo del micro en particular a usar. Por ejemplo, para los archiconocidos PIC16F877A y PIC16F628A los puedes encontrar en las tablas 14.6 y 14.7 respectivamente. suerte con tu programa.
-
No estoy seguro lo que voy a decir, pero en caso de un reset producido por el WDT, solo algunos registros son afectados.
-
.
No estoy seguro lo que voy a decir, pero en caso de un reset producido por el WDT, solo algunos registros son afectados
Me tomo el atrevimiento de contradecirte. Según el datasheet del 16F628A las condiciones de los registros luego de un reset por WDT son las mismas que un reset por activación del pin MCLR.
Este hilo está interesantísimo :smiley:
-
.
No estoy seguro lo que voy a decir, pero en caso de un reset producido por el WDT, solo algunos registros son afectados
Me tomo el atrevimiento de contradecirte. Según el datasheet del 16F628A las condiciones de los registros luego de un reset por WDT son las mismas que un reset por activación del pin MCLR.
Este hilo está interesantísimo :smiley:
¿Me puedes indicar dónde dice eso? Porque es justamente lo que ando buscando y no lo encuentro.
-
hola Leon Pic y mtristan, pueden despejar sus dudas dando un vistazo a la sección respectiva del datasheet; en la sección 14.3, caracteristicas especiales de la CPU/reset, y para un completo estado de los registros luego de un reset, ver la tabla 14.7 (esto específicamente para el PIC16F628A). un saludo.
-
.
Ahora me ponés en duda :|. Yo había visto la tabla 14-7 (página 101 del datasheet del 16F628A) y, según a mi entender, los registros son afectados de la misma forma ya sea luego de un WDT reset o del MCLR reset.
-
.
Ahora me ponés en duda :|. Yo había visto la tabla 14-7 (página 101 del datasheet del 16F628A) y, según a mi entender, los registros son afectados de la misma forma ya sea luego de un WDT reset o del MCLR reset.
En esto último estas en lo correcto, pero si te fijas bién, no es lo mismo un reset por WDT durante la ejecución normal del código, a un reste por WDT durante el estado del SLEEP. la invitación para ver la tabla, era para los que no conocían los registros que se alteraban al producirse el reset. (a tí te sale la pagina 101, que raro , a mi me sale la pagina 106, ?)
PDTA. que significa ese punto al inicio del mensaje? .. saludos
-
.
Eso es cierto. Resulta que da lo mismo un MCLR reset en modo normal o sleep, pero no un WDT reset en modo normal o sleep. De hecho, luego de un WDT wake-up, salvo los registros INTCON, PIR y STATUS, de ningún otro se puede estar seguro de como terminan. ¿Quiere decir esto que después de salir del modo sleep hay que configurar todo el pic devuelta? :huh:
-
¿Quiere decir esto que después de salir del modo sleep hay que configurar todo el pic devuelta?
Solo si es por motivo del WDT, ya que si esto no ocurriese, significaria que el micro seguiría dormido, y que el proceso que se debería dar para despertar al micro, no se dió o nunca se hubiea dado.
saludos...