¿Cómo proceder cuando se necesita un sistema maestro-esclavo I2C personalizado?

¿Cuáles son los criterios de diseño a aplicar?

¿Cuáles son las herramientas de depuración que uno puede usar para solucionar problemas?

Este tutorial que di en la Conferencia Embedded Linux trata de responder las preguntas, proporcionando enlaces a una descripción más detallada de los temas abordados y utilizando el ejemplo práctico de conducir un dron 4WD, donde un Arduino Mini Pro actúa como esclavo y controla las 4 ruedas independientes . El documento original se puede encontrar aquí .

Nota: Esta respuesta está actualmente en progreso, ya que adapto los aspectos más destacados del enlace.

Aplicaciones típicas del bus I2C

• Interfaz con periféricos relativamente lentos. Ej: sensores, actuadores mecánicos.

• Controlando periféricos "rápidos", que usan otros canales para intercambiar datos. Ej: códecs.

  En una PC, el sistema operativo generalmente interactúa sobre I2C con:

  • medidores de temperatura y voltaje de batería;
  • controladores de velocidad del ventilador;
  • códecs de audio.

En caso de que haya varios controladores de bus disponibles, los periféricos se agrupan por velocidad, de modo que los más rápidos no son penalizados por los más lentos.

Una introducción rápida al bus I2C: características clave

• Bus serie
• Solo 2 líneas: Serial CLock y Serial DAta (más tierra).
• 4 velocidades: 100kHz, 400kHz, 1MHz, 3.2MHz.
• Típicamente, 1 dispositivo maestro y 1 o más esclavos.
• Las comunicaciones siempre son iniciadas por un dispositivo maestro.
• Varios maestros pueden coexistir en el mismo bus (multimaestro).
• Drenaje abierto: tanto SDA como SCL necesitan resistencias pull-up.
• "Estiramiento de reloj"
  • El maestro controla SCL, pero un esclavo puede mantenerlo presionado (porque abre el drenaje), si necesita ajustar la velocidad.
  • El maestro debe verificar este escenario.
  • Un esclavo puede atascarse y atascar el bus: es necesario restablecer las líneas del maestro al esclavo.
• Por lo general, el direccionamiento de 7 bits, pero también es compatible con 10 bits.
• Protocolo lógico: los niveles de voltaje reales no se especifican y dependen de implementaciones individuales. Ej: 1.8V / 3.3V / 5.0V

URL de referencia:

• http://www.i2c-bus.org
• http://www.robot-electronics.co.uk/i2c-tutorial

Ejemplo de configuración de bus

Características del Protocolo (simplificado)

• 2 tipos de mensajes: leer y escribir
• Bit de inicio / parada: representado como “[“ y “]” en el resto de la respuesta
• Dirección: 7 o 10 bits
• Bit R / W: R = 1 / W = 0 Se utiliza para discriminar el tipo de mensaje enviado.
• Datos en el bus: (Dirección << 1 | R / W)
• Se registra como manejadores de información, dentro del dispositivo seleccionado.

Ejemplo de tráfico de autobuses

Esclavos personalizados

¿Por qué crear un esclavo I2C personalizado?

• Sensor / actuador deseado no disponible con interfaz I2C.
• Menos direcciones únicas disponibles que los esclavos necesarios.
• Funcionalidad personalizada deseada en el esclavo:
  • Reacciones semiautónomas a estímulos.
  • Filtrado / preprocesamiento de datos de entrada.
• Optimización de energía: el "concentrador de sensores" personalizado se encarga del mantenimiento mientras el procesador principal está inactivo.
• Respuesta en tiempo real a las entradas.
• [tu imaginación aquí]

¿Cómo diseñar un esclavo I2C personalizado?

• Definir requisitos (ver diapositiva anterior).
• Elija microcontrolador o microprocesador.
• Elija Programador o Sistema operativo (si corresponde).
• Definir sub-protocolo de comunicación:
  • Definir parámetros y comandos a intercambiar.
  • Organícelos en "registros" y elija una dirección gratuita.

Diseño del Master I2C

Criterios de diseño clave:

• Peso / Dimensiones.
• Potencia computacional requerida y latencia promedio.
• Dispositivo tipo PC
  • Dispositivo integrado, típicamente sin cabeza.
  • Lenguaje de programación preferido: interpretado vs compilado.
• Disponibilidad de autobuses / gpios para conducir los esclavos:
  • Solo GPIO: bitbang el protocolo
  • I2C: aplicación de espacio de usuario vs controlador de kernel.
  • No hay interfaces GPIO / I2C disponibles: adaptador USB a I2C.

Depuración: divide y vencerás

Tome el control directo del autobús con un dispositivo ad-hoc. Ejemplos:

• Bus Pirate (útil también para otros autobuses)
• Adaptador USB a I2C Master, también basado en el chip FTDI FT232R.
• Dispositivo personalizado (podría ser un proyecto separado).

• Examine el bus con un analizador lógico o un medidor de alcance / avanzado. Ejemplos:

  • sigrok / pulseview con analizador lógico compatible
  • Alcance / medidor independiente de 2 canales

  • Utilice el depurador de circuito / emulador de circuito específico de esclavo.

    Ejemplo: AVR Dragon para chips AVR (Arduino UNO, Nano, Mini, MiniPro)

BUS Pirate

