Comunicación rápida

Hola a todos, tengo una consulta, resulta que estoy haciendo un proyecto en el cual necesito una conexión arduino-pc rápida. Quisiera saber cual es la más rapida, usb, ethernet, tcp, wifi, bt etc...

Con rápida me refiero a la que tenga menor tiempo de comunicación entre mensajes, no cantidad de mbps, ya que solo enviaré comandos en array de carácteres, de no más de 5 elementos:

El pc envia lo sig:
C####
C = un comando, que realmente es solo 1 carácter, que viene a ser [a-zA-Z]

= argumentos del comando que son [0-9] los # pasan por carácteres :wink:

Arduino envia solo 2:
rc
Donde
r = respuesta que es 3 estados 0,1,2 donde 0 false, 1 es true, 2 contingencia acá tambien los # pasan por carácteres.
c = codigo de respuesta que es solo 1 carácter [a-zA-Z0-9] los # pasan como carácteres :wink: . el cual dependeniendo su valor mostrará en pc un mensaje en la base de datos, los campos de esta seria
mensaje | codigo

Si se fijan son pocos carácteres

5 pc->arduino
2 arduino->pc

Pero la idea es que la comunicación demore lo menos posible entre mensajes, si es asincrona o sincrona realmente no es relevante en cuanto a mi consulta.

Espero puedan orientarme un poco.

Ahh y mis hardwares

Tengo un arduino mega
Y bueno mi pc tiene USB 3.0 y una tarjeta ethernet bastante rápida, compré el pc hace muy poco, es bastante actual.

En cuanto a módulos externos para arduino tengo bastante capital como para comprar un buen módulo de conexión si fuese necesario.

Saludos

Y cual es el problema de la rapidez? Tienes que iniciar una cuenta en milisegundos?
No veo la razón porque cualquier opción bien implementada reacccionará rápido.

Empezando por USB a 115200 bps por ejemplo.
No depende de la velocidad, depende del resto del código y de lo que hará y cómo lo hará.

Veo que sabes de lo que hablas asi que tal vez no te este entendiendo debidamente.

Buena indicación cuantificar lo que pido, ideal llegar a los >=20ms entre mensajes.

El programa realmente no es muy complejo, no tiene muchos procesos pero ideal es llegar a ese rango.

Crearía que estas en rango con 15 mseg de sobra pero… si I2C se queda corto tendras que usar SPI.

surbyte:
No depende de la velocidad, depende del resto del código y de lo que hará y cómo lo hará.

También concuerdo; especialmente por el lado del Arduino que siempre tiene las de perder en cuanto a poder de procesamiento, comparándolo con un PC.

Por ese lado, el código debe estar optimizado (en función del tiempo más que de consumo de RAM).
Una vez resuelto ese problema, ahora sí podemos preocuparnos por el medio de comunicación.

Para bajas latencias, no hay nada como el cable (hasta cierto mínimo de calidad); la comunicación inalambrica, por naturaleza, es más propensa a interferencias; por esta razón, los protocolos utilizados para dicho medio deben garantizar integridad en los datos, "aislamiento" en cada una de las conexiones existentes y muy probablemente hasta encriptación.
Todo ese sobrecargo perfectamente puede rebasar los 20 ms, y ni que hablar cuando la interferencia es excesiva o la señal es débil. Solo los RF genéricos de 433 MHz no poseen dicho sobrecargo; pero a falta de un protocolo que brinde confiabilidad, operan a una velocidad tan baja que... transmitir 5 bytes tomaría 14 ms (asumiendo que se utilice únicamente el protocolo UART en configuración 8N1 y a alrededor de 4000 bps), nada mal excepto que de ida (5 bytes) y vuelta (2 bytes) serían los 20 ms (o más dependiendo del procesamiento adicional).
Cualquier medio inalámbrico sería aceptable si se toleran hasta 200 ms de latencia (es lo más cercano al peor caso)

Ya si hablamos de conexiones cableadas, es difícil decir cuál es mejor.
Con el riesgo a equivocarme, me atrevo a decir que USB tiene menor latencia que Ethernet; sin embargo es difícil decirlo para tu aplicación porque Ethernet, a pesar de tener tres protocolos más encima (MAC, IP y TCP/UDP; Wi-Fi también los tiene de hecho), la latencia suele ser de 1 a 15 ms si estamos en una misma red local.

