Módulo Wi-Fi transparente con entrada RMII

1

Necesito convertir un proyecto integrado conectado a Ethernet con una conexión inalámbrica.

Estoy buscando un módulo de puente de Wi-Fi de bajo costo (principal restricción, menos de USD $ 15) y la mayoría de fuente abierta / hardware posible, como Vonets.

Debe comportarse de manera transparente, redirigiendo todas las tramas de red (capa de transporte) a la pila IP existente y ya estable implementada en el hardware ETH actual con una modificación mínima del firmware; si es posible, utilizando pines RMII existentes.

Mi primer intento fue con ESP8266, pero hay algunos desafíos muy dolorosos:

  • No podría simplemente cambiar el transceptor y el RJ-45 con él, porque su comunicación está basada en UART (algunas variantes de módulo admiten SPI). Para solucionar esto, intenté habilitar PPPoS para comunicar uC < - > ESP8266, luego enviar datos a través de la pila IP incorporada de ESP y reenviarlos al adaptador de Wi-Fi y luego a Internet.

Sin embargo, aunque el puerto LwIP tenía PPP_SUPORT # define en el código fuente (que parece haberse agregado en una versión reciente v1.4.0 de marzo de 2016), no hay documentación sobre cómo habilitarlo y su uso. Además, el reenvío de IP tampoco parece ser compatible entre la interfaz virtual (por ejemplo, ppp0) y la interfaz "real" (por ejemplo, wlan0).

  1. ¿Sugiere algún otro hardware para hacer el trabajo del "puente de Wi-Fi"? ¿Debería ESP32 (no lanzado todavía en este momento) la solución para convertir señales RMII?
  2. En el caso de seguir usando ESP8266, ¿hay otro protocolo o forma de hacerlo transparente?
pregunta Luís Rigoni

1 respuesta

3

Aunque en principio es posible, MII no se utiliza realmente para interconectar PHY inalámbricos, porque todas las pequeñas diferencias se suman.

  • 802.11 tiene diferentes brechas entre tramas para diferentes clases de tráfico para darle un esquema de prioridad bruto
  • MII solo transporta los datagramas de los usuarios, por lo que la asociación y la autenticación tendrían que ser transportadas sobre MDIO.
  • La dirección MAC de destino en 802.11 es el siguiente salto inalámbrico, no la dirección del siguiente salto de enrutamiento, por lo que el paquete debe reescribirse, moviendo el siguiente salto de enrutamiento al primer campo de dirección auxiliar y agregando la dirección AP
  • ...

Básicamente, la PHY necesitaría replicar toda la lógica MAC, y el esfuerzo de implementar la comunicación del canal lateral sería mayor que el ahorro que supone reutilizar la interfaz MII.

Las razones principales para usar el controlador Ethernet MII integrado serían usar el filtro de multidifusión y la clasificación por tamaño de paquetes en dispositivos con memoria limitada. El filtro de multidifusión debe ser replicado en el PHY, debido a la forma en que se adjuntan los paquetes de multidifusión a la baliza, y el clasificador de tamaño de paquete solo es relevante para dispositivos muy pequeños, donde una integración más estrecha y una huella más pequeña son aún más importantes que la facilidad de implementación .

    
respondido por el Simon Richter

Lea otras preguntas en las etiquetas