Mais je me demande comment cette prise de contact se déroule entre un maître et un esclave lorsque l'esclave est l'expéditeur et le maître est le récepteur et que seul l'esclave (l'expéditeur) sait quand il n'y a plus de données à envoyer au récepteur?

Cela n'est pas censé se produire. i2c est un protocole très défini et chaque périphérique esclave doit être connu de chaque maître. En général, le maître demande à l'esclave de transmettre, et soit la taille du message est fixe, soit le message est séquentiel, soit le message comprend le nombre d'octets qui seront envoyés.

1. Le maître écrit une adresse de registre, puis le maître passe en lecture et l'esclave envoie un octet. C'est tout ce que le maître veut, envoie un arrêt.

2. Le maître écrit une adresse de registre, puis le maître passe en lecture et l'esclave envoie un octet, puis le maître lit à nouveau, de sorte que l'esclave envoie l'octet suivant (ou le même octet). Le maître lit combien il veut, arbitrairement, puis envoie un arrêt.

3. Le maître écrit une adresse de registre, puis le maître passe en lecture et l'esclave envoie un octet. Cet octet indique au maître le nombre d'octets que le registre doit avoir. Le maître lit et l'esclave en envoie autant, puis le maître s'arrête.

Toutes les communications sont contrôlées par le maître. L'esclave ne fait rien que le maître ne veut pas qu'il fasse. Le maître contrôle la vitesse de l'horloge (sans tenir compte de l'étirement de l'horloge) et le nombre d'octets lus. L'esclave ne doit à aucun moment essayer de forcer la ligne de données alors que le maître ne le lui a pas dit. La structure des données doit être connue à l'avance.

Ce sont les deux options.

Si le récepteur esclave n'accepte pas plus de données, il peut NAK l'octet, mais le maître est toujours responsable de l'envoi de la condition d'arrêt.

Pour un émetteur esclave, il ne peut rien signaler pour s'arrêter, il doit être connu à l'avance, ou il pourrait être encodé dans les données, par ex.la chaîne de texte se termine par un zéro afin que l'esclave puisse transmettre des zéros jusqu'à ce que le maître s'arrête.

Habituellement, cela est rare et il existe un protocole connu, le maître doit donc toujours savoir à l'avance combien d'octets il lira ou écrira dans une seule transaction, même si cela signifie transférer d'abord un en-tête de taille fixe entre les périphériques combien il faut transférer.

Disons qu'un esclave ou un maître envoie plusieurs octets au récepteur sur le bus I2C et le nombre d'octets n'est pas défini au préalable. Donc alors comment l'expéditeur dira-t-il au destinataire qu'il n'a plus de données à envoyer?

Si le maître est l'expéditeur, alors il sait combien d'octets doivent être envoyés. Le maître signalera la fin de son transfert de données en envoyant une condition STOP après l'envoi du dernier octet, et terminera la transaction.

Notez que Master peut le faire à tout moment. L'esclave peut envoyer NACK pour dire qu'il ne veut plus recevoir de données. Mais seul le maître décide d'arrêter cette transaction.

Mais je me demande comment se déroule cette poignée de main entre un maître et esclave lorsque l'esclave est l'expéditeur et le maître est le récepteur et seulement l'esclave (l'expéditeur) sait quand il n'y a plus de données à envoyer au récepteur?

Si Slave est l'expéditeur, le maître doit savoir au préalable combien d'octets doivent être reçus. Le maître le signalera en envoyant un NACK après avoir reçu le dernier octet afin que l'esclave ne conduise plus la ligne SDA. Le maître peut maintenant lancer une condition STOP et mettre fin à la transaction.

Bonne lecture ici: TEXAS i2c

Je vais digérer tout votre message petit à petit ...

Disons qu'un esclave ou un maître envoie plusieurs octets au récepteur sur le bus I2C et le nombre d'octets n'est pas défini au préalable.

Mais cela devrait être défini. Si des informations aléatoires ont été envoyées ou reçues, vous ne pourrez jamais les interpréter.

Alors, comment l'expéditeur dira-t-il au destinataire qu'il n'a plus de données envoyer?

Le fabricant détermine combien de bits il doit recevoir de l'esclave. Le maître est généralement écrit par un périphérique logique comme un microcontrôleur, un processeur, etc.

Jusqu'à présent, ce que je comprends, c'est que pour le cas où l'expéditeur est Master puis il envoie un NACK pour dire à l'esclave (récepteur) qu'il y a plus de données à envoyer.

Non, pas tout à fait correct. Un "NACK" se produit lorsque le maître "n'entend" rien en retour de l'esclave après avoir envoyé ce bit à l'esclave. C'est comme être au téléphone et dire: "Bonjour, tu es là?"

Mais je me demande comment se déroule cette poignée de main entre un maître et esclave lorsque l'esclave est l'expéditeur et le maître est le récepteur et seulement l'esclave (l'expéditeur) sait quand il n'y a plus de données à envoyer au récepteur?

Votre définition de l'expéditeur et du destinataire est biaisée. Le maître et l'esclave agissent à la fois comme émetteur et comme récepteur. Le maître peut à la fois envoyer et recevoir, en fonction des opérations d'écriture ou de lecture respectivement.

Conseil utile: Pensez à lire la fiche technique des esclaves I2C. Recherchez le mot clé "message". Ce sont les informations que le maître envoie à l'esclave.

Photo ici... pas ma photo.

Le maître doit être programmé pour lire la même longueur de trame d'adresse que l'esclave, qui est définie par la fiche technique de l'esclave.Vous pouvez également être en mesure de définir l'adresse d'un esclave, mais généralement pas de beaucoup.Cela aidera à résoudre le conflit si deux esclaves partagent la même adresse.

Voici un exemple de pièce avec laquelle je viens de travailler récemment, c'est un contrôleur ADM1276 remplaçable à chaud.Il respecte les spécifications PMBUS mais la topologie I2C s'applique toujours.Il vous indique les interactions du maître et de l'esclave lorsque vous envoyez, recevez, lisez et écrivez des octets.

Il n'y a rien dans le protocole i2c qui résout ce problème.Vous pouvez le faire fonctionner, mais vous utiliserez un logiciel pour le faire.Étant donné que i2c a été conçu pour la communication matérielle, impliquant généralement des registres de taille fixe, rien n'a été fourni pour gérer les données de longueur variable.J'ai découvert cela moi-même et j'ai dû résoudre le même problème que vous envisagez.

Puisque le maître contrôle tout, tout ce que l'esclave peut faire est de lui envoyer des indices sur la quantité de données à envoyer.Ce qui a fonctionné le mieux pour moi, c'est que l'esclave envoie la longueur comme premier octet.Ensuite, le maître sait combien d'octets il doit demander.

Le protocole lui-même ne permet pas une telle action, mais rien ne peut être résolu avec la programmation.

Deux options possibles éventuellement:

1. Que l'enseignant demande d'abord une valeur dans ce cas entier (moins de 255) et ce sera la taille des données que vous enverrez plus tard lors du prochain appel que vous passerez.

2. Si vous connaissez la longueur maximale des données à envoyer, prenez-la comme référence, convertissez-la en tableau ou en chaîne et ajoutez un caractère spécifique que vous allez prendre pour marquer où votreles données se terminent et dans le maître, vous convertissez à nouveau dans le type de données que vous utilisez.Avec les plus petites données, remplissez le reste de la chaîne avec votre caractère spécial et le tour est joué, vous enverrez toujours une chaîne de même taille.