Por lo tanto, mi recomendación para bajas latencias (aparte de optimizar el código) es usar cable; pero nada extravagantemente largo porque si no se degrada la señal y posiblemente volvamos al problema original.

20ms es una carreta, si no hago mal las cuentas:

A 3600 bps transmitiendo 8n1 (son 10 bits) es decir 360 caracteres por segundo, como son necesarios 5 caracteres, da como resultado 72 mensajes por segundo, que son como 14 ms por mensaje.

Gracias por las respuestas. Miren el programa es super sencillo de hecho no ocupa librerias externas, no ocupa mucha memoria y pocos procesos lo que me interesa es la vel.

Ya que 20 es carreta y se puede llegar a 14ms.
Cual seria el mejor método de comunicación.

Una cosa que no explique es que el programa del pc está hecho con C. Supongo que eso hace que sea más potente.

Si te dicen que a 3600 bps tendras 14 ms por mensaje, entonces si vas a 38400 tardarás < 1.4mseg y si usas 115.2Kbps menos aun o digamos 3 veces menos.

Prueba entonces con una simple comunicación serie a 115.2kpbs y evalúa los resultados.

A lo que hay que agregar que la comunicación serie es full-duplex, con lo que en el mismo tiempo que se está recibiendo un mensaje se puede estar contestando simultáneamente el anterior.

PeterKantTropus:
transmitiendo 8n1 (son 10 bits)

Yo tenía entendido que en UART siempre son dos bits de inicio, entonces lo calculé a 11 bits por byte/trama.

Los RF de 433 MHz, según hoja de datos, se recomienda máximo 4 Kbit/s; no poseen ningún protocolo que resguarde la integridad ya que sólo transmiten el estado digital del pin del emisor (si lo hace por modulación ASK, con más razón). En otras palabras, es como una línea digital, pero inalámbrica; también es la forma más simple de controlar un LED, sin cables.

OldTatita:
Miren el programa es super sencillo de hecho no ocupa librerias externas, no ocupa mucha memoria y pocos procesos lo que me interesa es la vel.

Si es así como lo describes, el tiempo de procesamiento podría ser de medio milisegundo. Cuanto más tenga que hacer, más latencia introduces.

OldTatita:
Ya que 20 es carreta y se puede llegar a 14ms.
Cual seria el mejor método de comunicación.

Yo antes había recomendado USB; es que Ethernet aún cableado, va a depender de lo cargada que esté la red local, además de que la latencia promedio es de 10-12 ms.

OldTatita:
Una cosa que no explique es que el programa del pc está hecho con C. Supongo que eso hace que sea más potente.

Programar en C es programar específicamente para un sistema operativo; así que debería rendir mejor que programar en lenguajes más portables como Java, y todavía mejor que Python. Aún así, si el sistema tiene un procesador de un único núcleo y muchos procesos activos, sí sería preocupante (por el tiempo compartido, se podría tardar algunos milisegundos solo en responder al evento de transmisión y recepción).
Hoy en día para que eso se dé, tendrías que usar máquina virtual o una computadora de al menos 15 años de antigüedad.

noter:
A lo que hay que agregar que la comunicación serie es full-duplex, con lo que en el mismo tiempo que se está recibiendo un mensaje se puede estar contestando simultáneamente el anterior.

Eso refuerza mi recomendación sobre el USB entonces.
Repito: Ethernet es igual, solo que con 3 protocolos más encima.

surbyte:
Si te dicen que a 3600 bps tendras 14 ms por mensaje, entonces si vas a 38400 tardarás < 1.4mseg y si usas 115.2Kbps menos aun o digamos 3 veces menos.

También de acuerdo. Solo que lo que se busca es tiempo de respuesta más que velocidad de transferencia.

Por supuesto, la velocidad de transferencia influye en el tiempo de respuesta; pero cuando la cantidad de datos es ridículamente pequeña, afecta más el retraso en iniciar la transmisión (el retraso en la recepción se cuenta si el o los protocolos utilizados lo inducen).