Puis-je utiliser un ATtiny84 comme esclave SPI et maître i2c dans la même application

macdonaldtomw

Puis-je utiliser un ATtiny84 comme esclave SPI et maître i2c dans la même application


Je suis en train de concevoir une carte à l’aide de l’Attiny84A qui utilise une USI (Universal Serial Interface), et en tant que tel, il n’y a pas de périphérique I2C et SPI dédié.

J’ai fait fonctionner I2C et l’ai testé en communiquant avec une EEPROM 24AA02UID.

J’ai fait fonctionner Slave SPI et l’ai testé en renvoyant les données demandées à un maître.

Ma question est: si l’ATtiny n’a aucun contrôle sur si / quand le maître décide de démarrer une transaction SPI, est-il possible d’utiliser ces mêmes broches USI pour interroger l’EEPROM sur i2c?

entrez la description de l'image ici

Je suppose que le fait d’autoriser le maître SPI externe à utiliser les broches i2c qui sont attachées à l’EEPROM va provoquer des données étranges sur l’EEPROM si / quand le maître envoie un octet correspondant à l’adresse i2c de la puce EEPROM, suivie d’autres données aléatoires.

Ou suis-je trop inquiet? J’espérais que les signaux SPI ne seraient pas pris en compte par l’EEPROM en raison d’un formatage incorrect du protocole i2c.

Le problème du maître SPI externe prenant le contrôle des lignes pendant une séquence de communication i2c est cependant troublant.

La meilleure solution est-elle d’utiliser un tampon à trois états que mon ATtiny84a peut basculer pour couper le maître SPI externe des lignes en question chaque fois qu’il souhaite lire / écrire dans l’EEPROM?

ÉDITER:

Il semblerait que la solution la moins chère, la plus simple et la plus géniale soit d’utiliser simplement une autre puce ATtiny. Je pense que j’irai avec l’Attiny88 qui a un port TWI et SPI dédié (sur des broches séparées):

entrez la description de l'image ici

Réponses


 Érable

Vous avez correctement identifié le plus gros problème – l’hôte SPI peut essayer de piloter la ligne d’horloge / données pendant que le maître ou l’esclave I2C le tire vers le bas.

Le deuxième problème est le timing, car la requête SPI peut arriver au milieu du paquet I2C. Ce qui se passe ensuite dépend de l’esclave I2C particulier. Il peut soit ignorer les données, attendre le prochain cycle d’horloge, attendre la condition d’arrêt ou simplement faire quelque chose de bizarre / inattendu.

La solution la plus simple serait déjà suggérée la séparation des canaux et le bit banging I2C. Cependant, cela n’est possible que si vous avez 2 broches et du temps processeur disponibles, et qu’une vitesse I2C plus lente est acceptable.

Si ce qui précède ne fonctionne pas pour vous, du matériel supplémentaire est nécessaire. Plus précisément, vous avez besoin de deux portes à 3 états pour déconnecter les lignes SCK et MOSI provenant du maître SPI, et d’une porte supplémentaire pour déconnecter l’entrée SCL de l’esclave I2C (lorsque les portes SPI sont ouvertes). C’est la solution que vous avez déjà décrite dans votre question et cela fonctionnera, jusqu’à un certain point. Le problème potentiel ici est que le maître SPI ne sachant pas que vous n’écoutez pas acceptera tout état que vous avez sur la ligne MISO comme réponse valide.

Si la ligne CS du maître est disponible et que vous souhaitez être plus convivial pour le maître, vous pouvez essayer d’utiliser l’étirement de l’horloge I2C comme moyen de suspendre la transaction I2C pour gérer la demande SPI. L’idée est de mettre des verrous sur le bus I2C pour « geler » les signaux provenant d’attiny au moment où la ligne CS est activée. Plusieurs choses se produiront alors:

  • le SCL et le SDA venant d’Attiny s’arrêteront là où ils étaient;
  • l’ISR en question reprogrammera USI en SPI;
  • à la fin, il ouvrira les portes SCK et MOSI et traitera les demandes entrantes.

Lorsque la ligne CS est libérée, l’attiny fermera les portes SPI, générera une condition « d’arrêt » pour l’esclave I2C et reprogrammera USI. C’est un scénario très compliqué et certains périphériques esclaves pourraient ne pas l’aimer (l’étirement de l’horloge maître était déconseillé dans les spécifications récentes).

En bref – si vous pouvez utiliser le bit banging, utilisez-le. Si ce n’est pas le cas, préparez-vous à quelques bricolages importants.

macdonaldtomw

Merci d’avoir confirmé mes soupçons. Je pense que je vais simplement utiliser un ATtiny88 à la place (avec des périphériques TWI et SPI dédiés sur des broches séparées).

Érable

Ce serait une solution idéale et en fait « la plus géniale ». Bonne chance.


 Nick Alexeev

La meilleure solution est-elle d’utiliser un tampon à trois états que mon ATtiny84a peut basculer pour couper le maître SPI externe des lignes en question chaque fois qu’il souhaite lire / écrire dans l’EEPROM?

Il peut y avoir une solution plus simple.

… ATtiny84A qui utilise une USI (Universal Serial Interface), et en tant que tel, il n’y a pas de périphérique I2C et SPI dédié.

Eh bien, USI est un périphérique dédié I2C et SPI. Mais un seul type de bus dans une conception donnée.

Puis-je utiliser un ATtiny84 comme esclave SPI et maître I2C dans la même application

Oui, c’est possible.

  • Implémentez le maître de bus I2C en utilisant le banging logiciel. Cela vous permet d’utiliser toutes les broches GPIO pour le bus I2C.

    Les bus I2C fonctionnent généralement à un rythme tranquille, et frapper un maître I2C dans le firmware est une option viable.
  • Utilisez le matériel USI pour l’esclave SPI.

    L’implémentation d’un esclave SPI ou I2C dans le micrologiciel est impossible à un débit de données raisonnable.

 

#et, #la, Application, ATtiny84, comme, dans, esclave, I2C, maître?, même, Puis-je, SPI, un, utiliser

 

google

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *