20 min. Cada bus existe porque alguien tuvo un problema que los otros no resolvían. Ese es el hilo de la sesión.

Los seis buses y su razón de existir

Bus Existe porque Límite duro En el coche
UART dos dispositivos, sin reloj compartido, cableado mínimo punto a punto; ambos extremos deben coincidir en baud GPS MAX-M10S (UBX 5 Hz)
RS-485 el ruido industrial mata las señales de un solo cable half-duplex, requiere terminación de 120 Ω candidato para sensores lejanos del chasis
I²C muchos dispositivos con solo 2 hilos direcciones fijas y colisionables; ~1 m de cable MPU6050, AS5600 ×2 (vía mux)
SPI hace falta ancho de banda, no ahorro de pines 1 CS por esclavo microSD, radio SX1262
1-Wire un solo cable de datos y hasta alimentación parásita lentísimo; ~750 ms por conversión a 12 bits DS18B20 motor y CVT
CAN varios nodos que hablan sin maestro y toleran fallas necesita transceptor; trama corta (8 B clásico) a futuro, si el nodo se parte en dos

Los tres ejes de decisión

  1. ¿Cuántos hablan? Uno a uno → UART/SPI. Muchos con un maestro → I²C/1-Wire. Muchos sin maestro → CAN.
  2. ¿Qué tan lejos y con cuánto ruido? Más de ~1 m o cerca del motor → diferencial (RS-485/CAN). Dentro de la caja → single-ended.
  3. ¿Cuántos bytes por segundo? Calcular antes de elegir: bytes/s = tasa_muestreo × bytes_por_muestra × n_sensores. Si eso pasa del 50 % de la capacidad del bus, el bus está mal elegido.

Sincronía: el punto que se olvida

UART no lleva reloj: los dos extremos acuerdan un baud y muestrean a ciegas. Un error de más de ~2 % desalinea el bit de stop y sale basura — no un error limpio, basura silenciosa. I²C y SPI llevan reloj explícito (SCL / SCK) y por eso no tienen ese modo de falla.

💡 Regla de la sesión: "sale basura pero sí llegan bytes" casi siempre es un problema de velocidad o de niveles, no de código.

Bibliografía