Guides d'ingénierie
I²C vs SPI pour les capteurs de pression : choisissez le bon bus ou détestez votre mise en page plus tard
Vous avez choisi votre capteur de pression. Vous connaissez la portée, la précision, le package. Ensuite, vous voyez deux variantes sur la page de commande : I²c et Spice. Même capteur. Même prix. Quatre lettres différentes. Voici comment décider – avec des chiffres réels, et non avec la théorie des manuels.
Le rappel de deux minutes
Ignorez ceci si vous avez déjà câblé les deux bus. Si ce n’est pas le cas, voici de quoi suivre le reste de l’article :
- Fils : 2 — SDA (données) + SCL (horloge)
- Type de signal : Drain ouvert, tiré haut avec des résistances
- Adressage : Adresse 7 bits par appareil
- Direction: Semi-duplex
- Vitesse: 100 kHz / 400 kHz / 1 MHz / 3,4 MHz
- Contrôle: Initié par le maître ; les esclaves répondent uniquement lorsqu'ils sont adressés
- Fils : 4 — MOSI, MISO, SCLK + 1× CS par appareil
- Type de signal : CMOS push-pull
- Adressage : Aucun — La ligne CS sélectionne l'appareil
- Direction: Duplex intégral
- Vitesse: 1 MHz à 50 MHz
- Contrôle: Le maître contrôle l'horloge ; pas d'étirement de l'horloge
À ce stade, vous pourriez penser : "SPI is faster, so SPI wins, end of article." Pas tout à fait : la vitesse n’a presque jamais d’importance pour un capteur de pression. Voici pourquoi.
L’argument de la vitesse qui n’a pas d’importance
Un capteur de pression MEMS typique effectue une lecture tous les 1 à 100 millisecondes — le temps de conversion ADC domine, pas la vitesse du bus. Même à 1 ms par échantillon (échantillonnage de 1 kHz), vous poussez peut-être 48 bits par lecture. C'est 48 kbit/s.
I²C à 400 kHz transfère ~ 320 kbps après surcharge. SPI à 1 MHz transfère 1 Mbps. L'un ou l'autre est 7× à 20× plus rapide que le débit de données du capteur. À moins que vous n'échantillonniez à des fréquences ultrasoniques – ce qui n'est pas le cas, car la pression ne change pas si rapidement – la vitesse du bus n'a pas d'importance. Le capteur est le goulot d'étranglement, pas les fils.
En résumé, sur la vitesse : cela n’a pas d’importance. L'ADC du capteur est le facteur limitant. Décidez pour d’autres motifs.
Nombre de broches : l'argument qui compte réellement sur les petits tableaux
| Scénario | Broches I²C utilisées | Broches SPI utilisées |
|---|---|---|
| 1 capteur | 2(SDA+SCL) | 4 (MOSI + MISO + SCLK + CS) |
| 2 capteurs | 2 (bus partagé) | 5 (bus partagé + 2× CS) |
| 4 capteurs | 2 (bus partagé) | 7 (bus partagé + 4× CS) |
Si votre MCU est un STM32 avec 80 GPIO, peu importe. Mais sur un ESP32-C3 avec 15 GPIO utilisables exécutant un écran, BLE, deux boutons et une carte SD, ces 2 broches supplémentaires pour SPI piquent. I²C vous enregistre les broches quel que soit le nombre de capteurs partageant le bus.
Remarque : I²C vous coûte cher deux résistances pull-up. SPI ne coûte rien. Deux résistances 0402 de 4,7 kΩ coûtent environ 0,002 $ au total et occupent 2 mm² d'espace sur la carte – ce n'est pas rien, mais presque.
Conclusion sur les broches : I²C gagne lorsque les GPIO sont serrés. Avec un MCU riche en broches, l'avantage disparaît : décidez d'autres facteurs.
Conceptions multi-capteurs : là où l'I²C brille réellement
Trois capteurs de pression sur le même PCB : une référence barométrique, un niveau de réservoir, une sortie de pompe. Avec I²C : attribuez à chaque capteur une adresse différente, câblez SDA et SCL en parallèle, c'est fait. Deux traces. Trois capteurs. Zéro broche MCU supplémentaire. Avec SPI : trois lignes CS distinctes au-dessus du MOSI/MISO/SCLK partagé — six fils au total.
Attention: Les appareils I²C ont besoin d'adresses uniques. La plupart des capteurs de pression offrent exactement deux adresses (une épingle attachée haut ou bas). Cela signifie que vous disposez de deux capteurs sur le bus avant d'avoir besoin d'un multiplexeur I²C comme le TCA9548A, ce qui ajoute environ 0,50 $ et quelques mm². SPI n’a pas une telle limite ; ajoutez simplement une ligne CS par capteur.
Conclusion sur le multi-capteur : I²C gagne en termes de simplicité de câblage jusqu'à deux capteurs identiques. Au-delà de cela, utilisez SPI ou un multiplexeur I²C – ni l'un ni l'autre n'est clairement meilleur, c'est un appel de mise en page.
Immunité au bruit : celle où SPI prend de l'avance
Les capteurs de pression haute résolution mesurent des changements aussi minimes que 0,03 hPa, soit environ le poids d'un moustique atterrissant sur votre bureau, traduit en signal électrique. À cette résolution, le bruit compte.
Caractéristiques du bruit I²C
Les lignes à drain ouvert avec des résistances de rappel produisent des bords de rampe RC, et non des transitions CMOS propres. Les valeurs de traction sont un compromis : une valeur trop forte gaspille de l'énergie ; trop faible rend le temps de montée lent et ouvre une fenêtre pour le couplage du bruit. Dans un environnement bruyant (à côté d'un pilote de moteur, d'un régulateur à découpage ou de tout autre élément doté de PWM), I²C peut avoir des problèmes. Le protocole n'a pas de détection d'erreur intégrée au-delà du bit ACK (certains capteurs ajoutent un octet CRC à la charge utile, ce qui aide).
Caractéristiques du bruit SPI
Les pilotes CMOS push-pull pilotent activement les états haut et bas. Les bords sont tranchants. La ligne CS se déclenche exactement au moment où l'esclave doit écouter, ignorant tout ce qui se passe sur le bus le reste du temps. Un SNR intrinsèquement meilleur.
En pratique, une disposition de circuit imprimé propre avec des traces courtes, un plan de masse et des capuchons de dérivation satisfera l'I²C sur la plupart des conceptions. Mais si votre capteur est sur un câble à un mètre du MCU, ou partage un boîtier avec tout ce qui commute les ampères de courant, l'immunité au bruit du SPI est un véritable avantage.
Conclusion sur le bruit : SPI est le choix le plus sûr dans les environnements électriquement hostiles. Sur le même PCB à quelques centimètres du MCU, I²C va bien.
Complexité du micrologiciel : le bris d'égalité dont personne ne parle
Micrologiciel I²C
A state machine. Start condition → send address + R/W bit → wait for ACK → read/write register pointer → read/write data → stop condition. Every step has a timeout, a retry path, and a "what if the sensor holds SDA low because it's still converting" case. Most MCU vendors provide a HAL. Most of those HALs have edge-case bugs you'll discover at 11 PM.
Micrologiciel SPI
Assert CS → shift bytes → de-assert CS. That's it. The sensor doesn't get to say "I'm not ready" by clock-stretching or NAKing. The master controls the clock; the slave responds or stays silent.
Problème de débogage : Lorsque SPI ne fonctionne pas, vous sondez quatre lignes avec un analyseur logique et voyez exactement ce qui se passe. Lorsque I²C ne fonctionne pas, vous regardez un écran rempli de NAK et vous vous demandez s'il s'agit des valeurs de pull-up, de l'adresse, de la synchronisation ou de la capacité du bus. Un analyseur logique à 8 $ résout les deux, mais I²C vous fera perdre plus de temps.
Conclusion sur le firmware : SPI est moins ennuyeux en mode nu. Avec un HAL ou une bibliothèque, c'est à peu près un lavage. I²C prend plus de temps à déboguer lorsqu'il tombe en panne.
Consommation d'énergie : les deux sont des erreurs d'arrondi
Un bus I²C de 400 kHz avec des pull-ups de 4,7 kΩ consomme environ 00,7 mA lorsqu'il est actif. SPI ne brûle pratiquement rien au niveau du bus – du courant de commutation purement CMOS à ces vitesses (microampères).
Context: the pressure sensor element and ADC draw ~5 µA at 1 Hz sampling and 0.3 µA in standby. Whether the bus burns 0.5 mA or 0.05 mA for the 2 ms it takes to read a sample — the energy difference is picowatt-hours. Your BLE radio burns more power sending one "hello" packet than the bus choice will save across the sensor's entire operating lifetime.
Conclusion sur la puissance : ne choisissez pas I²C ou SPI en fonction de la puissance. La différence est trop petite pour avoir de l’importance. Décidez plutôt des broches, du bruit ou de la santé du micrologiciel.
Flux de décision - Quatre questions, pas de matrice
1Combien de capteurs identiques sur un bus ?
Aucun avantage de toute façon. Passez à la question 2.
Deux adresses, deux fils. À moins que les capteurs ne soient éloignés les uns des autres, alors SPI.
Sauf si vous aimez lire les fiches techniques des multiplexeurs I²C.
2À quelle distance se trouve le capteur du MCU ?
I²C convient au niveau de la carte avec une présentation propre.
Ou I²C avec un tampon différentiel (PCA9615). I²C n'a jamais été conçu pour les câbles.
Utilisez 4 à 20 mA ou RS-485. Vous êtes sur le territoire des émetteurs industriels.
3Quel est l'environnement EMI ?
Une disposition épurée avec des capuchons de dérivation rend I²C heureux.
Les pilotes push-pull et le gate CS empêcheront les lectures fantômes.
4Est-ce que c'est vous qui écrivez le pilote ?
L'abstraction rend la différence négligeable. Utilisez ce que le reste du tableau utilise.
Moins d’états, pas d’étirement d’horloge, pas de conflits d’adresses.
La plupart des bibliothèques de capteurs amateurs utilisent par défaut I²C. Vérifiez d'abord la bibliothèque.
The "Why Not Both" Card
Dual InterfaceCertains capteurs sont livrés avec I²C et SPI sur la même puce, sélectionnable via une sangle à broches ou un embout de registre. Ceci est vraiment utile dans deux scénarios :
Flexibilité du prototypage
Commencez par I²C sur un Arduino ou une carte de dérivation car c'est plus facile à câbler. Lorsque vous faites tourner votre propre PCB, passez à SPI si votre configuration en bénéficie. Même capteur, même logique de firmware, juste un appel HAL différent.
Flexibilité des références de production
Une conception de PCB, différents SKU. Un SKU utilise I²C car il partage le bus avec un capteur de température/humidité. Un autre a besoin de SPI pour des tracés plus longs vers une carte de capteur distant. Vous ne modifiez rien : modifiez une ligne de nomenclature et une sangle de résistance.
Si votre candidat capteur ne prend pas en charge les deux bus, ce n'est pas un problème. Mais avoir cette option est une de ces choses que vous n'appréciez pas jusqu'à ce que vous relanciez un tableau à 2 heures du matin.
Résumé côte à côte
| Facteur | I²c | Spice | Gagnant |
|---|---|---|---|
| Nombre de fils | 2 | 4 + 1 par capteur | I²c |
| Vitesse | Jusqu'à 3,4 MHz | Jusqu'à 50 MHz | Tie - le capteur ADC est le goulot d'étranglement |
| Multi-capteur (même type) | Max 2 sans multiplexeur | Illimité (un CS par capteur) | SPI au-delà de 2 capteurs |
| Immunité au bruit | Bords RC à drain ouvert | CMOS push-pull, bords nets | Spice |
| Complexité du micrologiciel | Machine à états, ACK/NAK, délais d'attente | Affirmer CS, décaler les octets, c'est fait | SPI (sans système d'exploitation) ; Cravate (avec HAL) |
| Difficulté de débogage | Plus dur — Chasse au NAK | Plus facile – des signaux simples | Spice |
| Power consumption | ~0,7 mA (pull-ups actifs) | ~0 mA (pas de tractions) | Cravate - le delta est en picowattheures |
| Chemins de câbles | Non recommandé >200 millimètres | Tolère des traces plus longues | Spice |
| External components | 2 × résistances de rappel | Aucun | Cravate — 2 × résistances 0402 ≈ 0,002 $ |
TL;DR
Vous ne savez pas quelle interface correspond à votre conception ? Dites-nous votre MCU, les contraintes de votre carte et votre environnement : nous vous indiquerons la bonne partie, généralement dans un délai d'une heure.
Contactez-nous →
