Francamente, ¿por qué todos los circuitos integrados de comunicación (o al menos muchos de ellos o los más famosos o populares) como Bluetooth o WIFI o GSM o etc. soportan el conjunto de comandos AT? ¿Cuáles son las ventajas de utilizar el conjunto de comandos AT?
El conjunto de comandos AT es grande y tomaría tiempo y espacio en la memoria y dificulta la comunicación, mientras que en su lugar se puede utilizar un simple pin D/C y enviar un entero para establecer registros o enviar datos.
Brhans es correcto - Legacy.
En los años 80, Hayes empezó a fabricar el "Smartmodem 1200". Se quedó obsoleto casi inmediatamente y Hayes se apresuró a sacar el Smartmodem 2400. En esa prisa, no hubo tiempo para hacer modificaciones de diseño entre los diseños de los módems. Como resultado, Hayes fue la primera en fabricar dos módems de diferente velocidad que aceptaban los mismos comandos de programación. Cualquier software que pudiera hacer que un Smartmodem 1200 marcara un número de teléfono también podía marcar un Smartmodem 2400.
En aquella época, cada nuevo módem requería meses para escribir un controlador actualizado. Cuando el Smartmodem 2400 salió al mercado, ya existía un controlador que funcionaba para el Smartmodem 1200, por lo que no hubo que esperar meses. De repente, otros fabricantes se dieron cuenta de la ventaja de que los nuevos módems tuvieran el mismo conjunto de comandos que los antiguos. En seis meses, los proveedores ofrecían módems "compatibles con Hayes" como única opción. Lo que les llevó a ser demandados por Hayes. Así que todos empezaron a llamar a sus módems "compatibles con el conjunto de comandos AT", pero siguieron utilizando el conjunto de comandos Hayes.
A mediados de los 80 no se fabricaban módems de consumo que no pudieran utilizar el conjunto de comandos AT. Como resultado, todos los sistemas de comunicaciones tipo módem utilizan comandos AT. También hay otras ventajas: como el conjunto de comandos es ASCII, cualquiera puede escribir manualmente comandos AT en una ventana de terminal para controlar un módem. Debido a que mi propio módem tenía una conexión RJ11 poco fiable, solía empezar cada sesión en Procomm Plus con:
AT
OK
ATH1
[dial tone]
ATDT [phone number]Sólo para asegurarme de que tengo el tono de llamada. Si no lo conseguía, ¡daba la vuelta y movía un poco los cables!
Buen punto sobre la depurabilidad. Un protocolo binario puro (como el flujo de datos de la pantalla LCD) requiere el diseño de hardware/firmware para empezar a hablar con el dispositivo. El conjunto de comandos AT le permite probar el dispositivo con cero hardware. Todo lo que necesitas es un puerto serie (o hoy en día un convertidor de USB a serie) y un emulador de terminal.
Una pequeña objeción... Los Winmodems preservaron la compatibilidad a nivel de APLICACIÓN con los comandos AT, pero rompieron completamente la compatibilidad a nivel de SO. Antes de Winmodem, incluso los módems internos se conectaban a través de una UART 16550A estándar cuyo funcionamiento era bien conocido y soportado de forma transparente por Linux (porque parecían puertos serie ISA o PCI normales para el SO). Los Winmodems han sido un obstáculo al mover la lógica de alto nivel (Lucent) o literalmente todo (HSP) en el conductor. Como el host de comandos AT del Winmodem era virtual, eran literalmente pesos de papel en Linux.
Sí, yo también solía escribirlas manualmente porque tenía una línea telefónica de marcación por pulsos (pero todas las aplicaciones de comunicaciones daban por sentado que todo el mundo tenía tono táctil). :-)
Sólo hablas de las desventajas del conjunto de comandos. Considera los aspectos positivos:
Utilizando el conjunto de comandos AT, su dispositivo de comunicación puede ser puesto inmediatamente en cualquier red IP a través del sistema operativo PPP implementación. La alternativa es que, además de diseñar una interfaz de protocolo personalizada, tienes que escribir tu propio controlador de dispositivo de red para cada sistema operativo que quieras soportar antes de que ese sistema operativo pueda utilizar tu dispositivo para unirse a Internet.
Cualquier ingeniero competente ya conoce este protocolo. Te lo dice alguien cuyo trabajo diario le obliga a entender e implementar docenas de protocolos serie no estándar: un protocolo común bien diseñado es mejor.
Si bien es cierto que el protocolo AT es bastante complejo y requiere más memoria para ser implementado que un protocolo construido para una tarea específica, también es cierto que alguien que elige implementar este protocolo consigue evitar gastar un montón de tiempo reinventando una rueda perfectamente buena. Tiene décadas de experiencia en el diseño. Sabe que funcionará antes de dedicarle tiempo de desarrollo. Un buen diseño de protocolo es sorprendentemente difícil.
(Uno de estos días, voy a publicar mi obra magna, "Tu protocolo apesta", con la esperanza de prevenir la perpetración de más protocolos terribles a medias).
Aunque estoy de acuerdo con el sentimiento; ¿"bien diseñado"? Tres palabras: el ATS comando...
La mayoría de los dispositivos que he visto que utilizan los llamados comandos "AT" tienen nada en común entre sus conjuntos de comandos, aparte de los dos primeros caracteres. Si un módulo WiFi pudiera aceptar "ATDT192,168,254,5W1234" como comando para abrir una conexión TCP al puerto 1234 en 192.168.254.5, entonces el software que espera un módem podría utilizar el módulo sin problemas, pero todavía no he visto ninguno que haga algo así.
@supercat: Eso es porque un módem WiFi es más parecido a una tarjeta Ethernet, como se puede ver en los estándares correspondientes (serie IEEE802) y el uso de direcciones MAC. Y aunque en la pregunta se habla de "IC de comunicación" no creo que los IC de Ethernet de coomon utilicen el conjunto de comandos AT.
Voy a ampliar la otra parte de la pregunta... ¿por qué no añadir otra línea de señalización a la interfaz?
Eso sólo se lo puede preguntar alguien que no haya vivido todas las permutaciones de líneas de señalización en una auténtica interfaz RS232 de 25 pines. Además de TXD, RXD y Gnd, ya había otros pares de señales, RTS/CTS (Ready to Send, Clear To Send) DSR/DTR (Data Set Ready, Data Terminal Ready) y un pin hardware de Hangup. Y otros. Y no hay un acuerdo universal claro entre los fabricantes sobre qué hacía qué función - ¿por qué se necesitaban dos conjuntos de señales hardware de handshaking en primer lugar? Y un protocolo de software XON/XOFF encima) (¿Y por qué las impresoras Diablo insistieron - de forma única hasta donde yo sé - en el handshaking en el pin 11?)
Algunos equipos requerían una interfaz completa. Algunos se conformaban con TXD/RXD/Gnd. A algunos se les podía engañar para que funcionaran cortocircuitando los pines 4 y 6 (haciendo así un bucle de su propio RTS a CTS). Y algunos que debían ser DCE eran DTE o viceversa y sólo se comunicaban con cualquier otra cosa a través de un cable de "módem nulo" con cada par de conexiones intercambiadas.
Luego, para simplificar todo esto, el PC de IBM introdujo una nueva interfaz de 9 pines para RS232. Lo que significaba que toda tu colección de cables estaba obsoleta y tenías que empezar de nuevo...
Todo ello nos complicaba la vida incluso sin tener en cuenta que ambos extremos podían estar configurados con diferentes velocidades de transmisión...
De este modo, se creó toda una industria en torno a las cajas de conexión RS232, los cables y las herramientas de prueba y depuración.
Añadir otra señal, en este contexto, probablemente no iba a volar...
El primer módem Hayes que utilizó los comandos "AT" eligió la "A" como primer carácter de su prefijo de comandos porque necesitaba admitir múltiples velocidades de transmisión, y la "A" en la línea se parece: -------_-_____-x---------- que tiene una relación de 5:1 entre los tiempos "bajos" más largos y los más cortos (la "x" puede ser alta o baja según la configuración de la paridad). Ninguna velocidad inferior a 1200 baudios puede conseguir un tiempo "corto" de 833us o menos, y ninguna velocidad superior a 2400 puede conseguir un tiempo "largo" de 4,16ms o más, por lo que un módem puede asumir con seguridad que si ve algo que parece una "A" de 1200 baudios, lo es (y lo mismo con 300 baudios, etc.). La "T" tiene la paridad opuesta a la "A", por lo que si el segundo carácter se parece a una "T", el módem puede mirar el bit superior de esa y la "A" y distinguir entre 7-E-1, 7-O-1, 7-N-1 y 8-N-1.
Dispositivos o controladores que utilizan comandos "AT" que funcionan de forma similar o análoga a los comandos del módem Hayes (por ejemplo, aceptar ATDTW192,168,254,123W4567 como un comando para conectarse al puerto 4567 de 192.168.254.123) lo hacen por compatibilidad con el software que espera hablar con un módem de estilo antiguo o un dispositivo compatible. Sin embargo, hay muchos dispositivos que utilizan comandos que empiezan por "AT" con la teoría de que el "conjunto de comandos AT" parece ser una palabra de moda de marketing útil, a pesar de que los dispositivos no son capaces de detectar automáticamente la tasa de baudios y tienen comandos diferentes a los de cualquier otro dispositivo. El uso de "AT" como prefijo de comandos en estos contextos no añade ningún valor de compatibilidad y no tiene ningún propósito útil; los diseñadores lo hacen porque han visto a otros diseñadores hacerlo, aunque ninguno de los diseñadores en cuestión tenga idea de por qué.
I-Ciencias es una comunidad de estudiantes y amantes de la ciencia en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros usuarios, hacer tus propias preguntas o resolver las de los demás.
18 votos
Una palabra: Legado ... Todos pretenden ser módems compatibles con Hayes y lo han sido desde el principio de los tiempos (o al menos desde los años 80, que es prácticamente lo mismo). Y no, no es una buena razón.
0 votos
@brhans Lo más probable es que tengas razón.
4 votos
No sólo el legado, sino un realmente buena idea. Como dice el viejo refrán: "Lo maravilloso de los estándares es que hay muchos para elegir". Quiero que mi hardware y mi software funcionen con cualquier módulo de comunicaciones que esté utilizando sin tener que preocuparme de si habla un idioma diferente (conjunto de comandos) del que estaba usando antes.
7 votos
XKCD obligatorio aquí .
1 votos
En teoría, podrías desenchufar tu módulo WIFI y sustituirlo por uno de otro proveedor. Y como el protocolo es el mismo, ni siquiera tienes que ajustar el código.
0 votos
@FuaZe ¡Buena observación!
0 votos
Ohhhh este dolor implementando el conjunto de comandos AT en una comunicación de dispositivo a dispositivo donde todos los errores y respuestas tienen que ser procesados. No hay suma de comprobación, no hay encuadre de comandos, no hay consistencia. Un dispositivo compatible con comandos AT que utilicé lo hizo bien y añadió un protocolo "binario" adicional para facilitar la comunicación M2M.
1 votos
Si algo va mal en la comunicación/los bits no obtendrás la respuesta correcta, es decir: "OK" Así que si lo manejas como corresponde, es bastante estable. Es bastante fácil de depurar, ya que los mensajes tienen algún sentido. El manejo, sin embargo, es un poco más difícil de implementar. Tienes que comprobar dichos mensajes. Y leerlos, de una manera que no es regular para un MCU. Pero de nuevo, si haces esto una vez, funcionará para otros dispositivos AT.