Voyez l'initiateur de flux (le Master dans le cas de l'I2C) comme un chef d'orchestre : c'est lui qui donne le tempo !
Par voie de conséquence, personne d'autre ne doit avoir son propre tempo, sinon c'est la cacophonie et non la symphonie.
C'est pour ça que c'est si important dans le schéma d'architecture de savoir qui a l'initiative de chaque flux. On peut avoir des flux successifs qui s'enchainent :
A a l'initiative et envoie des données à B
B reçoit les données de A et a l'initiative pour envoyer des données à C (en fait, il se cale sur le tempo de A et l'impose à C)
etc...
Mais si B reçoit aussi des données de C ou d'un autre, il est coincé entre le timing de A et celui du tiers, lequel est forcément différent.
Ce conflit est très difficile à gérer sur un µ monotâche, encore plus sur un Picaxe pour lequel les tâches de fond (I2C slave, background receive, SERVO, timers, interruptions, ...) souffrent de nombreuses incompatibilité.
Par voie de conséquence, personne d'autre ne doit avoir son propre tempo, sinon c'est la cacophonie et non la symphonie.
C'est pour ça que c'est si important dans le schéma d'architecture de savoir qui a l'initiative de chaque flux. On peut avoir des flux successifs qui s'enchainent :
A a l'initiative et envoie des données à B
B reçoit les données de A et a l'initiative pour envoyer des données à C (en fait, il se cale sur le tempo de A et l'impose à C)
etc...
Mais si B reçoit aussi des données de C ou d'un autre, il est coincé entre le timing de A et celui du tiers, lequel est forcément différent.
Ce conflit est très difficile à gérer sur un µ monotâche, encore plus sur un Picaxe pour lequel les tâches de fond (I2C slave, background receive, SERVO, timers, interruptions, ...) souffrent de nombreuses incompatibilité.