¿Cómo organizo una comunicación sólida entre una PC y un microcontrolador?

3

Tengo una Raspberry Pi y STM32F072. Lo que quiero hacer es muy simple: generar muchos datos en la Raspberry Pi y transferirlos al STM32.

Hay varias cosas que son importantes:

  • El STM32 necesita tiempo para procesar datos, por lo que la Raspberry Pi debe enviar datos solo cuando el STM32 está listo para procesarlos.
  • La comunicación debe ser robusta . Con esto quiero decir entrega garantizada y sin errores (debe estar presente algún tipo de corrección de errores). También quiero estar seguro de que la conexión puede permanecer viva indefinidamente.
  • Preferible al menos 1 Mbit / s de velocidad.

Consideré usar SPI, I²C, UART y USB, pero todos comparten un problema común: todos son de un nivel demasiado bajo (nivel 1-2 del modelo OSI) y carecen de control de flujo (por lo tanto, no son robustos ).

  1. ¿Hay implementaciones de algunos protocolos de transporte preferiblemente livianos que se puedan usar?

  2. Si tengo que implementar un protocolo de transporte de este tipo, ¿qué protocolo subyacente será el más sencillo de usar? Aquí están mis pensamientos; corríjame si me equivoco en alguno de estos:

    • UART es simple, pero lento en Raspberry Pi. Creo que puedo usar un convertidor de USB a UART (por ejemplo, ch340) para hacerlo más rápido, pero ¿es una buena idea?
    • SPI es rápido y simple. Sin embargo, hay un inconveniente: Raspberry Pi admite SPI solo en modo maestro, lo que hace que el protocolo sea un poco más complicado.
    • I²C probablemente esté bien, pero no está claro por qué podría ser mejor que SPI en mi caso.
    • El USB es rápido, tiene corrección de errores y entrega garantizada incorporada, pero es muy complejo.
pregunta D. Dmitriy

4 respuestas

4

Creo que SPI sería mi primera opción. I2C y UART son mucho más lentos, el USB es una exageración. 1 MHz no es lento, pero ciertamente es factible para una distancia corta. Es posible que necesite impedancias coincidentes en sus líneas, y un alcance será muy útil para la solución de problemas.

Supongo que los errores son raros. Además de SPI, podría implementar un protocolo de devolución: enviar datos como un bloque grande con una identificación y una suma de comprobación. Con cada intercambio de SPI, el ST devuelve el ID del último bloque recibido con éxito. Cuando eso no coincide con lo que esperaba el RaPi, debe volver a transmitir el último bloque que aún no se ha recibido con éxito.

Cuando un bloque no se recibe correctamente, RaPi lo notará con la transmisión del siguiente bloque, por lo que se pierden dos bloques. Si esto se considera demasiado, el TS podría amortiguar un bloque adicional, o el reconocimiento podría ser superpuesto en una parte de la cola (bytes ficticios) del propio bloque.

    
respondido por el Wouter van Ooijen
2

Usted especificó en los comentarios: "un bit cada 4000 Tb", por lo que es una tasa de error de

(4000 T) -1 = ¼ · 10 -12 = 2.5 · 10 -13

En pocas palabras: eso es tan bueno como lo que se recomienda para los equipos de redes 10GE: lo que encontrará en los centros de datos. No es el Gigabit Ethernet barato que tiene cada computadora portátil.

Los transceptores de red utilizan todo un conjunto de medidas para reducir los errores de bits, incluida la codificación y la corrección de errores, la ecualización y la implementación de la lógica en lógica de hardware simulada y, a veces, incluso verificada formalmente.

Dudo que cualquier cosa que puedas hacer en una Raspberry Pi esté incluso cerca de esa probabilidad de error. La experiencia del desarrollador dice que ni siquiera funciona en un nivel superior, ya que los errores de RAM son más probables que uno en 4000 Tb ; Como, mucho más probable para la memoria RAM barata que utilizará. Además, al elegir su MCU, un Cortex-M0 con reloj de 48 MHz, prácticamente hace imposible tener una importante Corrección de errores hacia adelante (FEC) entre Pi y MCU, con 48 ciclos de CPU por bit, incluso haciendo lo que necesita con su láser, es muy probable que no haya suficiente espacio para la CPU para hacer eso.

Por lo tanto, coincido con Wouter, SPI con la comprobación de errores en la parte superior (el STM320 tiene una unidad CRC, pero eso no es suficiente para FEC) es muy probable que sea el protocolo de elección. Pero sin códigos de canal más complejos y soporte de hardware en ambos extremos, parece un poco improbable que realmente logre una tasa de error de bits de 2,5 · 10 -13 . Por otra parte, afirmaría que esta BER fue sobrestimada en exceso: si tiene un enlace de 1 Mb / s, y transfiere 4000 Tb, le llevará casi 127 años.

    
respondido por el Marcus Müller
2

El convertidor UART < - > UART puede funcionar bien. Le permitirá tener un cable USB largo entre el RPi y su dispositivo, y un enlace UART real de unos pocos centímetros, que funcionará felizmente a 1 o 2 Mbit / s con una tasa de error muy baja. Menciona CH340 que admite 2 Mbit / s baudrate.

Por supuesto, aún deberá tener algún tipo de protocolo para garantizar el control de flujo y la entrega garantizada, y ni siquiera tiene que empezar de cero, reutilizando, por ejemplo. XON / XOFF para el control de flujo de software y XMODEM para notificaciones de entrega. Teniendo en cuenta que su enlace UART tendrá una longitud de unos pocos cm, incluso puede implementar el control de flujo de hardware si tiene 2 pines adicionales en su MCU.

De esta manera, tendrá un software de trabajo en su RPi desde el principio (por ejemplo, minicom ), lo que hará que la depuración de su sistema sea mucho más fácil, en comparación con la solución en la que desarrolla software completamente nuevo en ambos lados.

    
respondido por el Dmitry Grigoryev
0
  

Preferible al menos 1 Mbit / s de velocidad.

SPI puede hacer eso fácilmente.

A medida que aumenta la velocidad, puede considerar DMA en el STM, o el uso de esquemas paralelos.

En ese momento, la adquisición de datos en el STM es probablemente el cuello de botella.

    
respondido por el dannyf

Lea otras preguntas en las etiquetas