Mensajes recientes

Páginas: 1 2 3 4 5 6 7 8 9 [10]
91
Lo primero, activa Brown Out Reset, desde los fuses.  Eso hará reset cuando el voltaje caiga por debajo de un umbral razonable.

Seguidamente puedes usar el Wathdog.  Tienes que ir reseteandolo periódicamente, así el pic sabe que el programa está vivo y corre. Si dejas de resetearlo y vence el tiempo se produce un reset.

   Pero eso son dos “parches” para actuar cuando pase el marrón.

  Lo ideal es evitar que suceda, para ello tienes que proveer al pic de todo cuanto necesite para evitarlo físicamente, como es, colocar condensadores de desacople, electroliticos que garanticen ausencia de rizado y transitorios, chokes, placas con planos de tierra en torno al procesador, etc...    si te pasa eso por un simple amago de apagón es por que estás muy corto de condensadores electroliticos.

   También , si lo que manejan los puertos son cargas inductivas hay que hacer unas cuantas cosas más.

   Y cuidado con el pin Máster Clear.   Resistencia pullup 4k7 a vdd y nada más, evita colocar ahí un pulsador para hacer función de reset, y si lo haces, que el pulsador esté lo más cerca posible del pin.


 

  Saludos.
92
Hola, activa el WDT.
93
Todo en microcontroladores PIC / En los cortes de energía se bloquea el pic, puede corregirse?
« Último mensaje por johenrod en 28 de Julio de 2020, 19:02:40 »
cordial saludo, tengo un pic 16f628a leyendo 4 pulsadores y activando 4 salidas, me ha sucedido que al producirse en zag (corte instantáneo de energía del suministro publico) el pic se cuega y no trabaja mas , para solucionar esto debo desconectar el suministro del pic y conectarlo nuevamente para que se reactive el pic.

hay algún registro que detecte esto y arranque solo cuando se cuelga?.
gracias de antemano.
94
Foro Técnico / Re:Sobrecalentamiento de chip MCP23S17 por sobreconsumo - Protegiendo GPIOs
« Último mensaje por genisuvi en 28 de Julio de 2020, 17:37:54 »
Definitivamente, el comportamiento que obtienes no es normal.
Es posible que exista algún problema con el código, ya que para que se caliente de esa manera, es porque se está creando un corto circuito que eleva la corriente y por eso el calentamiento.
Ya que si estuvieras activando todas las entradas al mismo tiempo a 0, y si estas tienen el pull-upo interno activado, la corriente que circula por cada entrada es extremadamente pequeña:

I = 3.3/100K = 33uA!!!
Si activas las 8, entonces sería 33uA x 8 = 264uA!!!! Eso no calentaría para nada al MCP23S017, por lo que estoy casi seguro que de alguna manera estás generando un corto. Y esto puede ser porque en tu código estés configurando el puerto de entrada como salida en un periodo de tiempo pequeño y eso obviamente alestar conectado a GND, estarías generando un corto por un periodo de tiempo pequeño, pero si este se hace oscilatorio, entonces de ahí la razón del problema.

Sería bueno que publicaras tu código de prueba para echarle una mirada.

elreypic.

Muchas gracias por tu atención y aportación @elreypic2, sí ya sé que no debería calentarse ni mucho menos estar al punto de arder como Roma; quema cuando se dispara "lo que sea" que lo haga entrar en ese estado. Es más tenemos la fuente de la Rasp conectada a un dispositivo de estos que te muestra por display el consumo en watts y cuando esto sucede pasa de marcar 3.2Watts a 6watts! Así que hay un consumo destructible y anormal, un corto he pensado yo también. También, cuando eso ocurre, si mido en los pines de tensión de la Rasp que alimentan al chip hay una caída de 3.3V a 2.8V. Antes de que se me chamusque lo reseteo rápido.

