Introduction
Le bus de communication I2C est souvent utilisé pour communiquer dans un périmètre restreint d'une carte ou de plusieurs cartes électroniques : voici une introduction au bus I2C pour en comprendre son mécanisme général. L'I2C c'est la solution de communication bas niveau "inside the box" ( dans la boîte ). Le nom I2C est l'abréviation pour bus de communication Inter - inter IC ( Integrated circuit ou circuit intégré ).
I2C pour Inter - Inter IC

L'I2C constitue le bon support pour la communication entre différents périphériques lents sur une même carte, qui sont consultés par intermittence, nécessitant peu de ressources matérielles pour être mis en oeuvre. Le bus I2C est simple, avec une bande passante faible et un protocole "courte distance". La plupart des circuits I2C disponibles fonctionnent à 400 Kbps et certains atteignent le MHz. Contrairement au bus SPI le bus I2C est un bus "half duplex" ou l'émission et la réception ne peuvent être simultanées. Il est facile d'utiliser l'I2C pour relier plusieurs périphériques suivant un schéma d'adressage intégré.

Philips à l'origine de l'I2C, à développé ce moyen de communication pour interconnecter à faible coût les différents sous ensembles des télévisions. Les circuits compatibles I2C sont nombreux sur le marché : EEproms, sondes thermiques, horloge temps réel + RAM, afficheurs etc ... L'I2C est également employé comme interface de commande aux dispositifs de traitement des signaux qui ont les interfaces séparées et spécifiques à l'application : mutimédia, tuner, encodeur / décodeur, processeur audio et vidéo. Philips, National Semiconductors, Xicor, Siemens et d'autres fabricants offrent des centaines de circuits compatibles I2C.
Dans la boîte

L'I2C est approprié pour connecter différents périphériques sur une même carte, et peut être étendu à travers plusieur cartes au sein d'un même système. Un exemple : un système de contrôle avec une carte unité centrale, qui utilise le bus I2C pour l'interface opérateur ( écran / clavier ). Un autre exemple : la SDRAM, qui peut comporter une EEprom I2C contenant les paramètres requis pour configurer correctement un contrôleur de mémoire dynamique.

Le bus I2C est un bus série synchrone à deux fils seulement. Il n'y a pas besoin de fils pour la sélection des périphériques ( comme SPI ) ou un système d'arbitration complexe, le rendant bon marché et simple à mettre en oeuvre au niveau matériel.
Les deux signaux I2C sont les données série ( SDA ) et l'horloge ( SCL ) ; ensemble ces signaux permettent de soutenir la transmission de données sur 8 bits, avec un adressage sur 7 bits et un bit de contrôle, sur seulement deux fils. Le circuit qui lance une transaction sur le bus I2C s'appelle le maître. Celui-ci commande normalement le signal d'horloge SCL. Le circuit adressé par le maître s'appelle l'esclave. Tout comme le bus SPI le bus I2C supporte le mode "multi-maîtres", mais la plupart des applications sont mono-maître. Il peut y avoir un ou plusieurs esclaves sur le bus. Le maître et les esclaves peuvent recevoir et transmettre des octets de données.

Chacun des circuits compatibles I2C à une adresse prédéfinie, dont les bits de poids faibles peuvent être configurables pour pouvoir adresser des circuits identiques sur le même bus. Le maître transmet l'adresse du circuit esclave au début de chaque échanges? Chaque esclave est responsable de surveiller le bus et de répondre seulement à sa propre adresse. Ce système d'adressage limite le nombre de circuits esclaves identiques qui peuvent co-exister sur un bus I2C sans conflits d'accès.


