¿Por qué la gente usa los comandos AT en la comunicación serial?

¿Necesito saber por qué las personas en sistemas integrados usan comandos AT?
Cuando he preguntado a la gente dice que es un estándar.

Entonces mi pregunta es: ¿Qué significa "AT"? ¿Por qué la gente sigue diciendo que es un estándar?

+++ATH0 alguien?
@kinokijuf ¿Qué quieres decir?
why people in embedded systems use AT commands- no hay nada incrustado específico sobre su pregunta o el uso de AT en un enlace serial. Es posible que haya visto esto en un sistema integrado, pero su origen se explica a continuación y no es específico de los sistemas integrados. (Tenga cuidado de no pintar las cosas con un pincel demasiado ancho).
El comando AT incluso se implementó en algo llamado modemu: un programa Unix que crea un dispositivo pseudo-tty maestro/esclavo y simula un módem que en realidad pasa por telnet. Usted "marca" un host con ATD<hostname>. Lo curioso es que ese programa salió casi exactamente en el momento en que lo necesitaba, allá por 1996: la versión 0.0.1. No lo he necesitado desde entonces. ¡Y sigue siendo 0.0.1! Lo usé junto con minicom para hacer transferencias zmodem a través de telnet a hosts remotos a los que solo se podía acceder de esa manera.
@kinokijuf Por favor, no pongas eso en los comentarios. ¡Acabas de hacer que StackOverflow me cuelgue! :-)

Respuestas (5)

Un detalle poco apreciado sobre los comandos "AT" es que muchos módems comenzarían en el modo "auto-baud/auto-parity". Inicialmente, el módem comenzaría sin tratar de decodificar ningún dato en serie, sino que simplemente buscaría un pulso bajo y un pulso alto consecutivos cuyos anchos coincidieran con el mismo período de bit válido (por ejemplo, 3.333ms para 300 baudios, 833us para 1200 baudios, etc. .). Al encontrar eso, verían si el siguiente pulso bajo era cinco veces ese ancho. Si es así, buscarían otro alto-bajo-alto o bien por al menos 1,5 bits de tiempo alto. Encontrar cualquiera de ellos indicaría que el módem acaba de ver un 0x41 o 0xC1 (es decir, "A") de la velocidad de transmisión identificada. Indicaría además que la computadora conectada estaba usando 8-N-1 o 7-E-1, o que estaba usando 7-N-1 o 7-O-1. En cualquier caso, buscaría que el siguiente carácter sea 0x54 o 0xD4 (es decir, "T"). Eso permitiría al módem categorizar aún más la longitud de los caracteres y la configuración de paridad.

Tenga en cuenta que todo lo recibido antes del "AT" sería ignorado. Si se activó el eco, los datos se devolverían a la computadora adjunta simplemente reflejando todas las transiciones de línea sin ninguna decodificación en serie. Si una computadora envió datos antes del "AT" a, por ejemplo, 247 baudios, se repetiría a esa velocidad.

Hoy en día, algunos dispositivos usan una "A" inicial para la detección automática de velocidad en baudios, pero por lo demás, el hecho de que los comandos comiencen con "AT" es básicamente una curiosidad histórica.

ehm... a que te refieres con "7-N-1"??
Siete bits de datos, sin paridad, un bit de parada. Permite que los datos se envíen un 11 % más rápido que 8-N-1, si no se va a enviar ningún dato con el conjunto de bits alto.
Excepto que la transmisión automática en baudios se realizaba (y se realiza) típicamente en la parte +++ de un comando +++AT o +++<guard time>AT. Ver en.wikipedia.org/wiki/Time_Independent_Escape_Sequence
@david: No veo ninguna mención de la transmisión automática en baudios en el artículo de la secuencia de escape independiente del tiempo, ni tampoco he visto un módem que acepte +++ a ninguna velocidad en baudios que no sea la que estaba usando para la comunicación. Los caracteres 0x9E 0x86 enviados uno tras otro a 2400-8-N-1 (o ^N^F a 2400-7-O-1) producirían exactamente las mismas transiciones de línea que un carácter "+" a 1200 baudios, por lo que consideraría "+" como una elección extraña para un carácter de entrenamiento en baudios.
La referencia de Wikipedia (!) fue solo para personas que no saben sobre +++. Hardware que uso trenes en 'U', trenes de software en cadenas personalizadas. ¿Conoces algún estándar? Todas las cadenas de conexión solían iniciar +++, por lo que la transmisión automática se completó antes que cualquier otra comunicación.
@david: He visto UART con funcionalidad cableada para entrenar en "A". No estoy seguro de que me guste "U" a menos que uno pueda estar 100% seguro de que los caracteres "U" repetidos se enviarán sin espacios y no habrá secuencias repetidas de "3" al doble de la velocidad de transmisión adecuada. La "A" tiene la ventaja de que su patrón de pulso no puede ser producido por ninguna cadena de bits a ninguna otra tasa de baudios. Por cierto, una vez hice un proyecto que entrenaba una placa con un reloj descuidado pero sintonizable para la comunicación con una PC a 38400 baudios haciendo que la PC enviara $80 y $C0 alternados a 57600 baudios [con pausas entre].
A 57600 baudios, esos caracteres representan pulsos bajos de 7 u 8 bits. A 38400 baudios, se convertirían en pulsos bajos de 5,33 o 4,67 bits, por lo que ambos deberían recibirse como $F0. Si el receptor obtiene $FC o $F8, es demasiado lento; si obtiene $E0 o $C0, es demasiado rápido. Una vez que obtiene caracteres $F0 consecutivos, está bien.