Tengo que decir que yo arranco el programa y puede estar 2, 3, 4 horas seguidas y más funcionando sin problemas, con el mismo código que no es más que un loop que sólo lee un puerto y escribe por otro, básicamente. Usamos una librería de python así que el código que he escrito es de más alto nivel de abstracción. Donde llamo a funciones de inicialización (configura el control de los chips y las direcciones de los pines), otras 2 funciones; una de leer puerto y otra de escribir puerto disponibles en dicha librería. Pero de repente, se da esta situación. Algo dispara este sobreconsumo y no sabemos detectar qué es. Lo que hacemos es conectar algunas entradas a estas salidas que escriben '0' y vamos viendo (mostramos por pantalla) cómo va cambiando el valor del registro de 8 bits conforme va cambiando el '1' (de estar las entradas al aire con la Rpull up) por un '0'.

Intentando replicar el problema me pareció que se me disparó dos veces al momento de inyectar un hilo desde la salida en la fila del pin de la entrada. Al hacer la conexión, se producen rebotes hasta que se estabiliza el valor '0' de dicho pin. Hago reset y con el cable en la misma posición que tenía cuando se disparó el sobreconsumo al volver a ejecutar el sw de control, todo sigue OK. Funciona por horas correcto. Tampoco me parece normal que se dispare un cortocircuito en el driver del pin a causa del switching '1<-->0' de los rebotes. Digo yo que una entrada GPIO estará hecha para recibir un tren de pulsos, pulsos variados, formas típicas en un sinfín de aplicaciones (sensores, timers, interrupciones, etc) a menos que la arquitectura interna sea tan diferente (cosa que desconozco) entre los de estos chips y los GPIOs de cualquier uC/CI basado en tecnología CMOS.

Otro dato de interés -que a mí me haría pensar que el problema pueda no estar en el código- es que un compañero detectó el mismo recalentamiento, habiendo programado el control del sw con csharp; un código que leía lo que escribía por los pines de salida. Tampoco sabe decir si algo muy concreto lo disparaba; pero lo mismo: todo iba bien hasta que de repente se sobrecalentaba y disparaba el consumo. Reseteaba y vuelta a la normalidad por horas.

No te pongo mi código en python porque no estoy en el ordenador de la oficina y no tengo acceso ahora a él. Pero a mi regreso lo compartiré.

En lo que me insisten varias voces es que parece que se me esté dando el fenómeno del "latch up" por ESDs. Se forma una especie de tiristor parásito que deja a las dos uniones PNNP en conducción montando un corto y ya no lo desactivas a menos que apagues el chip o resetees. Y me comentan que debería proteger mis entradas frente a ese fenómeno. Me extraña de nuevo que las GPIO en modo entrada tengan esa posibilidad con el peligro de destrucción que supone. Sin embargo no veo este tipo de protecciones en otros proyectos similares. Como te digo no he visto más protección que Rs en serie en algunas GPIOs y sólo por si a caso alguien configura una salida como entrada si tiene conectados elementos para entradas tales como pulsadores, etc.
.
Así que no sé. La librería es Pi_MCP23S17.py -->https://github.com/jebentancour/Pi_MCP23S17
95
* PROYECTOS * / Re:Mini PC desarrollada con lógica discreta
« Último mensaje por Robert76 en 28 de Julio de 2020, 16:23:16 »
Gracias compañero!
En la brevedad subo un vídeo de la placa controladora de teclado PS2.
Que además puede ser útil para cualquier aplicación dónde requiere teclado.
96
Foro Técnico / Re:Duda alimentación FT232RL
« Último mensaje por PicMinor en 28 de Julio de 2020, 15:01:32 »
Muchas gracias KILLERJC!

