I2C se vuelve loco al activar salida RB0 en PIC18F26J50

Hola.

En base a una experiencia reciente muy frustrante, quiero hacer una pequeña aportación a los que pretendan comunicarse vía I2C mediante un PIC18xxx.

Mi proyecto se comunica con un ISD5116 para reproducir frases grabadas, como único dispositivo conectado al PIC mediante I2C. Además consta de varios elementos más: Un acelerómetro, sensores de luz, temperatura, sonido, y algunos pulsadores. Todo lo programo en Assembler, y el código correspondiente al I2C está sacado del "Application Note" 976 de Microchip.

Durante el desarrollo, y después de tener probada y requeteprobada la comunicación I2C, de repente un día dejó de funcionar. El ISD5116 dejó de responder y ya no podía reproducir las frases. Lo peor de todo es que, después de reiniciar el PIC, quitar alimentación de toda la placa, asegurarme de tener descargados los condensadores, reprogramar el PIC... no era capaz de hacerlo reaccionar. Sólo cuando volvía a ponerlo en marcha al día siguiente parecía que se había solucionado: Funcionaba una vez, y después volvía a fallar.

No me llevó mucho tiempo averiguar que el problema surgía en el momento en que accionaba el puerto RB0, configurado como salida digital, y que utilizaba para despertar el acelerómetro (MMA7361L, pin \SLEEP).

Tuve que soltar el acelerómetro, e incluso dejar al aire la pata RB0 del PIC para cerciorarme de que, incluso en vacío, el I2C fallaba a partir de poner dicho puerto a 1.

Cambié condensadores, reformé varias partes del circuito (especialmente las pistas del I2C y sus pull-ups), revisé el programa de arriba abajo, me leí varias veces las páginas correspondientes del datasheet, probé varias configuraciones de interrupciones... y me sentí frustrado durante más de una semana al no dar con una solución.

Finalmente decidí probar si esto ocurría con cualquier otra salida. Reformé el circuito, configuré el puerto RB0 como entrada de uno de los pulsadores y el puerto RC6 como salida de \SLEEP del acelerómetro y... todo volvió a funcionar.

Realmente no tengo ni idea de qué es lo que provocaba el fallo, ni voy a perder más tiempo en averiguarlo. Al mismo tiempo que alabo los PIC por su versatilidad, por ser completísimos y por muchas cosas más, he de criticar lo enrevesado de su arquitectura y de su programación. A quienes piensen que la dificultad es inherente a la programación en assembler les recomiendo que vean el juego de instrucciones, modos de direccionamiento y registros de un MC68000. Es una maravilla. Todo funciona a la primera... o a la segunda si no vas muy fino con tu programa.

Bueno, pues esta es mi experiencia. Me gustaría que a alguien le sirviera para evitar llevarse los malos ratos que me he llevado yo.

Hasta luego.
 
Wow suena raro un "bug" como esos, suponiendo que es causa del hardware interno del PIC. ¿No has probado con algún otro PIC de esa serie?, el programa puede ser fácilmente transportado de un PIC a otro con similares caracterísitcas.
En realidad estos uControladores son muy versátiles pero no exentos de fallas... eso me recuerda el famoso error de division en el Intel Pentium...
 
¡Cierto! Yo también recuerdo el error del Pentium.

En mi caso, probablemente se trate de algo que no he tenido en cuenta o que no está convenientemente documentado, ya que la pata RB0 es también una entrada de interrupción. No obstante, deshabilité la interrupción correspondiente y el problema persistía.

No he probado con otros PIC porque lo mío es un proyecto personal y adquirí únicamente el PIC que iba a utilizar. Quizás habría sido bueno comprar más de uno por si acaso.

Gracias por tu respuesta.
 
Atrás
Arriba