Forçar a comunicação I2C é seguro?

Question

Para um projeto em que estou trabalhando, preciso conversar com um chip multifuncional via I2C.Posso fazer isso no espaço do usuário do Linux por meio da interface I2C/dev/i2c-1.

No entanto, parece que um driver está conversando com o mesmo chip ao mesmo tempo.Isso faz com que meus acessos I2C_SLAVE falhem com um valor errno de EBUSY.Bem, posso substituir isso por meio do ioctl I2C_SLAVE_FORCE.Eu tentei e funciona.Meus comandos chegam ao chip.

Pergunta:É seguro fazer isso?Tenho certeza de que os intervalos de endereços que escrevo nunca são acessados ​​por nenhum driver de kernel.No entanto, não tenho certeza se forçar a comunicação I2C dessa forma pode confundir alguma máquina de estado interna ou algo assim. que em I2C, eu apenas uso...)

Para referência, os fatos de hardware:

 OS:           Linux
 Architecture: TI OMAP3 3530
 I2C-Chip:     TWL4030 (does power, audio, usb and lots of other things..)

Answer 1

Não conheço esse chip em particular, mas muitas vezes você tem comandos que exigem uma sequência de gravações, primeiro a um endereço para definir um determinado modo, depois você leia ou escreve outro endereço - onde a função do segundo endereço alterações com base em O que você escreveu para o primeiro. Portanto, se o motorista estiver no meio de uma dessas operações e você o interrompe (ou vice -versa), você terá uma condição de corrida que será difícil de depurar. Para uma solução confiável, é melhor você se comunicar através do motorista do chip ...

Answer 2

Concordo principalmente com @Wim.Mas gostaria de acrescentar que isso pode definitivamente causar problemas irreversíveis, ou destruição, dependendo do dispositivo.

Conheço um giroscópio (L3GD20) que exige que você não escreva em determinados locais.Da forma como o chip é configurado, esses locais contêm configurações do fabricante que determinam como o dispositivo funciona e funciona.

Isso pode parecer um problema fácil de evitar, mas se você pensar em como funciona o I2C, todos os bytes são passados ​​um bit de cada vez.Se você interromper no meio da transmissão de outro byte, os resultados podem não apenas ser verdadeiramente imprevisíveis, mas também podem aumentar exponencialmente o risco de danos permanentes.É claro que isso depende inteiramente do chip sobre como lidar com o problema.

Como os microcontroladores tendem a operar em velocidades muito mais rápidas do que as velocidades do barramento permitidas no I2C, e como as próprias velocidades do barramento são dinâmicas com base nas velocidades nas quais os dispositivos processam as informações, a melhor aposta é inserir pausas ou loops entre as transmissões que aguardam. coisas para terminar.Se for necessário, você pode até inserir um tempo limite.Se essas pausas não funcionarem, algo está errado com a implementação.