Efectivamente, mi caso es el tercero. Ya veo cómo hacerlo. Gracias de nuevo!
97
Foro Técnico / Re:Sobrecalentamiento de chip MCP23S17 por sobreconsumo - Protegiendo GPIOs
« Último mensaje por elreypic2 en 28 de Julio de 2020, 10:35:37 »
Definitivamente, el comportamiento que obtienes no es normal.
Es posible que exista algún problema con el código, ya que para que se caliente de esa manera, es porque se está creando un corto circuito que eleva la corriente y por eso el calentamiento.
Ya que si estuvieras activando todas las entradas al mismo tiempo a 0, y si estas tienen el pull-upo interno activado, la corriente que circula por cada entrada es extremadamente pequeña:

I = 3.3/100K = 33uA!!!
Si activas las 8, entonces sería 33uA x 8 = 264uA!!!! Eso no calentaría para nada al MCP23S017, por lo que estoy casi seguro que de alguna manera estás generando un corto. Y esto puede ser porque en tu código estés configurando el puerto de entrada como salida en un periodo de tiempo pequeño y eso obviamente alestar conectado a GND, estarías generando un corto por un periodo de tiempo pequeño, pero si este se hace oscilatorio, entonces de ahí la razón del problema.

Sería bueno que publicaras tu código de prueba para echarle una mirada.

elreypic.
98
* PROYECTOS * / Re:Mini PC desarrollada con lógica discreta
« Último mensaje por Leon Pic en 28 de Julio de 2020, 09:32:49 »
Muy buen proyecto.  ((:-)) ((:-))
99
Foro Técnico / Sobrecalentamiento de chip MCP23S17 por sobreconsumo - Protegiendo GPIOs
« Último mensaje por genisuvi en 28 de Julio de 2020, 04:49:51 »
Buenos días,

Llevo unos días probando escrituras y lecturas de ese chip mediante un test de estrés que me he montado con python en una Raspberry 3. La idea es desarrollar una PCB con hasta 8 chips (Lo que permite su direccionamiento) de estos. El circuito lo tengo montado en una proto y es una versión básica con un único chip. Estoy poniendo a prueba el montaje más sencillo: 1 chip (clk spi funcionando a 1Mhz). Cabe decir que estoy tomando los 3.3V de los pines VDD de la Raspberry puesto que con un único chip el consumo no es prohibitivo.

EL test de python consiste en:
1.- configurar un banco como salidas y el otro como entradas con Rpull up habilitada.
2.- Las salidas escribirán siempre '0', nunca '1'.
3.- De entre todas las entradas algunas puede que estén directamente conectadas a alguna/s salida/s o bien no estar conectadas a nada, con lo cual leerán '0' o bien '1' (si están fotando/al aire).
4.- Las entradas también podrían estar durante la ejecución leyendo un contacto a GND (imaginad un usuario llevando una especie de "sonda" que lleva GND a las entradas GPIOs) o bien también puede ser un punto fijo (nadie lo cambia de posición) que está GND.

Ahora he probado qué tal se comporta en una proto teniendo 8 bits del chip de para entradas y otros 8 para salidas. Con un hilo a GND llevo GND a una de las entradas y con otros hilos juego a cerrar circuito conectando una entrada y una salida (con lo cual leería '0').

Problema:

Todo va perfecto hasta que ocurre que se dispara el consumo y se me calienta al punto de tocarlo y escaldarte. Le queda poco para quemarse. La cosa se resuelve si inmediatamente reseteo el chip. Levanto el pin de reset y se acabó. Luego vuelvo a arrancar y sigue leyendo bien sin recalentarse ni consumir fuera de lo habitual.



