stringtranslate.com

Discusión:Receptor-transmisor asíncrono universal

Papas fritas

Los compatibles con IBM PC utilizaban el National Semiconductor 8250, no el chip serial de Intel, porque los chips National tenían generadores de velocidad de transmisión programables integrados. Los sucesores también fueron fabricados por National. Este artículo también necesita un diagrama de bloques de un UART. -- Wtshymanski 05:58, 13 de abril de 2005 (UTC)

Hice un diagrama del esquema de codificación. No sé si eso es lo que querías decir, pero me gustaría que alguien lo integrara en el artículo por mí; temo que no podría hacerlo correctamente. El diagrama está aquí. RT Jones ( discusión ) 00:18 5 nov 2008 (UTC) [ responder ]

RS 232 y así sucesivamente

Estas normas se analizan en sus propios artículos; el UART puede interactuar con las líneas de control de una interfaz RS 232 pero no genera directamente los niveles de voltaje que salen por el cable. -- Wtshymanski 17:49, 17 de mayo de 2005 (UTC) [ responder ]

Consejos de programación para PC

"INT 14" es totalmente específico de IBM-PC y no es apropiado para un artículo general sobre UARTS. He movido las siguientes líneas aquí, pero no creo que pertenezcan a este artículo. -- Wtshymanski 18:57, 24 de febrero de 2006 (UTC) [ responder ]

Registros comunes

