El código que desarrollé funciona con otro dispositivo i2c pero no con el sensor DLVR ( lo que demuestra que el código es bueno )
[Mi énfasis arriba.]
Para su información, la declaración subrayada anteriormente no es cierta. Esta es una falacia de solución de problemas común, porque asume que todos los dispositivos I²C se comportan de la misma manera.
Algunos esclavos I²C son más o menos tolerantes al comportamiento exacto de un maestro I²C. Es posible tener errores o limitaciones de software (o hardware) que solo afecten a algunos dispositivos, o que requieran una programación maestra I²C específica. Por lo tanto, su declaración de que su código ha demostrado ser bueno porque funciona un tipo de dispositivo I²C, es falsa . (Por supuesto, su código podría, de hecho, ser adecuado para ambos dispositivos, pero su prueba no demuestra eso).
¿Alguna idea de cómo solucionar este problema?
Hay muchas técnicas posibles, dependiendo de su equipo disponible, habilidades, experiencia, tiempo, dinero, etc.
Suponiendo que tiene un equipo de prueba adecuado, luego, utilizando un enfoque simplificado de ATS (solución de problemas analíticos) Kepner-Tregoe, tiene un par de "IS" (es decir, problema) / "NO ES" (no hay problema) muy agradable pruebas equivalentes:
ES (es decir, el caso de prueba muestra el problema)
utilizando un adaptador UM232H usb-i2c de FTDI no [...] pude comunicarme con el sensor DLVR.
NO ES (es decir, el caso de prueba no muestra ningún problema)
Puedo comunicarme con el mismo sensor DLVR usando el adaptador Aardvark.
[La metodología ATS, aunque es demasiado compleja de explicar en su totalidad aquí, incluye la comparación de pares de "IS" (es decir, is muestra una desviación del comportamiento correcto = problema) versus "NO ES" ( es decir, no muestra una desviación del comportamiento correcto = no hay problema) entre otras cosas.]
Así que reúna las trazas del osciloscopio (idealmente), o las trazas del analizador lógico (si no hay un osciloscopio disponible) de los casos de prueba "IS" (es decir, problema) y "NO ES" (es decir, no hay problema) y compare las huellas . Ese es un punto de partida.
Como una prueba funciona y la otra no funciona, entonces debe haber una o más diferencias en lo que sucede en el bus I²C, entre los dos casos de prueba.
¡Encuentra las diferencias!
Los siguientes pasos dependen de lo que encuentres ...
Tenga en cuenta que las trazas del analizador lógico no pueden mostrar algunos problemas eléctricos , y esto puede inducir a error en algunas situaciones. Al menos comenzar con un 'alcance' le permitirá confirmar y validar la forma de onda I²C (tiempos de subida / caída), niveles de voltaje (es decir, pull-ups para corregir el voltaje para los dispositivos en ese bus) etc. Si todo esto se confirma correcto, y el problema es definitivamente a nivel I²C protocol , en lugar de eléctrico , por lo que un analizador lógico puede ser lo suficientemente bueno para una solución de problemas adicional .