• Principalmente para fines de desarrollo.
• Ambos pueden oler el autobús y conducirlo.
• Interfaz de consola sobre puerto serie (ttyACM), que incluye macros o acceso programático para varios lenguajes de programación.
• Resistencias pullup incorporadas y fuentes de voltaje (5V / 3.3V)
• Admite muchos otros protocolos.
• Referencias: Wikipedia , página principal

Adaptador USB a I2C

• Pequeña huella de pie.
• Apto para instalaciones permanentes.
• No es necesario realizar conexiones especiales en el host: se puede utilizar para interactuar con una PC típica.
• Variante disponible que también es compatible con SPI.
• Sin interfaz de consola, solo protocolo binario en serie.
• Requiere envoltura de protocolo .
• Referencia: protocolo

sigrok y pulseview

logotipo de sigrok (componente de fin de semana)

ejemplo de pulseview (visualizador)

Ejemplo de analizador lógico de gama baja

• Estándar de facto para mediciones controladas por PC en Linux (pero también disponible en otros sistemas operativos).
• Soporte para una amplia gama de analizadores lógicos, ámbitos y medidores.
• Varios decodificadores de protocolo, incluido I2C.
• Útil para visualizar las señales lógicas y los errores del protocolo de depuración.
• Incluso el extremo más bajo, HW de bajo costo puede proporcionar una dimensión completamente nueva para la depuración.
• Referencias: sigrok , pulseview , hardware compatible

Ejemplo: dirigir un dron 4WD

Prototipo construido con 2 Arduino Mini Pro.

¿Qué hace el esclavo en el ejemplo?

El esclavo I2C:

• Controla la cantidad de torque aplicado a cada rueda.
• Controla la dirección en que gira cada rueda.
• Mide la velocidad de rotación de cada rueda a través de un codificador óptico (cuentakilómetros).
• Expone los parámetros anteriores al I2C Master.

Diagrama de bloques de alto nivel del esclavo I2C.

Selección del esclavo: Arduino Mini Pro

• Suficientes pasadores / funciones para proporcionar para cada rueda:
  • 1 salida PWM con configuración independiente del ciclo de trabajo.
  • 1 GPIO para registrar la entrada del odómetro como IRQ.
  • 2 GPIO para seleccionar:
    • Adelante
    • Marcha atrás
    • Ocioso
    • Bloquear
• Bloque I2C HW para intercambios i2c controlados por interrupción.
• Pines dedicados para programación basada en SPI.
• Pequeña huella de pie.
• Bajo costo.
• El diseño de la placa del clon representado en la imagen está optimizado para su montaje en un zócalo DIL.

ICD específico de esclavo: AVR Dragon

• Admite varios modos de programación, incluida la programación SPI, a través de AVRDude .
• No interfiere con las operaciones normales de AVR, por lo que puede dejarse conectado al sistema.
• Después de habilitar la interfaz debugWire, permite configurar puntos de interrupción HW / SW, mediante un backend dedicado para gdb / ddd.

Selección del sistema operativo: ChibiOS

• RTOS: preferencia, tareas, semáforos, tic de sistema dinámico, etc.
• Huella pequeña: el enlace solo utiliza código / datos.
• Distinción entre RTOS y BSP a través de HAL.
• GPLv3 para uso no comercial.
• Desarrollado activamente, pero ya maduro.
• Admite AVR de 8 bits.

Sin embargo, tenía un soporte BSP limitado para AVR, falta de: - interrumpe el controlador para GPIO AVR (agregado). - Soporte I2C para el modo esclavo AVR (personalizado). Que tuvo que desarrollarse por separado como parte del Drone SW para el AVR .

Definiendo los Parámetros de Comunicación

Para cada rueda:

• Ciclo de trabajo de la señal PWM utilizada para controlarlo: 1 byte. 0xFF = par máximo / 0x00 = sin par.

• Dirección de rotación - 1 byte.

  • 0x00 = inactivo
  • 0x01 = reverso
  • 0x02 = adelante
  • 0x03 = bloqueado

• Período promedio entre ranuras del codificador óptico: 2 bytes.

  • Escribir cualquier cosa restablece la medida.

• Índice de parámetros - 1 mordisco:

  • 0 = ciclo de trabajo
  • 1 = dirección
  • 2 = Periodo promedio

• Índices de rueda - 1 mordisco:

  • 0 = trasero izquierdo
  • 1 = trasero derecho
  • 2 = Delantero derecho
  • 3 = Frente izquierdo
  • 4 = todos

Sub Protocolo: Definiendo los Registros

Formato de registro: 0xαβ - α = Índice de parámetro - β = Índice de rueda

Dirección (elegida arbitrariamente): 0x10

Formato de pirata de bus: - [= bit de inicio -] = bit de finalización - r = byte de lectura - dirección veces 2 (desplazamiento a la izquierda 1), para bit R / W

Ejemplo: en formato Bus Pirate

[i2c_addr reg_addr = (parm, rueda) reg_value]

[0x20 0x20 0x02]  Left Rear Forward
[0x20 0x21 0x01]  Right Rear Backward
[0x20 0x22 0x01]  Right Front Backward
[0x20 0x23 0x02]  Left Front Forward
[0x20 0x14 0xFF]  Wheels set to max torque

El auto gira en sentido horario.