En la mayoría de los chips UART, los registros se agrupan en 3 categorías:

  • Registros de datos : Registro de búfer del receptor (RBR), Registro de retención del transmisor (THR), Registro de almohadilla de raspado (SCR)

  • Registros de control : Registro de selección de velocidad de bits (DLL/DLM), Registro de control de línea (LCR), Registro de control de módem (MCR), Registro de habilitación de interrupciones (IER), Registro de identificación de interrupciones (IIR)

  • Registros de estado : Registro de estado de línea (LSR), Registro de estado de módem (MSR)

    • Descripción

  • Los circuitos RBR en el chip 8250 son programables para trabajar con 5, 6, 7 u 8 bits de datos.
  • THR se utiliza para almacenar datos paralelos temporales en espera de ser convertidos en una secuencia de bits.
  • En un chip 8250, el SCR de lectura/escritura no se utiliza
  • LCR se utiliza para controlar el formato de los caracteres de datos.
  • El LSR suele ser el primer registro que lee el microprocesador. Este registro se utiliza para indicar los errores que puedan producirse, si los hay, así como el estado de la operación actual.
  • MCR se utiliza para controlar la interfaz con el módem/conjunto de datos
  • MSR proporciona al microprocesador el estado de las líneas de entrada del módem

    • Además, en algunos manuales de hardware, DLab se refiere al último bit (bit 7, o el bit más significativo) del Registro de control de línea (LCR).

    Pasos básicos en la programación del puerto serie que involucra el UART

    El software deberá inicializar primero el puerto serie. Después de una inicialización exitosa, todas las operaciones en el puerto serie se transferirán al chipset UART, que las gestionará. Los pasos básicos se resumen a continuación:

  • Inicialice el puerto serial. Para ello, debe llamar a la interrupción 14h o escribir datos en el puerto directamente a través de su dirección. También es importante que el software configure el formato de datos (usando LCR) y la velocidad de transferencia de datos (usando MCR).
  • Protocolo de enlace de primer nivel (o a nivel de dispositivo) . El software y el hardware indicarán que están listos para la operación. Esto incluye el envío de señales de terminal de datos lista ( DTR ) y conjunto de datos listo ( DSR ).
  • Protocolo de enlace de segundo nivel (o de nivel de datos). Ambas partes indican su disposición para el proceso de transferencia de datos. El software y el hardware enviarán señales de solicitud de envío ( RTS ) y de autorización de envío ( CTS ) respectivamente.
  • Durante el proceso de transferencia, tanto el software como el hardware deberán asegurarse de que THR esté vacío antes de enviar cualquier dato y que RBR esté listo antes de leer cualquier dato de él.

    • Baudios frente a bps

    Del artículo:

    Las velocidades de los UART se expresan en bits por segundo (bit/s o bps), aunque a menudo se las denomina incorrectamente velocidad en baudios.

    Del artículo de Baud:

    En telecomunicaciones y electrónica, baud [...] es una medida de la velocidad de símbolo [...] Los primeros módems operaban sólo a un bit por símbolo, por lo que la velocidad en baudios y la velocidad de bits de esos dispositivos eran equivalentes.

    ¿La segunda cita no contradice la primera? Los UART tienen 1 bit por símbolo y, por lo tanto, su velocidad en baudios debería ser igual a su velocidad en bps. Por lo tanto, se debería cambiar la primera cita. (Sólo estoy de paso). 129.241.129.67 20:40, 15 de junio de 2007 (UTC) [ responder ]

    Sí, para un UART, la velocidad de bits y la velocidad en baudios son las mismas. Para una señal analógica que emplea modulación, como la que se utiliza con los módems en la red telefónica pública conmutada, normalmente se codifica más de un bit en una señal, por lo que la velocidad en baudios suele ser mucho menor que la velocidad de bits. -- Brouhaha 07:11, 16 de junio de 2007 (UTC) [ responder ]
    RS-232 permite dos niveles, por lo que en el cable los baudios son bits por segundo. Y también, los pines de envío/recepción en el UART. La distinción es importante para la señal que sale por la línea telefónica para los módems, pero eso no se aplica aquí. Gah4 ( discusión ) 18:56 12 abr 2023 (UTC) [ responder ]

    pronunciación

    Alguien dio una pronunciación de OO-wuh AT. Pensé que era extraño, así que lo edité. Reemplace si estoy equivocado: hay una clave del AFI en inglés en {{ IPA-en }} . kwami ​​06:16, 16 de octubre de 2007 (UTC) [ responder ]

    Intercambio

    Una transmisión asincrónica no envía nada a través de la interconexión cuando el dispositivo transmisor no tiene nada que enviar; pero una interfaz sincrónica debe enviar caracteres de "relleno" para mantener el sincronismo entre el receptor y el transmisor. Los dos modos deben intercambiarse, ¿no es así? Sevcsik 20:12, 27 de octubre de 2007 (UTC) [ responder ]

    He modificado el artículo para que ahora diga " Una transmisión asincrónica no envía caracteres a través de la interconexión cuando el dispositivo de transmisión no tiene nada que enviar ".

    Tomemos el caso en el que un USART se quedó sin cosas para enviar, pero luego, 3 tiempos de bit normales después, se le dio una "W" para enviar. Todos los transmisores asincrónicos que he estudiado no envían nada cuando no tenían nada para enviar; en algunos casos, "desconectan" el hi-Z del medio de transmisión, literalmente no envían nada; en otros casos, transmiten continuamente el "bit de parada lógico 1" hasta que tienen algo más para enviar. En este caso, el UART enviaría 3 bits de parada (en lugar del 1 bit de parada normal entre caracteres), luego, cuando el carácter "W" llegara de repente, enviaría el 1 bit de inicio y luego comenzaría a enviar los bits de datos que forman la "W". Esos 2 bits de parada "adicionales" ayudan a mantener el sincronismo, pero no se consideran un "carácter" completo.

    He visto algunos protocolos de transmisión sincrónica que simplemente dejaban de transmitir esos pulsos de reloj de 3 bits cuando no tenían nada que enviar, lo que parece contradecir el artículo.

    Sin embargo, todos los USART que he estudiado (que es el foco de este artículo, ¿no?) se ajustan a la descripción del artículo. Todos transmiten continuamente pulsos de reloj de bits a una velocidad constante, tengan o no algo que enviar. Si un transmisor sincrónico de este tipo comenzara a enviar inmediatamente los pulsos de reloj de bits "W" 3 después del último byte enviado, entonces el receptor perdería la alineación de bytes. Por lo tanto, en la práctica, -- en modo sincrónico -- el USART debe comenzar inmediatamente a enviar el carácter "relleno" después de enviar el último bit de datos reales; luego retrasa el envío de la "W" hasta que se hayan transmitido los 8 bits de ese carácter de relleno, y así mantiene la alineación de bytes.

    Algunos protocolos de nivel superior (especialmente cuando la comunicación se realiza a través de enlaces de radio ruidosos, en lugar de enlaces cableados) envían caracteres de relleno adicionales para mantener el sincronismo entre el receptor y el transmisor, independientemente de si el hardware subyacente utiliza transmisión sincrónica o asincrónica. Estos caracteres de relleno (incluso cuando el hardware subyacente utiliza transmisión asincrónica y, por lo tanto, no los necesita para mantener la alineación de bytes) ayudan al protocolo de nivel superior a mantener la alineación de paquetes (¿qué byte es el comienzo del paquete?) y también pueden ayudar al hardware subyacente a mantener la alineación de bits (¿son exactamente 7 ceros seguidos u 8 ceros?).

    ¿Eso responde a tu pregunta? -- 68.0.124.33 ( discusión ) 17:07 16 jul 2008 (UTC) [ responder ]

    Mi experiencia con los USART cuando funcionan de manera sincrónica es que los datos de "relleno" son innecesarios. Además, cuando funcionan de manera sincrónica, seguirán incluyendo los datos de trama: los bits de inicio, de detención y de paridad (opcional).

    Los caracteres "pad" son innecesarios ya que, al igual que cuando se opera de forma asincrónica, la línea de transmisión se mantendrá en estado inactivo. Y, al igual que cuando se opera de forma asincrónica, se utiliza un bit de inicio para indicar una condición de inicio de envío.

    Un USART que funciona de forma sincrónica funciona de forma muy similar a un UART tradicional, con la excepción de que los dos extremos de la transmisión comparten el mismo reloj de transmisión. Un extremo actúa como maestro y genera una señal de reloj que comparte con el esclavo. El esclavo luego usa esta señal de reloj externa para la sincronización al enviar y recibir. Los dos extremos aún deben acordar qué formato de trama se utilizará, pero ya no necesitan acordar una velocidad en baudios, ya que esta está determinada por la señal de reloj generada por el maestro.

    Al operar de manera sincrónica, los dos extremos deben acordar qué borde del reloj se utilizará para el muestreo de datos y qué borde del reloj se utilizará para cambiar los datos.

    La señal de reloj que genera el maestro seguirá funcionando incluso cuando no esté enviando datos. Esto es necesario para que el esclavo pueda transmitir datos al maestro. Imagino que algunas implementaciones pueden detener el reloj si el maestro no recibe datos del esclavo, pero no lo sé con certeza. -- 99.179.69.42 (discusión) 10:53 24 feb 2010 (UTC) [ responder ]

    Preguntas

    ¿Es entonces UART similar a RAMDAC (en tarjetas gráficas y tarjetas sintonizadoras de TV), excepto que traducen de digital a analógico, mientras que UART traduce de paralelo a serie? -- Ramu50 ( discusión ) 17:36, 18 de julio de 2008 (UTC) [ responder ]

    No. Al menos no en un sentido más fuerte que el de las ovejas, que son similares a los peces, excepto que dan leche. -- Wtshymanski ( discusión ) 20:54 18 jul 2008 (UTC) [ responder ]

    roflmao....leche ¿Vienen en forma de yogur de leche materna humana... (bofetada en la cara) bromeando, bromeando -- Ramu50 ( discusión ) 00:01 21 jul 2008 (UTC) [ responder ]

    Sí. Existen varias similitudes entre un UART y una combinación de un RAMDAC de tarjeta gráfica y un ADC de tarjeta sintonizadora de TV. Ambos son circuitos integrados . La CPU envía información: una imagen de mapa de bits al búfer RAM de la tarjeta gráfica, caracteres al búfer de caracteres dentro del UART. Luego, el chip envía esa información a un ritmo constante, una condición significativa a la vez. La tarjeta gráfica también agrega un "marco" de señales HSYNC y VSYNC, análogo a los bits de encuadre de "inicio" y "detención" generados por el UART. Las señales que salen de los pines UART o pines RAMDAC fluyen hacia un controlador de línea , y las señales del controlador de línea a su vez fluyen típicamente hacia algún tipo de conector D-sub conectado a un cable hacia el mundo exterior.
    En el receptor, las señales entrantes pasan a través del conector a un amplificador analógico; la salida del amplificador fluye hacia los pines UART o del decodificador de TV.
    La tarjeta sintonizadora de TV utiliza HSYNC y VSYNC para sincronizarse con el transmisor y descubrir el principio y el final de la imagen, de forma análoga a la forma en que el UART receptor utiliza los bits de encuadre para sincronizarse con el transmisor y descubrir el principio y el final del carácter. Ambos sistemas tienen una pequeña memoria intermedia para almacenar los datos. Con ambos sistemas, la CPU normalmente extrae los datos de ese búfer y los almacena en un disco duro.
    Ambos sistemas suelen tener software que maneja fragmentos más grandes de datos y decide dónde comienzan y terminan esos fragmentos (el comienzo y el final de una película para la tarjeta gráfica o sintonizadora; el comienzo y el final de un paquete o un archivo para el UART).
    Aparte de eso, estoy de acuerdo con el autor anterior en que UART vs. RAMDAC son categorías de cosas totalmente diferentes. :-). -- 68.0.124.33 ( discusión ) 02:33 21 jul 2008 (UTC) [ responder ]
    Cierto. Después de todo, en Escocia hay tanto ovejas como peces. Pero hay que esforzarse mucho para encontrar las similitudes y dudo que expliquen bien el funcionamiento de cualquiera de los dos sistemas. -- Wtshymanski ( discusión ) 01:00, 23 de julio de 2008 (UTC) [ responder ]

    Debe configurarse para los mismos ... bits de parada para un funcionamiento correcto

    A excepción de muchos sistemas, si no la mayoría, los bits de parada no tienen por qué ser los mismos, porque no hay nada que regule el nivel de parada. Todo se vuelve a sincronizar en el siguiente bit de inicio. Esa es la belleza de la comunicación asincrónica.

    ¿Existe algún ejemplo de un sistema que requiera que los bits de parada se configuren de la misma manera? Cámbialo si me equivoco.

    Piense en esto. Si el extremo emisor envía un bit de parada más corto que el que espera el receptor, el receptor nunca estará listo para un nuevo carácter a menos que haya intervalos entre los caracteres transmitidos. El receptor necesita al menos el tiempo del bit de parada para reconocer el final de un carácter. Supongo que si el emisor envía un bit de parada más largo que el que espera el receptor, esto funcionaría, pero el enlace sería más lento de lo necesario. Es más preciso decir que los bits de parada deben coincidir en lugar de omitirlos. -- Wtshymanski ( discusión ) 18:09, 8 de agosto de 2008 (UTC) [ responder ]
    Los sistemas que utilizo no se preocupan por la cantidad de bits de parada. Piénselo: si se preocupan por la longitud de la palabra, son un sistema sincrónico, no asincrónico. Los UART se vuelven a sincronizar en el bit de inicio y, si se desincronizan un bit al final del byte anterior, no les importa.
    Estoy usando sistemas físicos que no se preocupan por la cantidad de bits de parada. Sé que la mayoría de los dispositivos físicos actuales no se preocupan por la cantidad de bits de parada (de todos modos, las TTY mecánicas no tenían UART). http://www.atmel.com/dyn/resources/prod_documents/doc2513.pdf. http://ece-www.colorado.edu/~ecen2120/Manual/uart/UART.html,
    Lo que quiero decir es que, si sabes que hay una implementación específica de Windows que requiere bits de parada coincidentes, puedes volver a cambiarlo y confundir a la gente si incluyes la verdad sobre las implementaciones normales actuales. Obviamente, a la mayoría de los módems no les importa la cantidad de bits de parada, pero no cuentan, porque se sincronizan automáticamente de todos modos. Suponiendo que uses comunicaciones en serie en tu PC, ¿importa configurar mal los bits de parada? En el mío no importa: puedo hacer laplink con bits de parada no coincidentes. No importa en ningún hardware actual con el que esté familiarizado, pero si en la práctica pudiera confundir a la gente, estoy dispuesto a dejarlo así. Sin embargo, necesitas encontrar un ejemplo real. —Comentario anterior sin firmar agregado por 150.101.166.15 ( discusión ) 03:12, 12 de agosto de 2008 (UTC)[ responder ]
    No tiene nada que ver con Windows, PC, UART o teletipos mecánicos: imagínese como un dispositivo que observa una línea serial. Acabo de obtener un bit de inicio, cuento los tiempos de bit y ahora tengo mis ocho (o siete o cinco o lo que sea) bits de datos, espero dos bits de parada... de repente obtengo otro borde. ¡Caos! ¿Es este un nuevo bit de inicio? ¿Qué hago con el carácter antiguo? Nunca completó su trama, debo generar un error de desbordamiento. Y, como mínimo, enviar dos bits de parada en cada carácter cuando el receptor solo necesita uno es ineficiente. Si a los TTY mecánicos no les importaban los dos bits de parada, ¿por qué enviaban dos bits de parada? También desconfiaría de cualquier cosa que el software de comunicaciones alojado en PC le diga sobre cómo se configuran los caracteres. Me gustaría verlo en un osciloscopio, porque creo que algún software miente sobre lo que está haciendo. Lo estoy restaurando, oh coeditor anónimo. ¿Ha considerado iniciar sesión? Esto hace que este tipo de debates colaborativos sean mucho más fáciles. Además, así no recibimos esas molestas firmas generadas por bots. -- Wtshymanski ( discusión ) 13:37 13 ago 2008 (UTC) [ responder ]
    No hay ejemplos, ni referencias, ni indicios de que haya leído ninguna de las referencias que he facilitado, pero sí una admirable creencia en la rectitud de su causa. ¿Qué debería intentar a continuación? Me está poniendo en un aprieto. —Comentario anterior sin firmar añadido por 150.101.166.15 ( discusión ) 08:41, 25 de agosto de 2008 (UTC)[ responder ]
    Debe tener al menos un bit de parada para distinguir entre el final de este carácter y el comienzo de uno nuevo. La única razón por la que se implementó más de un bit de parada fue para permitir que el receptor tuviera tiempo de procesar el carácter recién recibido y prepararse para el siguiente. Esto se debe en gran medida a razones históricas, cuando los chips procesaban los datos con bastante lentitud en comparación con la actualidad. Tenga en cuenta que la cantidad indeterminada de tiempo entre caracteres (ya que se trata de un sistema asincrónico) significa efectivamente que podría haber cientos de "bits de parada" antes del siguiente carácter, por lo que no podría haber ninguna razón importante para no enviar más bits de parada de los que espera el receptor, excepto una ligera ineficiencia. Por lo tanto, enviar dos bits de parada cuando el receptor espera uno no causaría problemas, a menos que considere que perder el tiempo empleado en enviar el bit adicional es un problema. Sin embargo, enviar un bit de parada cuando el receptor espera dos podría causar problemas importantes si (y solo si) el hardware realmente necesitara el tiempo adicional para procesar el carácter recién recibido. No creo que el UART genere un error de encuadre si no obtiene el segundo bit de parada, aunque no puedo encontrar ninguna referencia autorizada a mano. Para que verifique que obtuvo dos bits de parada, se frustraría el propósito de tener dos bits de parada en primer lugar: dar tiempo al UART para mover el carácter completado a su búfer y notificar al procesador que el carácter entrante había llegado. Si pudiera hacer todo eso y también verificar que obtuvo dos bits de parada, también podría requerir solo un bit de parada. Por lo que he visto, el error de encuadre se debe simplemente a que no tiene un 1 lógico en el punto en el que debería haber llegado el bit de parada (y no que verifique un segundo 1 lógico cuando debería haber llegado el segundo bit de parada). Dicho de otra manera, en el punto en el que debería estar verificando el valor del bit de parada, estaría a mitad de camino del bit de parada y, por lo tanto, tendría medio bit de tiempo para prepararse para el siguiente bit de inicio. Algo de eso podría verse afectado por ligeras diferencias de reloj entre el transmisor y el receptor. Por lo tanto, dependiendo de la velocidad de los chips en cuestión y de la tasa de bits, se pueden especificar dos bits de parada para obtener ese tiempo adicional. Zoewyr ( discusión ) 04:12 3 enero 2011 (UTC) [ responder ]
    "Sin embargo, enviar un bit de parada cuando el receptor espera dos podría causar problemas importantes si (y solo si) el hardware realmente necesitara el tiempo adicional para procesar el carácter recién recibido. No creo que el UART genere un error de tramado si no recibe el segundo bit de parada..." Si el UART está configurado para dos bits de parada y solo ve un bit de parada y luego el bit de inicio para el siguiente carácter, sí, algunos, según mi experiencia, generarán un error de tramado porque esto podría indicar ruido en la línea. Conecte un terminal serial a una computadora, configure el terminal para dos bits de parada y la computadora para uno, y envíe un flujo de datos... el terminal mostrará una serie de manchas blancas o lo que sea que sea su notación para "error de tramado". Según mi experiencia. Un enlace a un manual para un microcontrolador muy reciente que dice "el receptor ignora el segundo bit de parada" está bien, pero no prueba que esta sea una práctica universal. Jeh ( discusión ) 21:01, 15 de noviembre de 2016 (UTC) [ responder ]
    "Esto se debe en gran medida a razones históricas, cuando los chips procesaban los datos con mucha lentitud en comparación con la actualidad". Es muy dudoso. Incluso los UART construidos a partir de lógica aleatoria en los días anteriores a LSI, DTL y RTL no eran tan lentos. Pero las máquinas de teletipo de 110 bps necesitaban los tiempos de dos bits para permitir que el UART, que era electromecánico en dichas máquinas, junto con el resto del mecanismo tuvieran tiempo de volver a "cero". Intente enviarle a uno de esos un flujo constante con solo un bit de parada y obtendrá una impresión de basura. Jeh ( discusión ) 21:39 15 nov 2016 (UTC) [ responder ]
    Sí. Todos los UART electrónicos que conozco aceptan un bit de parada. Los UART mecánicos, como se ha indicado, necesitan dos para los que son como el ASR-33. Hay un dispositivo mecánico que gira una vez por carácter y tiene que detenerse y volver a empezar físicamente. También había algunos que usaban 1,5 bits de parada, como el IBM 2741. El 2741 usa un código de seis bits con desplazamiento/desplazamiento (que hace girar la bola de tipo 180 grados). Además, el 2741 bloquea el teclado al imprimir. La tecla ATTN, equivalente a BREAK en terminales ASCII, es lo único que se puede hacer mientras se recibe. Gah4 ( discusión ) 19:07 12 abr 2023 (UTC) [ responder ]

    ¿Qué?

    Se menciona el término "TAE", pero no se define en este artículo ni en otros artículos de Wikipedia (en un sentido relevante, en todo caso). Me encantaría corregir esto, pero no sé qué es TAE y ni la "definición" de Google ni el diccionario de acrónimos gratuitos tienen la respuesta :-( 22:07, 2 de septiembre de 2008 (UTC)

    También me llamó la atención. Tampoco pude encontrar ninguna otra referencia a TAE , así que revisé el historial de la página y fue el último cambio realizado. Revisé las contribuciones recientes del autor y todas son actos de vandalismo. Supongo que un vándalo obtuvo esa IP recientemente asignada (algunas contribuciones anteriores son legítimas). Revertí la edición. Si alguien puede dar una buena explicación de qué es TAE , simplemente vuelva a publicarla, por favor. 24.80.185.126 (discusión) 10:13 10 sep 2008 (UTC) [ responder ]

    Baudios frente a bits

    Los bits por segundo son la carga útil, no la velocidad de símbolos. 9600 baudios tienen 9600 símbolos por segundo. Por ejemplo, para un UART configurado en 8N1, se requiere 1 baudio de inicio, 8 baudios de datos, 1 baudio de parada, para un tiempo total de 10 baudios. Los bits por segundo son 9600 * (8/10) = 7680 bits por segundo. Si miras cualquier hoja de datos de UART, usan el término baudios en todas partes, como el generador de "velocidad de baudios". • Sbmeirow • Discusión • 09:26, 15 de noviembre de 2016 (UTC) https://en.wikibooks.org/wiki/Talk:Universal_asynchronous_receiver-transmitter/Serial_Programming/Complete_Wikibook#Data_Transmission_Rates [ responder ]

    Primero, gracias por iniciar la discusión junto con tu reversión.
    No consideramos que Wikilibros (ni la propia Wikipedia) sea un sitio de contenidos generados por los usuarios. Véase WP:USERG .
    "Los bits por segundo son 9600 * (8/10) = 7680 bits por segundo". Lo siento, pero eso es incorrecto. La relación entre la tasa de bits y la velocidad en baudios no se debe a los bits de inicio y fin de la trama, sino a la diferencia entre bits por segundo y símbolos por segundo.
    Sí, es cierto que en la transmisión serial asíncrona existe una diferencia entre los bits totales del canal (que incluyen los bits de inicio y de fin) y lo que llamas "bits de carga útil" (que no los incluyen). Pero los "baudios" no tienen nada que ver con eso. (Tampoco, en protocolos más complejos, tiene nada que ver con el encuadre de paquetes, las sumas de comprobación u otras diferencias entre la "carga útil" y los bits totales enviados o recibidos).
    Consulte nuestro artículo Baud . "El término baud se ha utilizado a veces incorrectamente para referirse a la velocidad de bits,[2] ..."
    Consulte también http://electronicdesign.com/communications/what-s-difference-between-bit-rate-and-baud-rate, de la revista EDN.
    "Cualquier hoja de datos UART" - ¿Qué pasa con [1], [2], [3], ... Si dicen "generador de velocidad en baudios", bueno, están equivocados. Cualquier buen libro sobre la teoría de las comunicaciones de datos lo explicará. La confusión de baudios con bit/s es un error muy antiguo y muy conocido. La unidad de información es el bit, no el baudio. Un baudio es una velocidad de símbolo de un símbolo por segundo . El baudio de un enlace está relacionado con su velocidad de transferencia de información (bit/s) pero no es necesariamente lo mismo. Tienes que saber los bits por símbolo para relacionar los dos. Un símbolo puede transmitir más de un bit, o menos de un bit, o exactamente un bit.
    Un UART no sabe nada sobre la tasa de símbolos que podría estar en uso más adelante, por lo que no tiene sentido hablar de "baud" en relación con un UART. Si la entrada y la salida serial del UART se utilizan directamente, entonces sí, un bit = un símbolo y, por lo tanto, la tasa de bits en bit/s = baudios. Pero aún así no hay razón para no usar "tasa de bits", "bit/s", etc. Una vez más, los UART tratan con bits. Cuando se programa un generador de tasa de bits para crear la señal de reloj para un UART, se configuran los bits por segundo en los pines seriales, lo que incluye los bits de inicio y de parada.
    Digamos que lo configuramos a 9600 bit/s. Ahora digamos que conectamos un módem asincrónico antiguo capaz de alcanzar 9600 bit/s (de nuevo, eso incluye bits de inicio y detención). Esos módems usaban un esquema de codificación que enviaba cuatro bits por símbolo. Por lo tanto, los 9600 bit/s se enviaban y recibían en la línea telefónica a 2400 baudios. Esa es la diferencia entre "velocidad de bits" y "baudios". Aún configuras el puerto serial en el DTE para 9600. Nuevamente, el UART no conoce la velocidad de símbolos. El UART solo conoce bits.
    Tenga en cuenta que la especificación de "baud" no distingue entre bits de inicio, de detención y de datos. Si son 2400 baudios (2400 símbolos/seg) y cada símbolo lleva cuatro bits, entonces la velocidad de bits es 9600 bit/seg. No importa para ninguna de las dos figuras que algunos de esos bits sean bits de inicio y de detención.
    Lenguaje y unidades: Es vital entender que una medida expresada en Baud es siempre una tasa , símbolos por segundo. No un simple número de cosas. Un baudio no es un bit, nunca. Un baudio ni siquiera es un símbolo. Un baudio = un símbolo por segundo . Por lo tanto, no deberíamos escribir "9600 baudios por segundo", solo escribimos "9600 baudios". Entonces, cuando escribiste "1 baudio de inicio", estabas escribiendo "1 símbolo por segundo de inicio", lo cual no tiene sentido. Si quieres expresar el tiempo, la duración, del bit de inicio, eso simplemente se expresa en segundos (probablemente fraccionarios), no en "símbolos por segundo": una duración no tiene un "por segundo" en ella. "Tiempo de 10 baudios" significaría "tiempo de 10 símbolos por segundo", es decir, la duración de, no 10 símbolos, sino de 10 cambios de símbolo por segundo. Lo cual nuevamente no tiene sentido si estás hablando de una duración, una medida de tiempo transcurrido. Puedes escribir "10 símbolos por segundo" (10 baudios), o puedes escribir "el tiempo que tardan 10 símbolos" (que sería 1 s en este caso), pero no "la duración de 10 símbolos por segundo". Una cantidad de símbolos por segundo es una tasa. No es algo que tenga una duración.
    En cuanto al encabezado de la columna de la tabla "tiempo por baudio", además del hecho de que "baudio" se refiere a símbolos y no a bits, ya que "baudio" significa "símbolos por segundo", "tiempo por baudio" en realidad está diciendo "tiempo por símbolo por segundo". Lo cual es como decir "tiempo por milla por hora". No tiene sentido. Por ejemplo, puedes decir "tiempo por milla" o "millas por tiempo" para el caso. Pero la única razón para decir "tiempo por milla por hora" sería si estuvieras hablando de algo como la aceleración. (Como "0 a 60 mph en 10 segundos", una aceleración - tasa de cambio de velocidad - de 10 millas por hora por segundo). Si estás midiendo una duración simple, no pones "por unidad de tiempo" después, pero eso es lo que implica "baudio". Si los datos en la columna expresan tiempo en segundos (o en microquincenas para el caso), "duración de bit" o "tiempo de bit" o "tiempo por bit" serían los encabezados correctos.
    Por último, consulte nuestro Manual de estilo en WP:COMPUNITS . Se nos exige que utilicemos bits/s para expresar las velocidades de transmisión de datos, no baudios. QED.
    El hecho es que incluso el término "velocidad en baudios", por muy común que sea, es incorrecto, al igual que sería incorrecto decir "velocidad en hercios". Una velocidad de símbolos expresada como un número con "baudios" después de que ya tiene "por segundo" en él, por ejemplo, "9600 baudios" ya es "9600 símbolos por segundo". "Velocidad en baudios" estaría hablando de la cantidad de símbolos por segundo por segundo, o algo así. No hablarías de la "velocidad" de un proyectil; la "velocidad" ya es una "velocidad" de desplazamiento en el tiempo. Tampoco hablas de la "velocidad en amperios" de una carga eléctrica, ya que el amperio ya tiene una "unidad de tiempo" incorporada; ya es una velocidad. Pero la "velocidad en baudios" (al igual que la igualmente errónea "velocidad de velocidad") es tan generalizada que probablemente sea inútil tratar de arreglarla. Sin embargo, podemos evitarla utilizando la más correcta "velocidad de bits". Jeh ( discusión ) 10:08 15 nov 2016 (UTC) [ responder ]
    RESPUESTA DE SBMEIROW

    A) En WP:COMPUNITS se dice que "la definición más relevante para el artículo debe elegirse como principal para ese artículo". Una gran mayoría de documentos recientes sobre UART muestran claramente que el término "baud" es un término muy relevante.

    B) Entiendo que se pueden agrupar varios bits en un "baud" o "unidad de tiempo" en módems de acceso telefónico y en una montaña de protocolos de comunicación inalámbrica, pero este artículo NO trata de ellos, sino que trata específicamente del UART . Lo único que importa en este artículo es el UART en sí y los datos seriales que llegan/salen del UART.

    C) Mi uso de "cualquier hoja de datos" significa hojas de datos RECIENTES para piezas RECIENTES. La selección de hojas de datos ANTIGUAS OBSOLETAS es importante desde un punto de vista histórico, pero se debe utilizar la nomenclatura técnica reciente para describir las cosas en 2016. Los siguientes 12 enlaces a documentos más nuevos de 12 empresas diferentes muestran claramente la prevalencia del uso del término BAUD con los UART. Además, estoy seguro de que podría publicar una montaña de hojas de datos similares, ya que casi todos los microcontroladores tienen un UART en su interior. Esta evidencia por sí sola es una razón muy sólida de por qué se debe utilizar la nomenclatura BAUD tanto como sea posible en este artículo de Wikipedia sobre UART en 2016.

    Chip UART
    Chip USB a UART
    Chip microcontrolador
    Bloques "blandos" de FPGA

    D) Firmado • Sbmeirow • Discusión • 01:50, 16 de noviembre de 2016 (UTC) [ responder ]

    a) En relación con COMPUNITS, la disposición que usted cita, "La definición más relevante para el artículo debe ser elegida como principal para ese artículo", se encuentra en una sección que se refiere únicamente a la elección de prefijos binarios o decimales. Por ejemplo, ¿Mb significa 1048576 bits o 1000000 bits? No es en ningún caso una licencia para elegir algo que no esté en la tabla precedente de "Unidades específicas". Lo sé; fui parte de la última gran discusión sobre prefijos IEC, por lo que sé muy bien de dónde proviene esa oración y a qué se refiere.
    b) "Lo único que importa en este artículo es el UART en sí y los datos seriales que llegan/salen del UART". ¡Exactamente! Y el UART no habla en símbolos, solo en bits, por lo que bit/s es correcto. El uso del término "baud" implica que puede estar ocurriendo algún otro mapeo de bits a símbolos. Además de los otros artículos ya vinculados, consulte nuestro artículo sobre Velocidad de símbolos .
    c) En cuanto a las hojas de datos, sí, la ignorancia está en todas partes. (¡Algunas personas con las que me he encontrado incluso creen que los bits de trama no cuentan para la tasa de bits del canal!) El hecho de que muchos escritores técnicos aparentemente nunca hayan tomado clases formales sobre teoría de la comunicación no significa que sea nuestro trabajo perpetuar su ignorancia. Observo que en realidad no discutes que "baud" significa "símbolos por segundo". Bueno, entonces no es sinónimo de "bits por segundo" y ciertamente no significa "bit" o "bits" como afirmaste.
    d) En particular, esta confusión entre velocidad y cantidad hace que el encabezado de la columna "tiempo por baudio" en la tabla sea absurdo. El encabezado correcto es tiempo por bit, o duración de bit. No se puede poner una medida de duración bajo un encabezado que diga "tiempo por baudio". Ni siquiera es incorrecto. Supongo que se podría escribir "tiempo por baudio•segundo", que termina siendo tiempo por símbolo, pero eso parece mucho trabajo. Es como escribir "amperios•segundos" en lugar de "culombios". Pero "tiempo por baudio•segundo" todavía no funcionaría para este artículo porque aquí no se habla de símbolos, solo de bits.
    e) ¿Está en desacuerdo con que bit/s sea un término técnicamente correcto, si no el término mejor respaldado por las hojas de datos que citó? ¿Está en desacuerdo con que "duración de bit" sea un encabezado de columna técnicamente correcto en la tabla?
    Por cierto, no tienes que escribir "firmado". Solo tienes que escribir las cuatro tildes. El formato distintivo de la firma resultante es suficiente. Jeh ( discusión ) 02:41 16 nov 2016 (UTC) [ responder ]
    He estado ocupado la mayor parte de los últimos 7 días. Los próximos 2 o 3 días estarán ocupados debido a las vacaciones. También estoy tratando de ponerme al día con las reseñas de artículos de Kansas. Me comunicaré contigo este fin de semana o antes, para que podamos avanzar con esto. • Sbmeirow • Discusión • 07:54, 23 de noviembre de 2016 (UTC) [ responder ]
    Yo tampoco estoy inactivo y WP:NODEADLINE . :) Jeh ( discusión ) 12:12 23 nov 2016 (UTC) [ responder ]
    En cuanto a mi cartel, si miras más de cerca, había una razón por la que incluí la palabra "firmado" en esta situación. Mi cartel tiene viñetas y la última línea de mi comentario comienza con una viñeta, por lo que hice algo para evitar que se mezclaran visualmente. • Sbmeirow • Discusión • 07:26, 3 de diciembre de 2016 (UTC) [ responder ]
    Convertí la parte superior de la tabla a "BIT", pero incluí "BAUD" entre paréntesis en la columna de la izquierda, ya que el término "baud" se usa ampliamente en la industria UART. • Sbmeirow • Discusión • 07:32, 3 de diciembre de 2016 (UTC) [ responder ]
    Sea correcto o no, el término "BAUD" se usa tan ampliamente en la industria de UART y microcontroladores que sería un desaire eliminarlo por completo de un artículo sobre UART. En muchas ciencias técnicas, el uso de algunos términos ha cambiado con el tiempo. Si comparas libros de hace 100 a 150 años con libros recientes de química y física, notarás que han cambiado numerosos términos. Incluso en electrónica, "condensador" fue reemplazado por "capacitador" a principios del siglo pasado. En el mundo de UART, el término "BAUD" está firmemente arraigado en 2016, por lo que no debería eliminarse por completo de este artículo. • Sbmeirow • Discusión • 07:50, 3 de diciembre de 2016 (UTC) [ responder ]

    Sección de modelos UART

    ¿Cuál es el propósito de la sección de modelos UART? Estoy seguro de que hay miles de chips diferentes que admiten UART y que no se muestran allí. Creo que esa sección debería eliminarse por completo. -- IngenieroLoco ( discusión ) 11:15 29 nov 2016 (UTC) [ responder ]

    Creo que se deberían representar algunas unidades históricas famosas o significativas, además de un par de chips que se usan comúnmente (bueno, "comúnmente" hasta que desaparecieron los puertos seriales) en las PC (por ejemplo, 8250 y 16550), al menos. Y se debería incluir alguna indicación de la diferencia entre estos (que son dispositivos direccionables que pueden ubicarse en un bus) y los chips antiguos. Por otro lado, estoy de acuerdo en que Wikipedia no debería ser una lista de piezas. Jeh ( discusión ) 11:32 29 nov 2016 (UTC) [ responder ]

    ¿Cuándo los microcontroladores absorbieron el UART?

    Marqué "Los UART ahora se incluyen comúnmente en los microcontroladores", ¡el artículo tiene 16 años! Sería bueno citar una referencia. La sección Historia no llega a cubrir este avance. -- Skierpage ( discusión ) 23:13 18 abr 2018 (UTC) [ responder ]

    No sé exactamente cuándo, pero Intel 8051 incluyó una interfaz serial tipo UART en 1980. 2400:4051:4CE0:C400:922B:34FF:FED6:A16D (discusión) 09:17 6 ago 2021 (UTC) [ responder ]

    Arte de Estados Unidos

    Tenga en cuenta que el 8251 es en realidad un USART, que puede funcionar en modo asincrónico o sincrónico. Creo que algunos de los otros que aparecen junto con él también son USART o similares. Gah4 ( discusión ) 01:46 13 abr 2023 (UTC) [ responder ]

    Protocolo vs. Dispositivo

    Trabajo con ingenieros eléctricos (yo no soy uno de ellos) y a menudo me recuerdan que "UART" es un protocolo de enlace de datos, no un dispositivo. Esto también se enfatiza en otras fuentes. Como ejemplo, el protocolo UART se puede utilizar con un transmisor/receptor LVDS, y también se puede utilizar con un módem acústico, como cualquiera que haya configurado un módem para bits de inicio, detención, paridad y datos puede saber. No creo que un módem acústico que funcione con la PSTN pueda considerarse un "dispositivo UART", al menos no como se utiliza en este artículo. ¿Debería este artículo enfatizar que UART es un protocolo, en lugar de dar por sentado que es un dispositivo? -- Alan.A.Mick 15:25, 22 de mayo de 2024 (UTC) [ responder ]

    También se podría argumentar que la palabra "UART" en algunos contextos se refiere al dispositivo y en otros contextos se refiere al protocolo. Por ejemplo, si alguien dice "transferir los datos a través de UART", entonces esa palabra "UART" se refiere al protocolo, mientras que si alguien dice "transferir los datos a través de UART", entonces esa palabra "UART" se referiría a un dispositivo o módulo que implementa el protocolo.
    En lo que respecta a este artículo, podría sugerir cambiar la sección denominada "Transmisión y recepción de datos en serie" para que sea simplemente "Protocolo UART". Em3rgent0rdr ( discusión ) 16:23 22 may 2024 (UTC) [ responder ]
    UART es un dispositivo de hardware, o un periférico dentro de un microcontrolador, o emulado por software; pero en el contexto de los protocolos solo significa que el protocolo usa algún tipo de UART para transmitir y recibir datos asincrónicos. • Sbmeirow • Discusión • 13:15, 23 de mayo de 2024 (UTC) [ responder ]