Communication
Le maître commence la communication en établissant une condition de départ ( start bit ). Le maître continu en envoyant les 7 bits d'adresse de l'esclave, avec le bit de poids fort ( MSB ) en premier ; le huitième bit suivant les 7 bits d'adresse ( bit R/W ), indique si l'esclave doit maintenant recevoir ( 0 ) ou transmettre ( 1 ). Cela est suivi d'un bit d'acquittement ( ACK ) publié par l'esclave en accusant réception de l'octet précédent ( adresse + R/W ).
Alors l'émetteur ( esclave ou maître ) transmet un octet de donnée en commençant toujours par le MSB. A la fin de cet octet, le récepteur de cet octet ( maître ou esclave ) publie un nouveau ACK. Ce modèle 9 bits ( octet + ACK ) est répété tant qu'il y a des données à transmettre.
Dans une transaction d'écriture ( réception esclave ), quand le maître a fini de transmettre tous les octets qu'il devait envoyer, il surveille le dernier ACK et déclare l'état d'arrêt ( P - stop condition ). Dans une transaction de lecture ( écriture esclave , le maître n'accuse pas réception du dernier octet qu'il reçoit : ceci indique à l'esclave que sa transmission est terminée. Le maître déclare alors l'état d'arrêt.


Un bus simple
Comme on viens de le voir, le protocole I2C fournit un adressage esclave, un bit de lecture / écriture et un mécanisme simple d'accusé réception ( ACK ). Il existe aussi quelques éléments suplémentaires au protocole I2C tels que la diffusion générale ( broadcast ) et l'adressage sur 10 bits au lieu de 7.
Les circuits I2C standards fonctionnent à 100 Kbps, les circuits plus rapides montent à 400 Kbps. Une révision de 1998 de la la norme I2C ( V 2.0 ) ajoute le mode haute vitesse qui peut atteindre 3,4 Mbps ; la plupart des circuits sur le marché fonctionnent à 400 Kbps.
Le plus souvent le maître I2C fait partie intégrante d'un microcontrôleur sous la forme d'un module d'interface contrôleur. On peut aussi implémenter le protocole I2C par logiciel, très simplement, en utilisant seulement 2 fils d'entrée / sortie pour SDA et SCL.
Conclusion

L'I2C offre une bonne solution d'interconnexion entre des périphériques sur une ou plusieurs cartes, avec des échanges occasionnels. L'avantage de l'I2C par rapport à ses concurrents ( SPI et Microwire ) est que le coût et la complexité ne croît pas en même temps que le nombre de circuits connectés au bus augmente.

Introduction
La plupart des applications embarquées à base de microcontrôleurs nécessites d'être entièrement autonomes ; en cas d'anomalie de fonctionnement du logiciel, il n'est pas concevable d'attendre indéfiniment qu'une intervention extérieure ré-initialise l'application. Si le logiciel est "planté", l'application reste suspendue dans un état instable, pouvant conduire à des disfonctionnements graves : erreurs et / ou perte de données, états incertains des entrées / sorties, défaillance des interfaces de périphériques etc .... Un chien de garde ou "Watchdog" est un dispositif permettant de détecter automatiquement les anomalies de fonctionnement du logiciel, et si nécessaire interrompre le fonctionnement du processeur pour forcer un RESET ou une interruption prioritaire.
Principe

Le chien de garde est un dispositif électronique associé à un un petit bout de logiciel, permettant sa gestion ; l'élément principal est un compteur ( timer ) qui décompte d'une valeur initiale jusqu'à zéro. Dans la pratique, le logiciel charge cette valeur à l'initialisation de l'application, puis périodiquement, il force le rechargement du compteur avec cette valeur, avant que celui-ci n'arrive à zéro. Si le compteur atteint zéro avant que le logiciel n'est eu le temps de ré-initialiser le chien de garde, le logiciel est présumé ne plus fonctionner correctement et le RESET du processeur est activé.
Pour la petite histoire, "Kicking the dog" est le terme anglo-saxon qui désigne l'action de ré-initialiser le chien de garde. Cette métaphore visuelle est comparée à une homme qui se fait attaqué par un chien méchant : en lui mettant des coups de pieds régulièrement le chien de va pas le mordre ! De façon similaire, si le logiciel ré-initialise le chien de garde régulièrement, il ne courra pas le risque d'être ré-initialisé par un RESET. L'analogie fait un peu rire, bien que violente au premier abord !


Chien de garde interne
Appelé aussi chien de garde "logiciel", c'est un dispositif que l'on trouve directement intégré dans la plupart des microcontrôleurs modernes, comme la famille MOTOROLA, du 8 au 32 bits. Dans tous les cas l'implémentation est similaire : un registre de contrôle permet de valider / dévalider le chien de garde, un autre registre permet de programmer la valeur initiale du compteur par rapport à la fréquence d'horloge de l'unité centrale, et enfin, un dernier registre qui permet de ré-initialiser le chien de garde périodiquement : l'écriture consécutive à la même adresse d'une séquence de code ( ex : 0x55AA ), permet de recharger le compteur avec la valeur initiale.
Dans le cas ou le compteur atteint zéro, l'action engagée par le chien de garde varie d'une implémentation à l'autre : RESET de l'unité centrale ( comme un RESET externe ) ou génération d'un interruption prioritaire ( au même titre qu'un RESET ) non masquable, disposant d'un vecteur d'interruption indépendant ; ce dernier laissant le choix de forcer un RESET, analyser la défaillance ou effectuer des opérations spéciales. Certains microcontrôleurs disposent d'un registre d'état spécial permettant d'identifier la source d'un RESET, et donc de savoir si un évènement de type chien de garde est arrivé.