He consultado este tema y existe literatura que hace hincapié en estas posibles causas:

 * el switching en tecnología CMOS, en las que la prolongación en tiempo de un switcheo 0<->1 puede provocar enclavamientos y picos de corriente destructivos porque permanecería demasiado tiempo los dos transistores del inversor conduciendo. Esta es una de las principales causas del sobrecalentamiento indeseado. Por otro lado, pienso que leer "0-1" de forma prolongada -imaginad leer un tren de pulsos, palabras binarias de un bus- no puede ser que eso dañe un dispositivo por recibir en un pin '1' y '0' durante un tiempo no muy extenso, y, lo mismo, si así es no sé cómo protegen, de esto, a ese pin los diseñadores.


 * Diferencias o caídas de tensión diferentes puntos de GND --> no sé si tener hilos desde la Rasp hasta la proto afectaría mucho a eso.

 * Que esté llevando una tensión para Vih muy superior a VDD --> cosa imposible porque es el mismo chip el que escribe vih y escribe 3.3V. Igualmente no escribimos Vih, sino ViL siempre.

 * También hubo quien me sugirió también que una posible causa de este comportamiento podría ser "latch up" por ESD (un tiristor parásito) por el hecho que se arreglase al resetear el chip:

https://es.wikipedia.org/wiki/Enclavamiento_(electr%C3%B3nica) --> Pero no sé cómo protegerlas de ese fenómeno. Y me extraña ser la única a la que pase esto con tantos ejemplos de uso de este chip y conectándolo a circuitos más complejos. Nunca me había pasado esto.



Sugerencias de solución:

La gente me sugiere proteger con condensadores, Rs y diodos estas GPIOs; pero digo yo, no es exagerado meter en cada una de mis 64 GPIOs diodos, C y Rs? Más que nada porque no he visto ningún ejemplo de circuito que proteja así sus GPIOs (ni en MCUs ni en este chip en concreto), como mucho una R por si conectan por error una salida a un pulsador .

Yo no he visto esto ni con diodos, ni con condensadores y muchas veces ni si quiera Rs. Me gustaría saber cómo se suele proteger de una forma eficaz y eficiente las GPIOs. El circuito es muy sencillo, lo único es que tiene 64 puntos y se comunican con Rasp por SPI. Pero las GPIOs las usaré para cerrar circuito entre salida-entrada o las dejaré abiertas y leeré. No hay mucho más.

También me recomendaron usar Rs de 10K a las salidas y a las entradas. Yo lo he probado parece que no ha disparado el sobrecalentamiento (por ahora). Es cierto que estoy conectando y desconectando hilos durante la ejecución. Será ese el problema? Quizás los diseñadores no pongan condensadores ni diodos por que dan por hecho que no necesitarán proteger porque ven poco riesgo de cometer ciertos errores, o no conectarán cosas estando en marcha una ejecución, etc. Pero estos dispositivos que uso mantienen sus estados aunque se pare la ejecución. Y aunque un usuario no cambie conexiones de hilos hasta que no finalice la ejecución tengo miedo que esos cambios de hilos despierten a la fiera y se se achicharren las placas.


Sigo buscando ejemplos de circuitos con GPIO protegidas con diodos y condensadores para ver si me ilumino.

Agradecería si alguien me comparte su experiencia tratando GPIOs y protegiéndolas o bien sobre el tema de recalentamiento por sobreconsumo de este chip. Cualquier añadido será útil!
Gracias de antemano.



100
Almacén del Assembler / puntero en assembly CCS Compiler
« Último mensaje por tito melli en 28 de Julio de 2020, 03:13:50 »
Hola!

tengo un código de MPLAB en ensamblador que usa punteros. He intentado usarlo en CCS Compiler pero el dsPIC se reinicia y el debugger y el CCS se quedan bloqueados al pasar por este punto.

Sabéis cómo se hacen los punteros en CCS Compiler een ensamblador?

Concretamente la parte del codigo es esta:

Código: [Seleccionar]
#define Work1W        w1       // Working registers
#define ParkParmW    w7

mov      ParkParm+Park_qAngle,ParkParmW
mov      [ParkParmW++],Work1W

"ParkParm+Park_qAngle" es una variable de una estructura previamente definida

Gracias de antemano!

Saludos
Páginas: 1 2 3 4 5 6 7 8 9 [10]
anything