Hace referencia al conjunto de comandos de Hayes, que ha sido el estándar durante mucho tiempo para emitir comandos a módems (y otros equipos) a través de una línea serie.

En lugar de que los comandos y los datos tengan dos líneas separadas, solo se usa una línea y para cambiar al modo de comando desde los datos se envía una determinada secuencia, por ejemplo, +++ seguido de una pausa de duración determinada. Luego, los siguientes datos son vistos como un comando por el equipo receptor.
La razón para usar algo como esto es el hecho de que evita la necesidad de otro par de líneas, que en muchos casos simplemente no están disponibles, especialmente en pequeños sistemas embebidos.

Eche un vistazo a la página Wiki y los enlaces en la parte inferior: hay muchos detalles allí.

Sin embargo, hay todo tipo de extensiones para el conjunto AT original, por lo que no confiaría en todo lo que menciona AT para usar todos los comandos originales de Hayes. Por ejemplo, aquí tengo un chip serial bluetooth que IIRC usa su propio conjunto de tipos AT.
Sin embargo, no soy un experto en eso, solo recuerdo piratear los comandos en los viejos días de acceso telefónico y BBS.

El conjunto de comandos "AT" fue para resolver un problema de necesidad de información de control fuera de banda sobre el mismo canal de flujo de bytes que se enviaban datos arbitrarios. Este era un problema común de los módems, cuando eran cajas externas conectadas a computadoras a través de un cable serie.

Hayes era un fabricante de tales módems y ganó mucha popularidad desde el principio. Su solución para el problema fuera de banda fue enviar al módem principalmente comandos de control ASCII de dos letras con una secuencia especial para ponerlo en modo de transferencia de datos. Para reducir la probabilidad de que cosas aleatorias parecieran comandos, todas sus secuencias de comandos comenzaban con el comando AT, que significaba "atención".

Hayes ganó tanta participación de mercado que otros fabricantes de módems tuvieron que implementar el mismo conjunto de comandos para ser compatibles. De esa manera, los clientes podían usar sus módems sin tener que volver a escribir el software, que ya estaba configurado para controlar un módem Hayes.

Hoy en día, este esquema rara vez se usa, pero, por supuesto, algo que estaba tan generalizado se mantiene en los rincones oscuros incluso hoy.

Me gustó esta nota histórica sobre Hayes y cómo forzó su propio estándar, concatenar su respuesta con las dos respuestas anteriores es más que suficiente :)
Por cierto, muchos módems más nuevos ya no requieren que los caracteres "AT" estén en mayúsculas, lo que aumenta la frecuencia con la que una desconexión en medio del envío de un archivo de texto provocará un comportamiento erróneo del módem.
El código de control de ruptura de banda es +++AT o +++<tiempo de guardia>. AT son los dos primeros caracteres de un conjunto de control estándar y significa ATtention.

Hay un documento especialmente bueno que describe la historia de los comandos "AT" que se puede encontrar aquí:

http://nemesis.lonestar.org/reference/telecom/modems/at/history.html

Contiene muchas páginas de buena "historia" sobre cómo surgió el protocolo.

¿Por qué las personas en sistemas integrados usan comandos AT?

No soy una de esas "personas en sistemas integrados", pero diría que ATlos comandos todavía están en uso porque provienen de un estándar de baja sobrecarga bien definido para la señalización en línea.

Lo que eso significa es que puede usar el mismo canal de comunicación tanto para señalización (comandos AT para administrar la comunicación) como para datos (datos reales que desea enviar). El ATestándar especifica cómo diferenciar entre los dos para que usted y su dispositivo serie no se confundan al hablar entre sí.

¿Qué significa "AT"?

ATes para atencion

¿Por qué la gente sigue diciendo que es un estándar?

Bueno, porque lo es. Yo diría que en realidad es una mezcla de estandarización de facto y un par de estándares "reales" y algunas recomendaciones .

Esto parece no decir nada que no se haya dicho ya en otras respuestas hace años. Si va a desenterrar una vieja pregunta, realmente debería decir algo importante que no se haya dicho antes.
¿Por qué la gente usa los comandos AT en la comunicación serial?
RespuestasAquíPolítica de privacidad1y, 0v