Protocole I2c
Le protocole I2C (Inter-Integrated Circuit) est un protocole destiné à permettre à plusieurs circuits intégrés numériques “périphériques” (“puces”) de communiquer avec une ou plusieurs puces “contrôleurs”. Comme l’interface périphérique série (SPI), il n’est destiné qu’aux communications à courte distance au sein d’un seul dispositif. Comme les interfaces série asynchrones (telles que RS-232 ou UART), il ne nécessite que deux fils de signaux pour échanger des informations.
Comme les ports série sont asynchrones (aucune donnée d’horloge n’est transmise), les périphériques qui les utilisent doivent convenir à l’avance d’un débit de données. Les deux dispositifs doivent également avoir des horloges proches de la même fréquence, et qui le resteront – des différences excessives entre les fréquences d’horloge d’un côté ou de l’autre provoqueront des données brouillées.
Les ports série asynchrones nécessitent une surcharge matérielle – l’UART à chaque extrémité est relativement complexe et difficile à mettre en œuvre avec précision dans un logiciel si nécessaire. Au moins un bit de départ et un bit d’arrêt font partie de chaque trame de données, ce qui signifie que 10 bits de temps de transmission sont nécessaires pour chaque 8 bits de données envoyés, ce qui réduit le débit de données.
I2c arduino
La communication I2C fait partie intégrante de la conception des systèmes embarqués, en particulier pour les systèmes dont la priorité n’est pas d’atteindre des fréquences d’horloge très élevées. Il n’est donc pas surprenant que l’I2C soit largement utilisé dans les applications à faible vitesse et à faible coût. La technologie a été conçue pour la première fois en 1982 et malgré ses trois décennies d’existence, la popularité et les applications d’I2C n’ont pas diminué en nombre. Aujourd’hui encore, le protocole I2C équipe la grande majorité des systèmes embarqués d’entrée et de milieu de gamme, et il est probable que cette tendance se poursuivra dans un avenir proche.
L’énigme de la dénomination : Tout d’abord, jetons un peu de lumière sur le problème de terminologie dont souffre le protocole I2C. Dire qu’il s’agit d’un problème majeur serait exagéré. Néanmoins, il existe plusieurs terminologies associées à I2C, ce qui crée un certain degré de confusion lorsque quelqu’un lit ou entend parler de cette technologie pour la première fois. Vous trouverez peut-être un certain nombre d’ingénieurs, de professeurs et de techniciens qui préfèrent l’écrire comme I2C (prononcé I Squared C) à I2C. Dans le passé, IIC (prononcé double I C) était assez courant.
Exemple d’Arduino i2c
I2C (Inter-Integrated Circuit, eye-squared-C), également connu sous le nom de I2C ou IIC, est un bus de communication série synchrone, multi-contrôleur/multi-cible (contrôleur/cible), à commutation de paquets, à extrémité unique, inventé en 1982 par Philips Semiconductors. Il est largement utilisé pour relier des circuits intégrés périphériques à faible vitesse à des processeurs et des microcontrôleurs dans le cadre d’une communication intracarte à courte distance.
Plusieurs concurrents, tels que Siemens, NEC, Texas Instruments, STMicroelectronics, Motorola, [1] Nordic Semiconductor et Intersil, ont mis sur le marché des produits I2C compatibles depuis le milieu des années 1990.
Le Bus de gestion du système (SMBus), défini par Intel en 1995, est un sous-ensemble de I2C, définissant un usage plus strict. L’un des objectifs de SMBus est de promouvoir la robustesse et l’interopérabilité. En conséquence, les systèmes I2C modernes intègrent certaines politiques et règles du SMBus, supportant parfois à la fois l’I2C et le SMBus, ne nécessitant qu’une reconfiguration minimale par commande ou par utilisation de broches de sortie.
L’un des atouts particuliers de l’I2C est la capacité d’un microcontrôleur à contrôler un réseau de puces de périphériques avec seulement deux broches d’E/S à usage général et un logiciel. De nombreuses autres technologies de bus utilisées dans des applications similaires, comme le bus d’interface périphérique série (SPI), nécessitent davantage de broches et de signaux pour connecter plusieurs dispositifs.
Sda/scl arduino
À en juger par mes courriels, il est clair que le bus I2C peut être très déroutant pour le nouveau venu. J’ai beaucoup d’exemples sur l’utilisation du bus I2C sur le site web, mais beaucoup d’entre eux utilisent des contrôleurs de haut niveau et ne montrent pas les détails de ce qui se passe réellement sur le bus. Ce court article tente donc de démystifier le bus I2C, j’espère qu’il n’aura pas l’effet inverse !
Le bus I2C physiqueIl s’agit simplement de deux fils, appelés SCL et SDA. SCL est la ligne d’horloge. Elle est utilisée pour synchroniser tous les transferts de données sur le bus I2C. SDA est la ligne de données. Les lignes SCL et SDA sont connectées à tous les dispositifs sur le bus I2C. Il doit y avoir un troisième fil qui est juste la masse ou le 0 volt. Il peut également y avoir un fil de 5 volts si l’alimentation est distribuée aux dispositifs. Les deux lignes SCL et SDA sont des pilotes “open drain”. Cela signifie que la puce peut piloter sa sortie vers le bas, mais pas vers le haut. Pour que la ligne puisse passer à l’état haut, vous devez fournir des résistances d’excursion haute à l’alimentation 5v. Il doit y avoir une résistance entre la ligne SCL et la ligne 5v et une autre entre la ligne SDA et la ligne 5v. Vous n’avez besoin que d’un seul jeu de résistances pull-up pour l’ensemble du bus I2C, et non pour chaque dispositif, comme illustré ci-dessous :