Chien de garde externe
Ce dernier, bien que basé sur le même principe que le chien de garde interne, est moins flexible et il prend plus de place ! C'est le plus souvent un dispositif intégré dans un composant de type "superviseur", décliné sous des dizaines de références. Il dispose d'une entrée désignée par WDI ( Watchdog Input ) et d'une sortie désignée par WDO ( Watchdog Output ). La dévalidation du chien de garde est obtenue en laissant l'entrée WDI en l'air ; la programmation du "délai" peut être fixe ou programmable par une capacité ou par l'état de certaines entrées dédiées. L'entrée WDI est connectée à un un port de sortie du microcontrôleur, permettant au logiciel de ré-initialiser le chien de garde par des transitions 0>1 ou 1>0. La sortie WDO quand a elle est connectée au RESET ou à une entrée d'interruption non masquable (NMI). Si dans le principe le fonctionnement est le même, le chien de garde externe est beaucoup moins flexible que son homologue interne. On le réserve à des processeurs ne disposant pas de chien de garde interne ou pour des solutions sécurisés, en tandem.


Programmation
Souvent le chien de garde est mal employé réduisant sa fonction sécuritaire à néant. Les erreurs volontaires ou pas sont toujours les mêmes : pour ne pas être gêné par une éventuelle ré-initialisation du logiciel, le compteur est initialisé au maximum possible ( plusieurs secondes ) et la ré-initialisation du chien de garde est placée n'importe ou dans le logiciel. Cela amène à prendre en considération deux points importants :
Placement de la ré-initialisation du chien de garde.
Détermination de la valeur initiale du compteur.

