Cet article est le premier d’une série à décrire les «meilleurs» aspects du protocole I2C développé à l’origine par Philips.
Puisque vous lisez cette série, je suppose que vous connaissez déjà le bus I2C et que vous souhaitez éviter la douleur lorsque vous devez l’utiliser dans un projet. Si c’est le cas, vous êtes au bon endroit. Sinon, je vais bientôt ajouter les informations I2C dans le préambule à mon site Web bientôt.
Juste pour être clair, cet ensemble n’inclut pas la couverture en mode rapide, car cela diffère considérablement de la conception et du comportement d’une implémentation de bus partagé à 2 fils normale, et il n’est pas couramment utilisé. Il existe une abondance d’excellents documents de référence sur Internet couvrant cet espace.
Voici une liste rapide de ce que couvrent les autres séries:
- START est manquant
- STOP manquant
- START répétée
- bits de données manquants
- ACK / NAK manquant
- informations après NAK
- erreurs réciproques
- résistances
- väylätoistimet
- mise en œuvre à l’aide d’un périphérique TWI ou I2C à part entière
- mise en œuvre à l’aide d’un périphérique USI
- mise en œuvre à l’aide d’un périphérique USART
- Différences entre SMBus et I2C
Maintenant pour les bonnes choses!
Cet article se concentre sur les 3 types d’implémentations que vous pouvez trouver dans les modèles aujourd’hui: matériel complet, mix matériel / logiciel et logiciel complet (ou «bit-bang» comme on l’appelle parfois).
De nombreux microcontrôleurs modernes, même certains appareils haut de gamme, incluent un périphérique I2C entièrement matériel. Atmel les appelle TWI, Microchip les appelle I2C; d’autres fournisseurs utilisent des noms similaires. Lorsque vous utilisez une approche entièrement matérielle, il est vraiment difficile de créer tout type d’erreur de bus à moins que vous ne compreniez mal le fonctionnement du périphérique ou à quoi devrait ressembler la séquence de bus I2C correcte. En général, cependant, cette approche nécessite la compréhension la moins approfondie du protocole lui-même.
Le périphérique USI présent dans certains appareils Atmel est un matériel minimal qui dépend de l’interaction logicielle pour le compléter. Ce périphérique polyvalent peut en fait être utilisé dans les configurations I2C, SPI et UART, et convient aux appareils haut de gamme où l’ajout des trois périphériques serait rentable. Bien qu’il nécessite plus d’encodage que TWI ou un périphérique I2C complet, il est un peu plus flexible. Cette approche nécessite une compréhension plus approfondie du protocole car vous êtes responsable du passage d’un état à un autre, et il est possible d’aller dans la mauvaise direction.
Enfin, la mise en œuvre d’une approche 100% logicielle nécessite une parfaite compréhension du protocole I2C. Presque tous les fournisseurs de microcontrôleurs fournissent des instructions d’application et des exemples de code pour créer un maître I2C à l’aide d’un logiciel propre. Contrairement à UART, I2C est un protocole cadencé (plutôt que planifié), donc les interruptions dans la mise en œuvre du protocole sont bien tolérées, permettant aux interruptions d’être réparées sans se soucier de la perte de données. La vitesse maximale d’une solution logicielle est finalement déterminée par la vitesse d’horloge du processeur et, en général, une implémentation Master peut facilement atteindre une vitesse de 400 KHz.
La mise en œuvre logicielle d’un périphérique esclave est beaucoup plus difficile. Sans prise en charge matérielle, le logiciel doit surveiller simultanément les lignes SDA et SCL pour détecter les fronts d’horloge et reconnaître positivement l’état de la ligne SDA avant que le SCL ne monte ou descende. La détection de l’état START ou STOP nécessite généralement des interruptions, sinon le logiciel devrait consommer 100% sous surveillance SCL et SDA. Les implémentations esclaves basées sur le logiciel sont généralement liées au processeur, ce qui nécessite plusieurs valeurs MIPS pour atteindre des performances jusqu’à 100 KHz. Par conséquent, de véritables implémentations esclaves uniquement logicielles peuvent même ne pas exister pour certaines familles de microcontrôleurs, et d’autres peuvent ne pas être en mesure d’atteindre une vitesse de bus de 100 KHz.
Une fois cette base matérielle et logicielle configurée, nous approfondirons le protocole lui-même dans notre prochain article. Merci d’avoir lu!
(Copyright 2010 Robert G. Fries)
[amazon bestseller= »peripherals » items= »3″ ]