PIC I2C esclave ack sur les données

Question

Je regarde 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 l'I2C. Le PIC peut ACK ou NACK sur l'adresse I2C envoyée sur la ligne, mais d'après ce que j'ai lu, il sera toujours ACK sur les octets reçus suivants. 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 du registre valeur _. Si l'esclave ne comprend pas la valeur Register _, il ne doit pas Ack.

Est-ce que quelqu'un pourrait soit confirmer que ce n'est pas possible, ou me dire comment le faire?

Answer 1

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

réponse: Ce que votre demande, c'est probablement pas possible avec un PIC, au moins sans bits cognant lignes d'E/S. La raison en est que ack/nack est vérifié sur le bord de la 9ème horloge et que l'interruption SSPIF n'est pas déclenchée jusqu'à la fin de la 9ème horloge. Vous pouvez essayer de vérifier à plusieurs reprises le bit BF tel qu'il est défini dès que l'octet de données est déplacé dans le registre d'E/S (8ème horloge). Si vous pouvez retirer une comparaison et définir le bit SSPOV avant le 9ème cycle d'horloge cela devrait générer un NACK, c'est assez sommaire si vous avez des interruptions en cours d'exécution. Réponse plus longue: il semble que vous essayiez de valider si l'octet de données reçu par l'esclave est valide ou non. Personnellement, je ne ferais pas cela, ACK est de signaler l'intégrité de la ligne, ne pas vérifier l'intégrité des données. Si le périphérique est un esclave, le maître doit par définition savoir exactement comment il doit fonctionner et vérifier la validité de l'octet avant de le pousser sur les lignes I2C. Dans de tels cas, je suppose que vous avez également le contrôle sur le code du maître I2C, utilisez un fichier d'en-tête commun qui définit toutes les commandes ou des octets de données valides qui peuvent être envoyés pour éviter les discordances dans le code.

Si vous devez vous assurer que le bon octet a été envoyé pour une raison quelconque, demandez au maître de demander à l'esclave un octet de réponse, demandez à l'esclave de renvoyer 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 ne fonctionne réellement. Votre seule option serait d'envoyer un paquet d'octets au démarrage ou périodiquement avec un CRC et de vérifier qu'il correspond à l'esclave. Généralement, les lignes I2C fonctionneront ou non, elles sont à basse vitesse, ont généralement des traces courtes et ont une capacité de bus élevée, si elles ne fonctionnent pas, vous ne verrez aucune erreur.

Answer 2

Ma conjecture est non SI le matériel I2C est intégré au PIC. Toutes les solutions matérielles avec lesquelles j'ai travaillé ont une machine d'état qui ne peut pas s'empêcher d'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 un logiciel avec bit-banging et un tampon open-collector pour l'ACK. Ensuite, vous pouvez faire ce que vous voulez. Ce ne sera pas la norme I2C, alors faites attention si vous mettez sur le bus des périphériques qui ne fonctionnent pas selon vos spécifications. Je ne suis pas sûr mais je pense que pour tout appareil I2C standard s'il ne reçoit pas d'accusé de réception, il peut retransmettre les données ou juste la faute car il n'est pas sûr de qui a le contrôle du bus après une panne (signifié par un NAK).