Mensajes recientes

Páginas: 1 2 3 4 5 [6] 7 8 9 10
51
Lenguaje C para microcontroladores PIC / Re:nRF24L01+ y la @#$%&#@%&#@%& que me pasé probando.
« Último mensaje por osposto en 04 de Agosto de 2020, 12:07:34 »
Buenos días estimados sufrientes del nRF24L01+... :)
Logré como les indiqué en el post anterior que pude leer los registros del nRF hasta el momento. Pasa que tengo que intercomunicar una placa que tiene un PIC18F4620 (que es el que logré que funcione) y una placa Arduino Mega2650, que todavía no me puse a hurgar. Descargué las librerías para esta, está todo listo (en principio), pero como es ligeramente distinto a lo que es MPLABX, tengo que habituarme, y la verdad es que en estos días no me puse aún a meterle mano.
Aparte, estoy escribiendo una librería en MPLAB para esto, y resulta que cometí el error de borrar el programa inicial con el que conseguí leer los registros. Así que me encuentro nuevamente desc... hormigas, je....
Pero se mantiene lo que expuse antes, y apenas lo pueda poner en marcha, les comento nuevamente.
Saludos.
52
- Niple - / Re:Rotar bit en NIPLE
« Último mensaje por lennart en 04 de Agosto de 2020, 11:06:12 »
bueno  lo que se puede hacer es evaluar un bit(en este caso c) si sale 1 ir a la instruccion de rotar (izquierda o derecha) via registro declarado
53
Foro Técnico / Re:Sobrecalentamiento de chip MCP23S17 por sobreconsumo - Protegiendo GPIOs
« Último mensaje por genisuvi en 04 de Agosto de 2020, 04:57:35 »
Comento la situación actual:

Llevo varios días después de unos cambios mínimos en que ese conflicto ha dejado de suceder.

Ya que al parecer la tecnología CMOS es sensible a los sobrepicos de tensión (esto favorecería la polarización de uniones PN/NP que no deberían estarlo y se ponen a conducir) cambié la fuente de alimentación del chip. En vez de emplear los pines de 3.3V de mi Raspberry estoy usando una fuente externa regulada. También le cambié un condensador de 1uF por uno de 0.1uF. Pensé que 1uF al ser más grande absorbería mejor que el de 0.1uF los sobrepicos. Igual, no sé si esta diferencia de orden de magnitud realmente ha podido influir tanto en evitar el corto interno (teoría que tengo, lo mismo no es así).

Por otra parte, después de indagar sobre el tema y conocer un poquito más parece ser otra causa de este tiristor parásito son las ESD, descargas electroestáticas bastante propias de entornos de laboratorio donde hay humanos con cargas, haciendo masa con el suelo trasteando y toqueteando. A mí esta opción no me parecería descabellada.


Ahora mismo tengo el circuito escribiendo 0-1 en bucle y desde que:

1.- no lo toco,
2.- uso fuente externa
3.- y un condensador más pequeño


eso ya no me ha sucedido más.

Si se me dispara, encuentro que al final hay una teoría más acertada que esta o puedo validar esta de una forma más contrastada lo comentaré.

54
Foro Técnico / Re:Sobrecalentamiento de chip MCP23S17 por sobreconsumo - Protegiendo GPIOs
« Último mensaje por genisuvi en 04 de Agosto de 2020, 04:40:19 »
puede ser que se configuren en algún momento las e/s erróneamente.
Para ello asegurarse 'no sé si ya lo haces' es verificar siempre los valores escritos en el registro .

algo asi :
Código: C
  1. /*******************************************************************/
  2. void Write_Byte_MCP23S17_L(int8 Addr , data){  
  3. /*******************************************************************/
  4.  
  5. spi_write_L(Addr,data);
  6.  
  7. /* VERIFICA */
  8.  if (spi_read_L(Addr) != data){
  9.   /* reintentar x intentos y si falla resetear MCP23S17 configurar todo lo necesario*/
  10.  }
  11.  
  12. }

Sí, un compañero lee los registros con su código en cSharp. Son dos lenguajes distintos y tanto con Python como con cSharp ha estado pasando.
No obstante ahora os comento en el hilo un resumen de cómo tengo el tema ahora mismo y que creo que ya puedo ir cerrándolo.
55
Foro Técnico / Re:Sobrecalentamiento de chip MCP23S17 por sobreconsumo - Protegiendo GPIOs
« Último mensaje por genisuvi en 04 de Agosto de 2020, 04:38:08 »
Hola

