Guías de ingeniería
I²C vs SPI para sensores de presión: elija el bus adecuado o odie su diseño más tarde
Has elegido tu sensor de presión. Conoces el alcance, la precisión, el paquete. Luego verá dos variantes en la página de pedidos: I²C y SPI. Mismo sensor. Mismo precio. Cuatro letras diferentes. He aquí cómo decidir: con números reales, no con la teoría de los libros de texto.
El repaso de dos minutos
Omita esto si ya ha conectado ambos autobuses antes. Si no lo has hecho, aquí tienes suficiente para seguir el resto del artículo:
- Cables: 2 — SDA (datos) + SCL (reloj)
- Tipo de señal: Drenaje abierto, elevado con resistencias
- Direccionamiento: Dirección de 7 bits por dispositivo
- Dirección: semidúplex
- Velocidad: 100kHz/400kHz/1MHz/3,4MHz
- Control: Iniciado por el Maestro; Los esclavos responden sólo cuando se les dirige la palabra.
- Cables: 4 — MOSI, MISO, SCLK + 1× CS por dispositivo
- Tipo de señal: CMOS push-pull
- Direccionamiento: Ninguno: la línea CS selecciona el dispositivo
- Dirección: Full-dúplex
- Velocidad: 1MHz a 50MHz
- Control: Reloj de control maestro; no hay reloj que se estire
En este punto podrías pensar: "SPI is faster, so SPI wins, end of article." No del todo: la velocidad casi nunca importa para un sensor de presión. He aquí por qué.
El argumento de la velocidad que no importa
Un sensor de presión MEMS típico toma una lectura cada 1 a 100 milisegundos — Predomina el tiempo de conversión del ADC, no la velocidad del autobús. Incluso a 1 ms por muestra (muestreo de 1 kHz), estás empujando quizás 48 bits por lectura. Eso es 48 kbps.
I²C a 400 kHz transfiere ~320 kbps después de la sobrecarga. SPI a 1 MHz transfiere 1 Mbps. Cualquiera de los dos es De 7 a 20 veces más rápido que la velocidad de datos del sensor. A menos que estés muestreando en frecuencias ultrasónicas (lo cual no es así, porque la presión no cambia tan rápido), la velocidad del autobús es irrelevante. El sensor es el cuello de botella, no los cables.
En pocas palabras sobre la velocidad: no importa. El ADC del sensor es el factor limitante. Decidir por otros motivos.
Número de pines: el argumento que realmente importa en los tableros pequeños
| Guión | Pines I²C utilizados | Pines SPI utilizados |
|---|---|---|
| 1 sensor | 2(ADS+SCL) | 4 (MOSI + MISO + SCLK + CS) |
| 2 sensores | 2 (autobús compartido) | 5 (autobús compartido + 2× CS) |
| 4 sensores | 2 (autobús compartido) | 7 (autobús compartido + 4× CS) |
Si su MCU es un STM32 con 80 GPIO, a quién le importa. Pero en ESP32-C3 con 15 GPIO utilizables ejecutando una pantalla, BLE, dos botones y una tarjeta SD, esos 2 pines adicionales para SPI pican. I²C le ahorra pines independientemente de cuántos sensores compartan el bus.
Nota: I²C te cuesta dos resistencias pull-up. SPI no cuesta nada. Dos resistencias 0402 de 4,7 kΩ cuestan alrededor de 0,002 dólares en total y ocupan 2 mm² de espacio en la placa (no nada, pero casi).
En resumen, los pines: I²C gana cuando los GPIO están ajustados. Con una MCU rica en pines, la ventaja desaparece: decida sobre otros factores.
Diseños multisensor: donde realmente brilla I²C
Tres sensores de presión en la misma PCB: una referencia barométrica, un nivel de tanque, una salida de bomba. Con I²C: asigne a cada sensor una dirección diferente, conecte SDA y SCL en paralelo, listo. Dos huellas. Tres sensores. Cero pines MCU adicionales. Con SPI: tres líneas CS separadas encima del MOSI/MISO/SCLK compartido: seis cables en total.
Cuidado: Los dispositivos I²C necesitan direcciones únicas. La mayoría de los sensores de presión ofrecen exactamente dos direcciones (un alfiler atado alto o bajo). Eso significa que obtienes dos sensores en el bus antes de necesitar un multiplexor I²C como el TCA9548A, que agrega ~$0,50 y unos pocos mm². SPI no tiene tal límite; simplemente agregue una línea CS por sensor.
En pocas palabras, con el multisensor: I²C gana por la simplicidad del cableado de hasta dos sensores idénticos. Más allá de eso, use SPI o un mux I²C; ninguno de los dos es claramente mejor, es una llamada de diseño.
Inmunidad al ruido: aquella en la que SPI avanza
Los sensores de presión de alta resolución miden cambios tan pequeños como 0,03 hPa, aproximadamente el peso de un mosquito que aterriza en su escritorio, traducido en una señal eléctrica. A esa resolución, el ruido importa.
Características de ruido I²C
Las líneas de drenaje abierto con resistencias pull-up producen bordes de rampa RC, no transiciones CMOS limpias. Los valores de pull-up son un compromiso: demasiado fuerte desperdicia potencia; demasiado débil hace que el tiempo de subida sea lento y abre una ventana para el acoplamiento de ruido. En un entorno ruidoso (al lado de un controlador de motor, un regulador de conmutación o cualquier cosa con PWM), el I²C puede fallar. El protocolo no tiene detección de errores incorporada más allá del bit ACK (algunos sensores agregan un byte CRC a la carga útil, lo que ayuda).
Características del ruido SPI
Los controladores CMOS push-pull controlan activamente los estados alto y bajo. Los bordes son nítidos. La línea CS activa exactamente cuando el esclavo debería escuchar, ignorando todo lo que hay en el bus el resto del tiempo. SNR inherentemente mejor.
En la práctica, un diseño de PCB limpio con trazas cortas, un plano de tierra y tapas de derivación mantendrá contento a I²C en la mayoría de los diseños. Pero si su sensor está en un cable a un metro de distancia de la MCU, o comparte una carcasa con cualquier cosa que cambie amperios de corriente, la inmunidad al ruido de SPI es una ventaja genuina.
En pocas palabras sobre el ruido: SPI es la opción más segura en entornos eléctricamente hostiles. En el mismo PCB a unos centímetros de la MCU, I²C está bien.
Complejidad del firmware: el desempate del que nadie habla
Firmware 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.
firmware 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.
Dolor de depuración: Cuando SPI no funciona, prueba cuatro líneas con un analizador lógico y ve exactamente qué está sucediendo. Cuando I²C no funciona, miras una pantalla llena de NAK y te preguntas si son los valores pull-up, la dirección, la sincronización o la capacitancia del bus. Un analizador lógico de 8 dólares resuelve ambas cosas, pero I²C le consumirá más tiempo.
En resumen, el firmware: SPI es un sistema básico menos molesto. Con un HAL o una biblioteca, es más o menos un lavado. I²C tarda más en depurarse cuando se estropea.
Consumo de energía: ambos son errores de redondeo
Un bus I²C de 400 kHz con pull-ups de 4,7 kΩ quema aproximadamente 00,7 mA mientras está activo. SPI esencialmente no quema nada a nivel de bus: puramente corriente de conmutación CMOS a estas velocidades (microamperios).
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.
En pocas palabras sobre la potencia: no elija I²C o SPI según la potencia. La diferencia es demasiado pequeña para importar. En su lugar, opte por los pines, el ruido o la integridad del firmware.
Flujo de decisiones: cuatro preguntas, sin matriz
1¿Cuántos sensores idénticos hay en un autobús?
Ninguna ventaja en ambos sentidos. Pase a la pregunta 2.
Dos direcciones, dos cables. A menos que los sensores estén muy separados, entonces SPI.
A menos que le guste leer las hojas de datos del multiplexor I²C.
2¿A qué distancia está el sensor de la MCU?
I²C está bien a nivel de placa con un diseño limpio.
O I²C con un buffer diferencial (PCA9615). I²C nunca fue diseñado para cables.
Utilice 4–20 mA o RS-485. Estás en territorio de transmisores industriales.
3¿Cuál es el entorno EMI?
El diseño limpio con tapas de derivación mantiene contento al I²C.
Los controladores push-pull y la activación CS evitarán lecturas fantasma.
4¿Eres tú quien escribe al conductor?
La abstracción hace que la diferencia sea insignificante. Usa lo que usa el resto del tablero.
Menos estados, sin retrasos en el tiempo, sin conflictos de direcciones.
La mayoría de las bibliotecas de sensores para aficionados tienen por defecto I²C. Primero consulte la biblioteca.
The "Why Not Both" Card
Interfaz dualAlgunos sensores se envían con Tanto I²C como SPI en el mismo troquel., seleccionable mediante una correa de pasador o una broca de registro. Esto es realmente útil en dos escenarios:
Flexibilidad de creación de prototipos
Comience con I²C en un Arduino o placa de conexión porque es más fácil de cablear. Cuando haga girar su propia PCB, cambie a SPI si su diseño se beneficia de ello. Mismo sensor, misma lógica de firmware, solo una llamada HAL diferente.
Flexibilidad de SKU de producción
Un diseño de PCB, diferentes SKU. Un SKU utiliza I²C porque comparte el bus con un sensor de temperatura/humedad. Otro necesita SPI para recorridos de seguimiento más largos hasta una placa de sensor remoto. No rediseña nada: cambia una línea de lista de materiales y una correa de resistencia.
Si su candidato a sensor no es compatible con ambos autobuses, no es un factor decisivo. Pero tener la opción es una de esas cosas que no aprecias hasta que vuelves a girar una tabla a las 2 a.m.
Resumen lado a lado
| Factor | I²C | SPI | Ganador |
|---|---|---|---|
| recuento de cables | 2 | 4 + 1 por sensor | I²C |
| Velocidad | Hasta 3,4MHz | Hasta 50MHz | Empate: el sensor ADC es el cuello de botella |
| Multisensor (mismo tipo) | Máximo 2 sin mux | Ilimitado (un CS por sensor) | SPI más allá de 2 sensores |
| Inmunidad al ruido | Bordes RC de drenaje abierto | CMOS push-pull, bordes afilados | SPI |
| Complejidad del firmware | Máquina de estado, ACK/NAK, tiempos de espera | Afirmar CS, cambiar bytes, listo | SPI (metal desnudo); Empate (con HAL) |
| dificultad de depuración | Más difícil: caza NAK | Más fácil: señales sencillas | SPI |
| Power consumption | ~0,7 mA (dominadas activas) | ~0 mA (sin dominadas) | Empate: delta es picovatios-hora |
| Tendidos de cables | No recomendado >200 milímetros | Tolera trazas más largas. | SPI |
| External components | 2 × resistencias pull-up | Ninguno | Empate — 2× 0402 resistencias ≈ $0.002 |
TL;DR
¿No estás seguro de qué interfaz se adapta a tu diseño? Cuéntenos su MCU, las limitaciones de su placa y su entorno; le indicaremos la pieza correcta, normalmente en una hora.
Ponte en contacto →
