... tant que les signaux d'activation pour les trois états s'excluent mutuellement ...

L'astuce consiste à faire cela sans ajouter un autre fil, ou plusieurs fils pour dire à chaque périphérique quand il est autorisé à piloter le bus.

Le principal avantage d'I2C est qu'il n'utilise que deux fils et deux broches sur chaque puce connectée au bus.

Si vous êtes prêt à échanger des broches contre de la vitesse, envisagez d'utiliser SPI, qui peut généralement atteindre une vitesse plus élevée que I2C, mais nécessite 3 ou 4 broches par appareil.

Il existe deux fonctionnalités spécifiques qui nécessitent des conduites à drain ouvert.Le premier est l'étirement d'horloge, où un esclave peut maintenir l'horloge (SCL) à un niveau bas pour retarder la transaction pendant qu'il traite les données.Le second est l'arbitrage multi-maître, où deux maîtres ou plus essaient de transmettre en même temps.L'arbitrage est effectué en faisant arrêter la transmission par un maître lorsqu'il voit la ligne de données maintenue au niveau bas par un autre maître.

L'arbitrage est le plus gros, je pense.Vous pourriez probablement remplacer l'horloge par quelque chose de basé sur un protocole, mais si vous voulez plusieurs maîtres sur le même bus, vous devez éviter les conflits.À moins que vous ne puissiez ajouter un autre fil, vous êtes coincé avec un drain ouvert.(Voir aussi: la couche physique CAN, qui utilise un schéma d'arbitrage similaire.)

tant que les signaux d'activation pour les trois états s'excluent mutuellement

Il n'y a aucun moyen de s'en assurer dans I2C.Vous auriez besoin d'un signal d'activation par appareil - vous avez maintenant inventé un cousin de SPI.

Les protocoles impliquant plusieurs périphériques communiquant sur un bus commun à l'aide de pilotes à trois états nécessitent généralement l'ajout d'un câble de contrôle externe pour éviter les conflits de bus ou des pilotes de limitation de courant pour éviter tout dommage en cas de conflit de bus. Alors que le niveau de courant de défaut que l'on peut tolérer en cas de conflit de bus peut être plus élevé que le niveau de courant que l'on pourrait tolérer à chaque fois qu'une ligne est basse, les pilotes bidirectionnels à courant limité sont plus compliqués que les pilotes à collecteur ouvert combinés avec des pull-ups passifs. .

Si l'on est prêt à accepter la dépense supplémentaire des pilotes actuellement limités, cela permettra de concevoir des protocoles plus rapides et plus robustes que I2C. D'autre part, l'ajout de pilotes actifs à un maître I2C peut permettre d'obtenir des avantages similaires même avec I2C. Pour obtenir de tels avantages en toute sécurité, il peut être nécessaire d'ajouter des résistances série sur la ligne SDA entre le maître et les esclaves, mais si l'on utilise une résistance séparée entre le maître et chaque esclave, la capacité du maître à conduire haut la ligne SDA comme le montre tout esclave qui ne le réduit pas activement peut permettre au maître de se remettre de scénarios qui pourraient autrement provoquer le verrouillage permanent du bus (aucun appareil ne peut maintenir SCL bas en continu pendant plus de 9 cycles de SCL, donc un maître serait capable de générer une condition d'arrêt pour n'importe quel appareil dans les 9 cycles, mais si deux appareils pouvaient chacun maintenir la ligne SCL vue l'un par l'autre, ils pourraient entrer dans un état où ils tiraient à tour de rôle vers le bas SCL de manière à ce qu'il ne jamais être libéré, laissant le maître incapable de générer une condition d'arrêt.

La VRAIE réponse à cette question, comme à la plupart des questions similaires, est que c'est ainsi qu'elle a été conçue.L'extension d'horloge, l'arbitrage de bus sont certainement valables, mais la solution est adéquate pour son objectif de conception, qui est une communication à faible vitesse à courte distance (souvent embarquée).

Il existe de nombreux protocoles plus récents et plus rapides, qui compensent une certaine complexité pour la vitesse et la distance.Si vous en avez besoin, utilisez l'un de ces protocoles.

Alors que I²C est un protocole relativement moderne (~ 1982), avant Tri-State ou TTL (~ 1963), les premiers circuits intégrés utilisaient RTL et l'open-collector était la conception de bus standard pour les premiers ordinateurs.(Et je pourrais ajouter un vrai défi aux concepteurs.)

Open drain est une forme de pilote d'état éprouvé.C'est nécessaire ici pour éviter les conflits de logique - l'esclave se tenant sur le bus par exemple.