Y a-t-il une différence entre les deux, ou s'agit-il simplement d'une question d'abstraction? Mon intuition dit qu'il n'y a pas de différence mais j'aimerais me tromper.
Réponses:
Un périphérique de contrôleur SPI réel dans le MCU peut souvent fonctionner beaucoup plus rapidement que le fait de frapper l'interface. Bien sûr, cela dépend du MCU, mais cela ne m'étonnerait pas de voir un contrôleur SPI fonctionner à 30+ MHz, tandis que le banging pourrait être limité à environ 1 MHz (si vous avez de la chance).
Mais il y a plus que cela. Lors du bang-bang, le MCU est occupé à le bang-bang. Il déplace les données et fait tourner les lignes GPIO. Cela signifie qu'il ne peut rien faire d'autre. Lorsque vous utilisez un contrôleur SPI, le contrôleur est occupé à faire tout cela et le MCU est libre de faire d'autres choses.
Ainsi, avec un contrôleur SPI réel, le transfert SPI réel est beaucoup plus rapide et le MCU récupère certains cycles qu'il peut utiliser pour faire d'autres choses.
Il n'y a aucune différence en termes que vous pouvez obtenir le même résultat en utilisant les deux méthodes, mais il y a quelques raisons pour lesquelles vous choisiriez l'une plutôt que l'autre.
L'utilisation d'un périphérique SPI permettra au processeur de ne pas avoir à se soucier de générer le timing pour frapper les broches d'E / S, lui permettant d'effectuer d'autres tâches de calcul et de simplifier votre programmation du CPU. Étant donné que le périphérique est implémenté dans le matériel, il fonctionnera plus rapidement et consommera moins d'énergie que les E / S de frappe de bits. Il peut y avoir des cas où vous voudriez mordre les E / S pour interfacer avec SPI si votre application exige que vous choisissiez un processeur sans périphérique SPI. Pour des raisons de santé mentale, je recommanderais d'éviter cela, sauf si cela est absolument nécessaire.
SPI est une interface synchrone , le maître contrôlant l'horloge. Cela signifie que si vous êtes le maître, vous pouvez choisir la vitesse d'horloge et le timing. Les périphériques esclaves auront une limite supérieure sur la fréquence d'horloge qu'ils peuvent gérer, mais ne se soucient généralement pas de la lenteur de l'horloge en dessous. Plus spécifiquement, il y a généralement un temps minimum pour que chaque esclave ait besoin de voir l'horloge à l'état haut et bas avant de pouvoir à nouveau basculer, et il y aura une configuration minimale de données et des limites sur la ligne de données entourant le bord de l'horloge sur lequel le l'esclave lit la ligne de données.
Pour cette raison, l'implémentation d'un maître SPI dans le firmware est vraiment assez facile. Je l'ai souvent fait pour faciliter l'utilisation de certaines broches, lorsqu'il n'y avait pas de matériel SPI intégré, ou qu'il n'était pas disponible à cette fin pour une raison quelconque. Faire un maître SPI dans le firmware est aussi simple que possible.
De nombreux périphériques esclaves SPI sont assez rapides, donc souvent l'horloge minimale et les temps de configuration sont respectés simplement en s'assurant que chacun a au moins un cycle d'instruction. Dans ce cas, le code est très court et rapide. Dans certains cas, un appareil esclave peut nécessiter deux ou trois cycles d'instructions par phase d'horloge, mais ce n'est vraiment pas difficile à garantir non plus. La boucle de bits SPI de bas niveau nécessite d'effectuer un certain décalage du bit de sortie suivant en position, de saisir le bit d'entrée et de vérifier le compteur de boucle. Vous pouvez généralement répondre à des exigences de temps minimum de deux ou trois cycles simplement en organisant lorsque vous conduisez et en échantillonnant les lignes avec certains des autres frais généraux insérés aux bons endroits. Si la vitesse est importante, vous pouvez utiliser le préprocesseur assembleur pour écrire une boucle déroulée. Avec des techniques comme celle-ci,
Il y a quelques avantages à faire le maître SPI dans le firmware. Le matériel SPI est parfois un peu ridicule dans la façon dont il peut être configuré. Il y a toujours la question de ce qui doit exactement se produire immédiatement lorsque la sélection d'esclaves est affirmée. Le premier bit est-il alors écrit sur les lignes de données? Que se passe-t-il si l'horloge commence bas et que les lignes de données sont censées être verrouillées sur le front descendant? Parfois, cela compte, parfois non. Avec un firmware SPI maître, vous pouvez être plus indulgent et éventuellement utiliser la même routine pour communiquer avec différents esclaves. Par exemple, vous pouvez vous assurer que la ligne de données MOSI (Master Out Slave In) est stable sur les deux bords de l'horloge. Le matériel SPI ne fait généralement pas cela, donc ce matériel devrait être reconfiguré en fonction de l'esclave avec lequel il communique à l'époque.
Un autre avantage d'un firmware SPI maître est que vous pouvez choisir un nombre arbitraire de bits par séquence SPI. Le matériel est généralement limité à des multiples de 8 bits. La plupart des appareils sont conçus pour permettre des transferts d'octets entiers, mais souvent ils n'en ont pas besoin. Par exemple, un A / D 10 bits enverra probablement les 10 bits de données en premier, puis enverra 0 ou des ordures après cela si vous continuez à le synchroniser. Si vous utilisez du matériel SPI, vous serez obligé de transférer 16 bits et de masquer les déchets. Tout fonctionnera bien, mais un micrologiciel SPI maître pourrait en fait être plus rapide que le matériel dans ce cas, car il ne transfère que le minimum de 10 bits requis.
Les principaux avantages des maîtres matériels SPI sont que le micrologiciel peut lancer un transfert d'octets, puis s'éteindre et faire autre chose. Le cadencement peut également être généralement plus rapide que ne peut le faire une boucle de micrologiciel non déroulée. Notez que bien que ces deux avantages puissent être importants dans certaines circonstances, ils sont souvent non pertinents. La plupart du code SPI qui utilise du matériel pour transférer un octet entre immédiatement dans une boucle d'attente pour que le matériel termine le transfert. Vérifiez également attentivement les exigences de synchronisation de l'esclave. Les périphériques SPI sont généralement rapides dans leur ensemble, mais il y a des cas où vous devez quand même ralentir le matériel pour correspondre à la vitesse maximale que l'esclave peut gérer.
C'était tout du point de vue du maître. En bref, il y a souvent peu d'avantages à utiliser du matériel SPI comme maître, et même quelques avantages à ne pas l'utiliser parfois. Cependant, tout cela est différent pour les esclaves. Puisque le maître contrôle l'horloge, les esclaves doivent être prêts pour tout ce que le maître fait chaque fois que le maître le fait. Les exigences de synchronisation sont souvent assez courtes par rapport aux temps d'instruction, donc avoir du matériel implémentant un esclave SPI est généralement ce que vous voulez.
Vous pouvez faire des esclaves SPI dans le micrologiciel, mais c'est délicat, vous devez compter soigneusement les cycles et la latence, et vous finissez généralement par implémenter un sous-ensemble du protocole que vous savez utiliser par votre maître particulier. Par exemple, une fois, j'ai dû concevoir un équivalent numérique d'une ancienne carte contrôleur analogique (ils voulaient des fonctionnalités supplémentaires qui ne pouvaient pas être raisonnablement faites en analogique, et ils voulaient quelque chose de plus petit, moins cher à produire et plus stable). Cette carte est interfacée au reste du système via un bus SPI. L'ancienne carte analogique avait un D / A à deux canaux pour régler les valeurs de contrôle et un A / D à deux canaux pour relire les valeurs mesurées. La mise en œuvre de ces deux dans un seul processeur était délicate, et cela comprenait la détermination du sous-ensemble du protocole matériel D / A et A / D SPI que le maître existant utilisait réellement. Il a également imaginé un processeur qui pourrait fonctionner beaucoup plus rapidement que la fréquence d'horloge SPI. Au final, j'ai utilisé trois interruptions, une pour chaque sélection d'esclave et une pour le front montant de la ligne d'horloge. Cette dernière devait être l'interruption de priorité la plus élevée du système, sinon l'exigence de latence ne pouvait pas être satisfaite.
Quoi qu'il en soit, le point global est qu'un maître SPI du micrologiciel est facile, petit, rapide et flexible, et il n'y a pas de raison de se détourner d'en faire un. D'un autre côté, pour un esclave, vous voulez vraiment du matériel, ou vous devez vous réveiller et réfléchir très attentivement au timing, à la latence, etc.
Cela dépend de ce pour quoi vous faites le SPI. Si votre intérêt en tire les taux de données les plus élevés, le matériel est toujours plus rapide que le bitbanging (par exemple, la puce du cortex du bras dans l'adolescence 3, je peux diffuser des données à 22 Mbps en utilisant le support SPI matériel, contre ~ 4,5 Mbps avec le bitbanging (il peut également gérer des nombres arbitraires de bits par transfert de 3 à 16 - utile lors de l'envoi de données en morceaux de 12 bits pour certains contrôleurs led!)). Sur 16Mhz avrs, la différence est un peu moins extrême, le débit de données le plus élevé avec le matériel semble être élevé 4 / faible 5Mbps, tandis que le bitbanging est d'environ 2,3Mbps).
De plus, si vous utilisez la prise en charge matérielle, encore une fois, selon le microcontrôleur en question, vous disposez d'options pour utiliser les contrôleurs DMA pour déplacer vos données, laissant votre code revenir à d'autres choses, potentiellement plus intéressantes que de garder les données écrire.
Tout ce qui précède dépend du fait que le SPI matériel soit ou non une option.
Si vous bit-bang SPI, vous ne pouvez pas utiliser l'interruption SSP pour gérer les communications. Ce n'est pas si important pour SPI pour de nombreuses utilisations