TODOPIC
Misceláneas - Interés General => Off Topic => Mensaje iniciado por: planeta9999 en 28 de Agosto de 2017, 16:09:49
-
Estaba cuestionándome sobre la importancia del uso del Watchdog, en desarrollos profesionales. La verdad, nunca le he tenido cariño al Watchdog, para mi era un incordio o algo irrelevante.
Recientemente estuve intercambiando mensajes en los foros de NXP sobre el tema del bootloader encriptado con uTasker (que va de fábula), y para tratar de resolver algunos problemas, su autor me sugirió desactivar temporalmente el Watchdog, y aunque al final los tiros no iban por ahí, me hizo un comentario que me hizo pensar.
¿ Que pensais sobre la importancia del Watchdog, es tan imprescindible como me han sugerido para usos profesionales ?
" P.S. The watchdog concept is generally the most important part of any product design. Arduino always disables it as far as I known but this is probably due to the fact that the Arduino libraries are intended for maker's projects where simplicity has priority over reliability. For professional work Arduino is a starting point but needs further development in order to achieve adequate quality.
This blog entry may highlight some important reasons to be very careful with Arduino:
http://embedded.fm/blog/2017/8/12/dont-use-arduino-for-professional-work "
-
Yo no lo suelo usar. El wdt te da un diagnóstico de que algo has programado mal o no has tenido en cuenta algún escenario pero no soluciona el problema. Si se te atasca el código por lo que sea puedes resetear o volver a un estado anterior pero eso no evitará que el bug vuelva a darse. Yo soy más de encontrarme con las sorpresas y luego solucionarlas jejeje. Aq no pongo en duda q sea útil: si no se hubiese dejado de poner en los micros y ahí lleva décadas...
Gran artículo!
-
Yo si lo uso, pero lo uso en el caso del codigo "final" y no un codigo que todavia esta en desarrollo. Porque intento evitar todo el tema de lidiar con el WDT hasta ese ultimo momento y Como pocas veces termino usando un delay muy grande, luego no es problema de implementacion.
Tambien te encontras no solo con el WDT, sino con los flags que te indican porque el micro fue detenido.
-
Yo estoy totalmente de acuerdo con el comentario del creador de utask, es una de las partes mas importantes. Aunque como dice killer, hay que implementarlo al final, primero hay que probar todas las cosas que pueden salir mal, arreglarlas y dejar el programa superpulido. Despues se habilita el WDT para que este se ocupe de algo puntual que pueda ocurrir y que tu no puedas ni controlar ni predecir, yo que se.... que se rompa un cable en mitad de una transmisión, que caiga un rayo cercano, cualquier cosa que pueda pasar y que no puedas controlar.
es un sistema de seguridad final y en mi opinión nunca debe faltar, pero cuidado, tampoco se debe utilizar para reiniciar el micro por cualquier tonteria, si un programa esta bien hecho el WDT no debe saltar.
Es como el airbag del coche, no debe funcionar a no ser que pase un accidente.
un saludo
-
¿ Y como poneis el refresco del Watchdog, por aquí y por allá de manera anárquica en cada rutina, en el bucle del programa principal, con un timer para que se reinicie cada cierto tiempo ?.
Entiendo que pueda ser importante en entornos industriales, donde el fallo de un programa que controla máquinas, pueda provocar un desastre.
El problema es que tengo algunos diseños con tiempos críticos, usando DMA, y meter más cosas al programa, puede perjudicar más que ayudar.
Para mi lo que si es imprescindible es un buen bootloader encriptado, para poder corregir cosas y dar parches o nuevas versiones de firmware a distancia. El uTasker va genial (probado con Kinetis, lo quiero probar tambien con STM32), y para dar nuevas versiones de firmware al cliente, he creado un Github.
-
Y como poneis el refresco del Watchdog, por aquí y por allá de manera anárquica en cada rutina
Noooo, eso nunca, el WDT solo se refresca una vez en todo el programa, nunca en cada rutina ni en cada bucle... eso hace que tener el WDT y no tenerlo sea exactamente lo mismo, debes calcular cuanto tiempo maximo puede tardar tu programa en ejecutarse y poner un WDT que reinicie si tarda mas. si tu programa se queda parado en un bucle y el bucle lo esta reseteando de que te sirve?
no solo en entornos industriales, cualquier chisme que quiera tener un poco de calidad debe de poder reiniciarse solo en caso de que se quede pillado. No todos algunos procesos industriales necesitan un rearme manual para indicar que se ha visto el fallo y cosas asi, pero por norma general deberia estar en todos los sistemas, puede que haya alguna aplicación donde este prohibido pero debería estar en todos.
PD: Muy buen articulo, muy bien resumido y toda la razón.
PD2: cuando digo una sola vez en todo el programa, me refiero a una vez en cada ciclo del programa.
-
Ya que lo tienes es útil ponerlo, más aún en dispositivos que pueden pasar meses conectados sin intervención del usuario, pero como dice manwenwe, si todo está bien diseñado no debería saltar..
-
Del enlace original a embedded.fm, he mirado en esa web y se ven artículos interesantes:
http://embedded.fm/blog/embedded-wednesdays
Y en general todos los que están en el apartado "EMBEDDED WEDNESDAYS"
http://embedded.fm/blog/?tag=Embedded+Wednesdays
Como este sobre DMA.
http://embedded.fm/blog/2017/2/27/dma-examples
Creo que en cuanto domine un poco el DMA, podré hacer virguerías
-
Os recomiendo leer este mensaje de Azicuetano, yo para trabajos profesionales considero imprescindible lo de los checkpoints
http://www.todopic.com.ar/foros/index.php?topic=12418.msg70483#msg70483
-
El tema esta en que realizar esos checkpoints y que te salte el programa al vector de reset es un problema.
En los PICs 16 y 18 no se resetearia el stack y por consiguiente pasa a un stack overflow. (agregar codigo de limpieza de stack en el archivo de inicializacion de C para evitar esto)
En los ARMs, dsPIC y PIC32 menos problemas con eso, pero no detectas nada ya que al iniciar todo de nuevo tenes tu variable en 0.
En lo unico util es cuando salte a otra seccion de codigo de forma inesperada, y pienso que eso implica que tenga una buena cantidad de memoria ocupada. Ademas no quita la posiblidad que salte en un lugar que sea:
- Cuando se hace 0 la variable
- Que coincida correctamente con el checkpoint que es de otra funcion sea con suma o no
- Que ocurra luego de la comparacion del checkpoint
Es cierto que aumentas un poco mas el grado de seguridad de tu codigo, pero no lo eliminas completamente, un refuerzo seria ademas utilizar valores variables en cada funcion.
La otra que queda para ayudar a eso de los checkpoints es llenar la memoria del integrado con saltos a loops infinito para que lo tome el WDT y conocer a ciencia cierta que el reset provino del WDT. En caso contrario de que llegue al vector de reset imlpica que no se detecte la falla. El resultado es lo mismo = reset, pero la diferencia es detectar o no la falla.
-
No es frecuente que un microcontrolador se cuelgue (como el pantallazo azul en Windows), pero a veces pasa. En ese caso la máquina se quedaría inservible hasta que alguien venga y la resetee. Con un WDT no hace falta, se resetea sola y puede incluso guardar un log o enviar un mensaje con el fallo. Es mucho más profesional.
Saludos.
-
En ese caso la máquina se quedaría inservible hasta que alguien venga y la resetee. Con un WDT no hace falta, se resetea sola y puede incluso guardar un log o enviar un mensaje con el fallo. Es mucho más profesional.
¿ Y para que hace falta que alguien vaya a resetear un microcontrolador ?, lo desconectas de la corriente, lo vuelves a enchufar y arreando, el resultado será el mismo que el de un Watchdog, pero a mano.
No creo que la utilidad del Watchdog sea esa, sino proteger la periferia que maneja ese micro si falla. Seguro que hay entornos industriales, médicos y demás en los que puede ser crítico que una máquina se vuelva loca porque entre en un bucle o salte a una parte del programa sin control.
Lo que hará falta es que el programador de turno lo arregle y envíe una actualización por email, Skype, Telegram, etc... No hace falta desplazarse, a menos que sea una avería física.
-
¿ Y para que hace falta que alguien vaya a resetear un microcontrolador ?, lo desconectas de la corriente, lo vuelves a enchufar y arreando, el resultado será el mismo que el de un Watchdog, pero a mano.
Imagina, Un almacen de congelados, el termostato se queda colgado a las 2 de la mañana, y se pierden miles de euros de productos que se han descongelado por que el programador dijo que era lo mismo desenchufar y enchufar manualmente que a que lo hiciera el propio micro.
-
Me refería a la necesidad de que un técnico se tenga que desplazar para resetear la unidad, o así lo entendí yo. Desconectas la unidad y la vuelves a conectar, no hace falta ningún técnico para eso, eso no suple las funciones del Watchdog, pero tampoco te obliga a llamar a nadie para reiniciar la unidad.
Precisamente la aplicación que yo entiendo es prioritaria en un Watchdog, es evitar desastres si una máquina se vuelve loca por entrar el programa en un bucle o saltar a una zona del programa sin control.
No he tenido ningún caso, en el que haya echado en falta el Watchdog, igual en el diseño de la ruleta lo pongo, no vaya a ser que la máquina se vuelva loca y empiece a dar monedas sin parar. Si diseñara aparatos médicos si que lo usaría sin dudarlo, o para controlar máquinas industriales,
-
A para ese caso si.
Yo te he puesto ese ejemplo precisamente por que la mayoría de mis proyectos son para medicina y sector de frio industrial, y ha pasado que muchos termostatos de los modelos antiguos se quedaban colgados y hacían un bloque de hielo o se derretía todo, el diseñador que lo hizo no puso WDT, tampoco es que hiciera bien el software por que se quedaban colgados muchas veces...
Prueba a usarlo en alguno de tus proyectos, no es muy difícil, tu haces tu software olvidandote del WDT y una vez que veas que esta correcto y como tu quieres activas el WDT y lo refrescas una sola vez en el bucle while, no tiene mucho trabajo pero si muchos beneficios.
Un saludo
-
Ufff, yo tengo una experiencia de hace muchos años, que casi fué desastre por mal funcionamiento de un termostato digital programable. Aquello se reseteaba a los valores por omisión con nada.
Compré unos termostatos digitales, para controlar una estufa para cultivos biológicos, construí el aparato y puse unas muestras a cultivar. Total me tuve que ir de viaje y lo deje en marcha, termostato programado a la temperatura corporal para controlar un calefactor.
Cuando regrese, me contaron que casi se prende fuego la casa, aquello había empezado a echar humo y al ser el contenedor de madera, casí empieza a arder todo.
El termostato lo configure a la inversa, en reposo conectaba el calefactor y cuando superaba los 37 grados, lo desconectaba. El problema es que estos termostatos, no se porque, se reiniciaban ellos solos y perdían toda la configuración, dejando el calefactor permanentemente conectado. Probablemente al activarse el relé, la chispa provocaba un reseteo del termostato, perdiendo la configuración.
¿ El tiempo de refresco del Watchdog es algo que configura el usuario ?, es el único detalle que desconozco. Probaré a usarlo en el diseño de la ruleta.
-
¿ El tiempo de refresco del Watchdog es algo que configura el usuario ?, es el único detalle que desconozco. Probaré a usarlo en el diseño de la ruleta.
Si, es parecido a un timer, por ejemplo, si tu programa tarda en ejecutarse 100mS (por decir algo) pues tu calculas el WDT para 200 mS y al principio del while, por ejemplo, lo refrescas, si el while tarda mas de 200mS pues se reinicia.
En cuanto al termostado que comentas, cuando algo se puede reiniciar, las variables importantes deben estar guardadas en memoria no volatil, para que cuando se reinicie el programa continue por donde lo dejo.
Eso ya depende del proyecto, pero una buena forma de abordar un proyecto es hacerlo como una maquina de estados, cuando el micro arranca, ya sea por un reseteo automatico, manual o involuntario, que mire las variables de memoria y detecte en que estado se encuentra para continuar.
De esta manera si se queda en el estado 3 y se reinicia, continuara por el 3.
En el termostato, si se reiniciaba y empezaba calentando(estado1), no se si llegaba a enfriar(estado2) y se volvía a reiniciar y en vez de seguir en el estado2 seguia calentando, pues normal que casi saliera ardiendo :shock: :shock:
Es una conjetura de por que pudo ser, la verdad es que pudieron ser 1000 cosas.
un saludo
-
Solo mi experiencia .
Me arme una alarma casera con pic 16F84 por practicar y aprender.
Funciono sin problemas durante años y años con tormentas ruidos y vete a saber. Y a la perfección.
Pensé … si hago otro diseño con dspic30f4011 display, rs486 , teclado , Wavecom • The Wireless Experts ,, Asi me llama , sms y mas yerbas .y será la repera .
Pero nunca ha funcionado 100x100 . falsas alarmas , yo cenando el fin de año fuera de casa y corriendo por que se disparaba , por decir un ejemplo ya no os digo si estas de vacaciones a 2000km .
Con el wdt salvo un poco pero algo falla .
Menos mal que no es un marcapasos :D .
-
Ahora le agregas video Sispic, y te olvidas de correr a tu casa, lo revisas y lo desactivas desde distancia :P
-
Pero nunca ha funcionado 100x100 . falsas alarmas , yo cenando el fin de año fuera de casa y corriendo por que se disparaba , por decir un ejemplo ya no os digo si estas de vacaciones a 2000km .
Con el wdt salvo un poco pero algo falla .
Tengo la ligera impresión que programaste un detector de intensiones, para que de forma automática se dispare la alarma cuando alguien sospechoso pase por tu casa. Como cuando entras al supermercado y te suenan las alarmas, porque algún p@#$ de otro establecimiento no le quitó la etiqueta de seguridad a la ropa que compraste.
Como coloquialmente se dice: no es un error es una característica.
-
jajjaaa ..
seguire con el pic 16F84
:D
-
No me refería a un técnico, sino a cualquier persona.
Con resetear me refería precisamente a eso, quitar alimentación o pulsar el botón de reset.
Hay muchas circunstancias en las que es molesto o inadmisible que el responsable de la máquina tenga que pulsar el reset (por seguridad personal, por no estropear la máquina, por no estropear el producto, por no parar la producción o símplemente por comodidad)
Saludos.
-
jajjaaa ..
seguire con el pic 16F84
:D
Pero sin son más caros que los PIC18.
La única justificación que le veo a usar micros muy viejos, es que en el país de cada uno sea difícil conseguir otros micros mejores o los precios sean abusivos porque los importadores o el estado aplican tasas o impuestos desorbitados.
Aquí no hay limitaciones a la importación, y aplicando el truco de los 20€ te traes de todo sin pagar aranceles ni IVA.
Tengo un amigo en Portugal, que me comentó que antes allí podían hacer lo mismo, hasta que el Estado decidió poner en marcha medidas que impidieran hacer eso, y ahora los masacran en Aduanas. Me pidió si le podía yo hacer una compra a los chinos de unos paneles TFT, para luego enviárselo desde aquí a Portugal, y así se ahorró un pastón de Aduanas.
Hay gobiernos de países, que no se dan cuenta, que castigar la importación con tasas abusivas, solo sirve para anclar al país en la prehistoria, sobre todo a nivel tecnológico. Así no se protege el producto propio, lo que hay que hacer es fomentar la investigación, el desarrollo y la calidad para poder competir.