controlador de serie para 3.3 v uC completo en la parte posterior de la computadora

0

Estoy buscando un circuito integrado que pueda conectar un lpc17xx (microcontrolador) al puerto serie en la parte posterior de una computadora estándar. El lpc17xx tiene un controlador UART con 8 pines.
RXD
TXD
CTS
DCD
DSR
DTR
RI
RTS
Me gustaría usarlos todos. Me imagino que si NXP decidió implementar todos esos pines, no solo RX y TX, entonces deberían ser útiles ... ¿Alguien sabe por qué? ¿Control de flujo?

El microcontrolador funciona a 3.3 voltios voltios y no pude encontrar una pieza de tipo max232 que tenga 8 canales a 3.3 voltios.

Supongo que podría usar RX y TX si realmente no hay diferencia, pero si nada más, mi circuito podría parecer más fresco con más cables: P

gracias.

EDITAR: ¿Se les llama controladores o transceptores?

    
pregunta Chris H

4 respuestas

1

Si desea usar las ocho señales, puede usar MAX3243E. Es bastante similar a MAX232 pero le brinda 5 receptores (CD, RXD, DSR, CTS, RI) y 3 controladores (TXD, DTR, RTS).

  • RXD y TXD son datos.
  • DSR, CTS, DTR y RTS son para control de flujo.
  • CD y RI son solo indicadores y, en general, casi nunca se usan (a excepción de los módems).
respondido por el Josip Medved
1

Para el control de flujo de hardware solo necesita 4 señales: datos enviados, datos recibidos, control de envío y control de recepción.

Como hay 2 tipos diferentes de control de flujo de hardware, parece que NXP ha decidido ser flexible y cubrirlos a ambos. Depende de usted que decida implementar:

  • DSR / DTR - Conjunto de datos listo / Terminal de datos listo
  • CTS / RTS: Borrar para enviar / Solicitar para enviar

También, hay otras conexiones de señalización para generar alertas en cualquiera de los extremos:

  • RI - Indicador de timbre: utilizado por los módems para indicar la presencia de un tono de timbre
  • DCD - Detector de datos detectado - utilizado por los módems para indicar la presencia de un soporte de datos - es decir, está conectado al extremo remoto.

Por lo tanto, puede hacer el handshaking de hardware con solo RXD / TXD y CTS / RTS o DTR / DSR, no necesita implementar ambos. Los demás solo son de interés si se está conectando a un módem (o quizás emulando un módem, no sé la dirección de esas señales en ese chip).

    
respondido por el Majenko
1

Los datos se transfieren a través de RXD (recibir) y TXD (transmitir). RTS (solicitud de envío) y CTS (borrado para enviar) se utilizan para el control de flujo de "hardware" opcional. No estoy de acuerdo con Majenko en que DSR / DTR no se usan para el control de flujo. Al igual que las otras líneas restantes, éstas se usaron para módems externos pasados de moda. Las líneas adicionales le dirían a la computadora cuando el teléfono estaba encendido / apagado, si estaba sonando, si el módem tenía "operador", etc. Básicamente ignore todas esas líneas.

RTS / CTS puede ser útil para el control de flujo, pero tenga en cuenta que otros dispositivos solo los implementan de forma remota. Se puede hacer que las PC los usen si el software configura el puerto de esa manera . A menos que el programa que desea comunicar específicamente diga que usa RTS / CTS o "handshaking de hardware", debe asumir que no lo hace. Eso significa que envía caracteres cada vez que se siente.

Otro problema a tener en cuenta con el protocolo de enlace de hardware es que solo porque le dices a una PC que deje de enviar, aún puede enviar hasta 16 caracteres antes de que realmente se detenga. Algunas implementaciones solo hacen que el controlador deje de enviar caracteres al hardware de UART, que tiene un búfer de 16 bytes que continuará vaciando. Cuando se habla con otra PC, esto no es un problema ya que el otro lado tendrá mucho más que un búfer de entrada de 16 bytes. Si estás en un micro pequeño, debes asegurarte de que puedes tolerarlo.

En el caso general, lo que hago es suponer que solo tengo un flujo de bytes bidireccional sin ninguna señalización fuera de banda como RTS / CTS. Si necesito asegurarme de que el micro no se supere, lo incorporo al protocolo. Por ejemplo, es posible que al host no se le permita enviar un nuevo comando hasta que se reciba algún ACK para el anterior. Muchos esquemas son posibles.

Suponiendo que el único canal con el dispositivo remoto es un flujo de bytes bidireccional, permite una conexión más fácil a otras conexiones subyacentes. Una versión futura de su producto podría entonces usar TCP o USB o alguna otra cosa para comunicarse solo con las capas inferiores del software y el firmware que necesite cambiar. Un flujo bidireccional de bytes es el protocolo común más bajo con el que se puede contar casi cualquier enlace para admitirlo. Eso es lo que TCP hace de forma nativa, por ejemplo. Con USB, puede reservar un punto final a granel en las direcciones de entrada y salida, y eso es lo que tiene.

    
respondido por el Olin Lathrop
0

No necesitas 8 pines, como parece que sabes. Pero si debe hacerlo, ¿qué hay de malo en comprar 2 x 4 canales IC.s?

También, fwiw, ya que son relevantes para la dirección, necesitas N de algunos y 8-N de los demás.

RS232 a uC está suficientemente bien servido por NPN bipolar, Resistor 10k tal vez desde el colector a Vdd o lo que sea, Rin desde la señal a la base. 100k base a tierra.

Si tiene V- para RS232, cuelgue el emisor pnp de V +. Colector R a -12 o lo que sea. Conduzca la base desde el controlador. Base a V + 100k. QED.

Si necesita -V, puede usar un dispositivo de tipo MAX232 para proporcionarlo.

    
respondido por el Russell McMahon

Lea otras preguntas en las etiquetas