Bus I2C

[savignyexpress]

Bonjour à tous,

Pour mon nouveau projet en N, j'aurai certainement plusieurs microcontrôleurs: gare cachée, gare principale, alimentations tractions. C'est avant tout pour disposer de plus de broches et aussi pour séparer les fonctionnalités.

Ce nouveau réseau étant petit (1.2 m * 0.75 m), les liaisons seront courtes. Pour cette raison, je me demande si le bus TWI (two wires interface = I2C) ne ferait pas l'affaire. Il est intégré à la plupart des microcontrôleurs Atmel. Peut-être ferait-il l'affaire pour ce réseau.

J'aimerais vous soumettre les réflexions / questions suivantes:

• Le bus I2C n'a pas, contrairement au CAN, la notion de CRC en standard. Il serait opportun d'implanter CRC et quittance, même sur de courtes distances.
• Quelle méthodologie employer pour mettre au point une application multi microcontrôleurs communiquant entre eux ? Linux dispose d'outils logiciels pour simuler un maître / esclave, mais avec quel hardware ? J'imagine que la même question se poserait pour le CAN !

Le site instructables.com mentionne que I2C se trouve dans les interfaces entre cartes graphiques et écrans, c'est le display data channel (http://www.instructables.com/id/Worlds-Cheapest-I2C-I-Squared-C-Adapter/?ALLSTEPS), peut-être une voie à suivre !

Qu'en pensez-vous ?

Meilleures salutations.

Marc-Henri

[Pierre59]

Bonjour

J'utilise un bus I2C pour la communication entre les cartes électroniques de mon réseau. Toutes les cartes comportent un ATmega Atmel et sont proches les unes des autres. Je n'ai pas de problèmes de communications.

Pour communiquer avec le PC, j'ai un adaptateur USB I2C avec en circuit FTDI USB-parallèle et un ATmega8 pour l'I2C (fait maison). Mais je pense qu'un Arduino peut faire aussi l'affaire.

Pierre

[Jean-Luc]

Je dirais même CRC / acquittement et re-émission

Une architecture multicontrôleur pas trop compliquée est de faire un système avec un seul micro-contrôleur maitre, le contrôleur central, et une série de capteurs/actionneurs intelligents en réseau qui sont en quelque sorte des périphériques. Le contrôleur central envoie périodiquement à chaque actionneur une consigne. Vue du contrôleur ces consignes sont dans des variables et en tâche de fond ces variables sont envoyées sur le réseau. Chaque actionneur envoie périodiquement (CAN) ou est interrogé périodiquement (I2C) et fournie donc un état des capteurs. Vue du contrôleur les informations des capteurs sont des variables rafraichies périodiquement. L'avantage d'utiliser des variables rafraichies plutôt que des événements est la robustesse.

De cette manière tu évacues beaucoup de problèmes de concurrence et de partage de ressources.

Concernant l'interface I2C commandante par Linux : tu envisage de piloter le réseau via un PC ?

[savignyexpress]

...Concernant l'interface I2C commandante par Linux : tu envisage de piloter le réseau via un PC ?...

Bonjour Jean-Luc,

C'est bien à une architecture maître unique - multiple esclaves que je pensais.

L'interface I2C depuis Linux ne me servirait qu'à la mise au point des communications I2C. Je prèfère, de plus pour un petit réseau, ne pas avoir un PC pour commander le réseau.

Bonne fin de semaine & meilleures salutations.

Marc-Henri