Dans le cas du chien de garde interne la réinitialisation ne devrai être placée qu'une seule fois dans la boucle d'attente principale du programme ( ce n'est bien sûr pas toujours possible ) ; en aucun cas elle ne doit être placée dans une procédure d'interruption, qu'elle soit ou non périodique ; il faut éviter aussi les sous programmes et les procédures, pouvant être appelées par différentes parties du logiciel.
L'erreur la plus courante c'est une erreur de placement conduisant à un "arrêt dynamique" du logiciel, c'est à dire qu'une partie du programme est planté ( programme principal ) alors qu'une interruption périodique continue à ré-initialiser le chien de garde : l'application reste figée et le microcontrôleur n'est pas ré-initialisé .
L'analyse détaillée du fonctionnement dynamique du logiciel doit permettre d'établir les attentes, les traitements longs ou les boucles qui n'en finissent plus ! A partir de là il faut déterminer un délai maximum dans lequel doit "rentrer" l'occurrence du traitement le plus long du logiciel, puis placer la ré-initialisation du chien de garde aux endroits stratégiques ( le moins possible ! ).
Lors du développement d'un nouveau logiciel, il est préférable de dévalider le chien de garde jusqu'à ce que ce que le logiciel soit entièrement déverminé : bien assez des bugs à corriger, pas besoin de rajouter de RESET intempestifs durant cette phase.
Une bonne méthode consiste à placer le délai de ré-initialisation au maximum dans un premier temps, de faire fonctionner l'application au maximum de ses fonctionnalités et de vérifier si il n'y a pas d'intervention du chien de garde ; l'opération est répétée en diminuant à chaque fois le délai jusqu'à ce que un RESET forcé par le chien de garde soit détecté. Puis, il suffit de prendre le dernier délai programmé en ajoutant une marge de sécurité de 20 % environ.

Un grand pas est franchi avec le nouveau cœur ARM Cortex M3. En effet comment décrire cette petite révolution dans le monde des microcontrôleurs : un microcontrôleur 32 bits à 1 $ ! La mort des microcontrôleurs 8 bits ! 25 Dhrystone MIPS dans un boîtier SOIC 28 ! ….

Actuellement le marché des microcontrôleurs est dominé en volume, par les 8 bits : depuis leur introduction il y a 30 ans, ils sont partout, dans tous les secteurs, embarqués dans toutes les applications, enfouis dans notre quotidien. Leurs principaux avantages c’est un faible coût, une grande simplicité, une faible consommation et des performances en rapport avec l’application. En effet dans les 8 bits, pas de mémoire à cache à gérer, pas de gestion mémoire compliquée, pas de contrôleur d’interruptions sophistiqué, pas des centaines de registres à initialiser etc … Coté limitations, la première c’est la fragmentation du marché où aucune architecture ne sort vraiment du lot, contrairement aux 32 / 64 bits avec les architectures x86 ou ARM ; la deuxième limitation c’est un support allégé des langages évolués, du fait du jeu d’instructions, des modes d’adressage, de la gestion mémoire et des performances générales. Dans une grosse majorité d’applications 8 bits, c’est encore l’assembleur qui domine.

ARM, frappe fort avec cette nouvelle architecture Cortex M3, qui fourni les capacités d’un 32 bits au prix du 8 bits, avec une mémoire minimale, un boîtier faible coût avec peu de broches et une faible consommation. Contrairement à la tendance générale qui veut l’intégration de millions de transistors, ARM à réduit au minimum le nombre de transistors afin de diminuer la surface du silicium, la consommation et le coût de fabrication ( process 0,35 µ à 0,25 µ ). Avec tout juste 33.000 transistors, le cœur Cortex M3 n’en développe pas moins de 1,25 Dhrystone MIPS par MHz. Bien connu des cœurs ARM, la compression de code ou mode « Thumb » n’est pas une option : Cortex M3 exécute uniquement un jeu d’instructions en mode Thumb-2, codées sur 16 bits. Cela permet de réduire fortement le code exécutable compilé. On y trouve aussi de puissants moyens de calcul comme la multiplication / division câblée sur un cycle, le support des accès mémoire non alignés [ lire article ] ou encore la manipulation de bits par la technique du « bit-banding ». Autre caractéristique du Cortex M3 c’est son orientation déterministe et temps réel : sauvegarde automatique des registres sur interruption, préemption sur priorité, enchaînement des interruptions ( tail-chaining ) sans dépilage / empilage des registres, autant d’outils permettant de booster n’importe quelle application. Un peu DSP, beaucoup 32 bits et plus du tout 8 bits, tel est le cœur Cortex M3 : équipé d'une architecture ARMv7-M ( Harvard ) contre une architecture ARMv4T Von Neumann sur un ARM7TDMI,  le M3 est plus performant et consomme moins qu'un ARM7TDMI !

Actuellement seule la société Luminary Micro propose des microcontrôleurs monochip basés sur le cœur Cortex M3 ( famille Stellaris ) : déclinés en 4 groupes ( séries 100, 300, 600 et 800 ) proposés en boîtier SIOC 28 ou SOIC 48, avec 8 à 64 Ko de Flash et 2 à 8 Ko de Sram, on retrouve aussi différentes interfaces classiques telles que : GPIO, UART, Timers, I2C, ADC etc … avec des fréquences allant jusqu’à 50 MHz. Cœur 32 bits ARM oblige on retrouve une interface JTAG pour le debug et la programmation. Le prix d’appel de la première référence ( LM3S101 ) est déconcertant : seulement 1 $ pour 10.000 pièces. A ce prix là et au vu des performances les concurrents sont loin derrière !

Des secteurs tel que la robotique [ lire article ] sont dans l’attente de ce type de révolution pour exploser, où puissance et faible coût sont les moteurs : des quelques MHz et Ko des début de la micro-informatique, nous sommes bien arrivé à des GHz, des Go, avec des coûts qui n’ont cessés de baisser [ lire article ] !

Tags : ARM Cortex M3 - Luminary MICRO - Famille Stellaris