Forcer la communication I2C est-elle sécurisée?

Question

Pour un projet sur lequel je travaille, je dois parler à une puce multifonction via I2C. Je peux le faire depuis l'espace utilisateur de Linux via l'interface I2C/dev/i2c-1.

Cependant, il semble qu'un pilote parle à la même puce en même temps. Cela a pour conséquence que mes accès I2C_SLAVE échouent avec une valeur errno de EBUSY. Eh bien, je peux remplacer cela via l'ioctl I2C_SLAVE_FORCE. Je l'ai essayé et il fonctionne. Mes commandes atteignent la puce.

Question: Est-ce sécuritaire de le faire? Je sais avec certitude que les plages d'adresses que j'écris ne sont jamais accessibles par un pilote de noyau. Cependant, je ne suis pas sûr si forcer la communication I2C de cette façon peut confondre certains état-machine interne ou. (Je ne suis pas que en I2C, je l'utilise juste ...)

Pour référence, le matériel faits:

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

Answer 1

Je ne sais pas cette puce particulière, mais souvent vous avez des commandes qui nécessitent une séquence d'écriture, d'abord à une adresse pour définir un certain mode, vous lisez ou écrivez une autre adresse - où la fonction de la deuxième adresse change en fonction de ce que vous avez écrit au premier. Donc, si le pilote est au milieu d'une de ces opérations, et que vous l'interrompez (ou vice versa), vous avez une condition de concurrence qui sera difficile à déboguer. Pour une solution fiable, mieux communiquer via le pilote de la puce ...

Answer 2

Je suis surtout d'accord avec @Wim. Mais je voudrais ajouter que cela peut certainement causer des problèmes irréversibles, ou la destruction, selon l'appareil.

Je connais un Gyroscope (L3GD20) qui nécessite que vous n'écrivez pas à certains endroits. De la façon dont la puce est configurée, ces emplacements contiennent les paramètres du fabricant qui déterminent le fonctionnement et les performances du périphérique.

Cela peut sembler être un problème facile à éviter, mais si vous pensez au fonctionnement d'I2C, tous les octets sont transmis un bit à la fois. Si vous interrompez au milieu de la transmission d'un autre octet, les résultats peuvent non seulement être vraiment imprévisibles, mais ils peuvent également augmenter le risque de dommages permanents de façon exponentielle. Ceci est, bien sûr, entièrement à la puce sur la façon de gérer le problème. Comme les microcontrôleurs ont tendance à fonctionner à des vitesses beaucoup plus rapides que les vitesses de bus autorisées sur I2C, et que les vitesses de bus elles-mêmes sont dynamiques en fonction des vitesses de traitement des informations, le mieux est d'insérer des pauses transmissions qui attendent que les choses se terminent. Si vous le devez, vous pouvez même insérer un délai d'expiration. Si ces pauses ne fonctionnent pas, alors quelque chose ne va pas avec l'implémentation.