No se si he entendido bien, pero eso de conectar salidas a entradas del circuito dependiendo como esten configuradas ¿no te puede estar provocando un corto? A mi me suena que en el curro para el amigo que trabajo tiene algun montaje con este circuito integrado en algun que otro pcb y lo ha usado para conmutaciones rapidas desde un software USB asi como para circuitos con cargas (creo que ataca mediante otra etapa de mosfet) y ha funcionado correctamente sin ningun problema de esos, se mantiene frio y sin consumo exagerado. Es para un sistema de debug que se reconfigura según la placa que se conecta (yo lo suelo usar para reparar algun equipo de otras compañias que cascan y lo desarrollo para hacer un chequeo ahorrando tiempo en reparaciones), tiene otra version con una fpga que hace mas funciones, pero han funcionado correctamente y no tiene diodos ni nada por el estilo, alguna resistencia si, pero no se si es para eso o que (no he mirado el esquema para saber si estan en los pines de I/O)

Tambien tiene otras placas con un micro similar de infineon, según el porque le gusta más esta marca para proyectos mas serios, por algo de ESD, por si te puede servir de referencia. Pero yo creo, según lo poco que se y lo que he visto con este integrado, que igual van por ahi los tiros, algun problema de reconfiguracion de las entradas/salidas.

Saludos !


Están bien configuradas, además como digo se pasa horas funcionando perfectamente. Y lo otro sólo pasa muy esporádicamente; basta una sola vez para que se me frían los chips de una placa.
Por otro lado, estoy convencida que se produce enclavamiento (latch up). Después de leer más literatura sobre ese concepto "latch up" que consiste en un tiristor "fantasma" (parásito) creo que eso es lo que internamente se forma en ese pin, porque le haces un reset y vuelve al estado original. Sin cambiar nada, ni una coma del código, ni cableado, lo arrancas y sigue funcionando como si nada. Pero cuando se dispara no cambias la situación hasta que haces reset o le suprimes la alimentación.

No obstante ahora voy a comentar algo en lo que puede ser el cierre de este tema. Llevo varias días con el circuito en marcha y no se me ha dado más la situación. Comentaré en el hilo los cambios que he hecho y la lógica que creo que tiene.
56
Foro Técnico / Re:Sobrecalentamiento de chip MCP23S17 por sobreconsumo - Protegiendo GPIOs
« Último mensaje por Sispic en 04 de Agosto de 2020, 03:31:09 »
puede ser que se configuren en algún momento las e/s erróneamente.
Para ello asegurarse 'no sé si ya lo haces' es verificar siempre los valores escritos en el registro .

algo asi :
Código: C
  1. /*******************************************************************/
  2. void Write_Byte_MCP23S17_L(int8 Addr , data){  
  3. /*******************************************************************/
  4.  
  5. spi_write_L(Addr,data);
  6.  
  7. /* VERIFICA */
  8.  if (spi_read_L(Addr) != data){
  9.   /* reintentar x intentos y si falla resetear MCP23S17 configurar todo lo necesario*/
  10.  }
  11.  
  12. }

57
- Niple - / Re:Rotar bit en NIPLE
« Último mensaje por sergito2269 en 04 de Agosto de 2020, 02:54:38 »
Muchas gracias !!!!!!!!
58
- Niple - / Re:Rotar bit en NIPLE
« Último mensaje por Fer_TACA en 04 de Agosto de 2020, 00:54:29 »
El bit de carry no se puede rotar. Su valor depende del resultado de una operación matemática.
Lo único que se puede realizar es comprobar su estado, si es 1 hago una cosa y si es 0 hago otra.
En nivel experto deberías tener la posibilidad de comprobar su estado dentro de la opción: condicion -> bit
F.
59
- Niple - / Re:Rotar bit en NIPLE
« Último mensaje por lennart en 03 de Agosto de 2020, 23:26:49 »
60
- Niple - / Re:Rotar bit en NIPLE
« Último mensaje por sergito2269 en 03 de Agosto de 2020, 21:40:14 »
El asunto es que estoy leyendo bits que desconozco si son "1" o "0" y necesito que ingresen al registro y a medida que ingresan roten
Páginas: 1 2 3 4 5 [6] 7 8 9 10
anything