Yep!
osaka:
Par contre tu pourras peut être me renseigné sur la réel différence entre les tiny et atmega, avantage, inconvénient ?
ATtiny2313, 2048 bytes, DIP20
ATtiny4313, 4096 bytes, DIP20
ATTiny25/45/85 2048, 4096, 8168 bytes, DIP8
Cà c'est pour ceux que je connais. Il y a aussi des modèles CAN bus.
Naturellement, on ne retrouvera pas toutes les fonctionnalités des mega, principalement du côté des ports analogiques, sur les tiny, je n'en connais pas. L'I2C est aussi sacrifié, mais il demeure le TWI, avec donc, des possibilité quand même.
Pour le tiny2313, 18 i/o brutes dont Rx/Tx, 4 Pwm, l'horloge, etc. Quand on fait les comptes, il demeure grosso modo 10/12 i/o. C'est déjà pas mal.
Le principal inconvénient, c'est bien entendu l'absence de port analogique. Pour inclure des capteurs de cette famille, pas le choix faut serialiser à travers un chip ou bidouillé sur les temps de charge/decharge d'une capa.
En ce qui concerne les tiny25/45/85, peut de i/o à la base mais on peut compenser avec des shifts register.
osaka:
J'aimerai connaître le résultat de tes expérimentations , compte rendu obligatoire
Pas de souci, par contre faudra être patient, j'ai un truc sur le feu pour l'instant XD
Pour détailler un peu, je compte mettre un afficheur tactile et l'ethernet sur un chip mega644 (taches lentes), quant au second 644, les tâches courantes, gestion des évenements capteurs et envoie des commandes asservies. Le tout en intercommunication.
J'espère avec cette configuration obtenir plus de réactivité sur les interfaces IHM.
Le protocole I2C est utilisé dans des projets tels que core2duino ou core3duino.
Je n'ai pas encore fixé mon choix sur le chip des modules de commandes, l'attiny2313 a ma préference pour l'instant, mais il va falloir que je m'affranchisse de l'analogique et que je palie ce problème.
Je suis plutôt satisfait de ma solution actuelle à base de mega1280 + afficheur tactile + ds18b20 + relais piloté en rs485.
Je crains pourtant en ajoutant l'ethernet et des sondes supplémentaires d'être rapidement saturé en i/o et en vitesse de calcul.
Les avantages que j'entrevois dans ma solution est d'obtenir théoriquement deux fois plus d'entrée/sortie avec la même taille mémoire. (robotique ???)
Le plus chaud sera de partager les tâches équitablement. (l'option du clustering n'est pas loin!)
L'idée de déporter les modules de commandes me plait de plus en plus 
@+
Zoroastre.