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.