ack esclave I2C PIC sur les données

Question

Je suis à la recherche dans le protocole I2C pour PIC16F88X. Ce que je voudrais faire, est de permettre à un esclave I2C soit ACK ou NACK en fonction des données reçues sur le I2C.

Le PIC peut ACK ou NACK sur l'adresse I2C envoyé sur la ligne, mais de ce que je l'ai lu sera toujours ACK sur les octets suivants reçus. Est-ce exact?

Dans la communication suivante:

Start - I2c_Addr+write/ACK - Register_value/Nack

Je voudrais l'esclave de pouvoir ou Ack Nack en fonction de la valeur Register_value. Si l'esclave ne comprend pas Register_value, il ne devrait pas Ack.

Quelqu'un pourrait-il s'il vous plaît soit confirmer que cela est impossible, ou me dire comment faire?

Answer 1

En supposant que votre périphérique en utilisant le MSSP

réponse courte: Ce que votre demande, c'est probablement pas possible avec un PIC, au moins sans bits cognant lignes d'E / S. La raison est que ack / nack est vérifié le 9 bord d'horloge et l'interruption de SSPIF ne se déclenche pas jusqu'à la fin de l'horloge 9. Vous pouvez essayer de vérifier à plusieurs reprises le bit BF comme il est défini dès que l'octet de données est décalée dans le registre d'E / S (8 horloge). Si vous pouvez retirer une comparaison et définir le bit SSPOV avant le 9 cycle d'horloge cela devrait générer un NACK, cela est tout à fait peu précis si vous avez des interruptions en cours d'exécution.

réponse plus longue: il semble que votre tentative de validation si l'octet de données reçoit l'esclave est valide ou non en utilisant ack. Personnellement, je ne voudrais pas faire cela, ack est de signaler l'intégrité de la ligne, ne pas vérifier l'intégrité des données. Si l'appareil est un esclave du maître, par définition, doit savoir exactement comment il est au travail et peut vérifier la validité de l'octet avant de le pousser sur les lignes I2C. Dans ce cas, je suppose que vous avez également le contrôle sur le code du maître I2C, utilisez un fichier d'en-tête commune qui définit toutes les commandes ou octets de données valides qui peuvent être envoyés afin d'éviter discordances dans le code.

Si vous devez garantir l'octet approprié a été envoyé pour une raison quelconque, avoir le maître demander l'esclave d'un octet de réponse, ont l'esclave retourne un code indiquant le résultat du transfert précédent.

Si votre intention est de garantir l'intégrité de la ligne I2C, aucune de ces approches fonctionnent vraiment. Votre seule option serait d'envoyer un volume d'un octets au démarrage ou périodiquement avec un CRC et vérifier qu'il correspond à l'esclave. En général, les lignes I2C seront soit le travail ou non, ils sont à vitesse réduite, ont généralement courtes traces et ont une capacité élevée de bus admissible, si elles arn't vous ne verrez pas de travail du tout de tout ack.

Answer 2

Je pense pas si le matériel I2C est intégré au PIC. Toutes les solutions matérielles j'ai travaillé ont une machine d'état qui ne peut pas aider mais ACK le second octet moins qu'il y ait quelque chose de mal avec la transmission (manque un peu, par exemple). Vous feriez mieux de faire votre propre implémentation I2C dans le logiciel avec le bit-banging et un tampon collecteur ouvert pour l'accusé de réception. Ensuite, vous pouvez faire tout ce que vous voulez. Il ne sera pas la norme I2C, donc attention si vous mettez des périphériques sur le bus qui ne fonctionnent pas à votre cahier des charges. Je ne sais pas désinvolture mais je pense que pour tout appareil I2C standard si elle ne reçoit pas un accusé de réception, il peut retransmettre les données ou tout simplement la faute car il ne sait pas qui a le contrôle du bus après une panne (signifié par un NAK ).