Cómo implementar un protocolo de comunicación UART [cerrado]

Navega tus respuestas
2

Tengo dos tablas:
Board M: Master board
Junta S: Junta de esclavos
Estoy intentando implementar un protocolo de comunicación UART (longitud de datos = 8 bits) entre ellos. La tarjeta maestra M enviará las solicitudes a la tarjeta esclava S y esta última responderá.

Ejemplo 1:
Tablero M (Tx) - > GET_VALUE - > (Rx) S tablero
S board (Tx) - > 150 - > (Rx) M board

Ejemplo 2:
Tablero M (Tx) - > GET_STATUS - > (Rx) S tablero
S board (Tx) - > I_AM_READY - > (Rx) M board

Ejemplo 3:
Tablero M (Tx) - > GET_STATUS - > (Rx) S tablero
S board (Tx) - > I_AM_BUSY - > (Rx) M board

Tengo algunas preguntas:
1. ¿Es una buena opción usar un búfer de anillo FIFO en UART ISR?
2. ¿Cómo elegir el número de bytes intercambiados entre los dos tableros? 3. ¿Cómo elegir el tamaño del búfer?
4. ¿Qué modo es mejor para este tipo de comunicación? Half dúplex o dúplex completo?
5. ¿Qué tipo de datos debo usar? Debo definir algunas macros como esta: 

#define GET_VALUE  0x01
#define GET_STATUS 0x02

o simplemente uso esta implementación: 

#define BUFFER_LENGTH = x;
uint8_t buffer[BUFFER_LENGTH] = "GET_VALUE\n";
    
pregunta Pryda

2 respuestas

2
  1. Parece bueno, solo asegúrate de comprobar si hay un búfer lleno (significa que perderás bytes). O tiene que evitar enviar más.
  2. Esto depende de cuánta sea la diferencia entre recibirlos y manejarlos. Si puede haber alguna diferencia, necesitas un búfer más grande. Si puede asegurarse de que procesa los bytes entrantes casi de inmediato, el búfer puede ser pequeño.
  3. Debe ser el tamaño máximo (o razonable) de datos que desea almacenar antes de poder procesarlos. O para evitar que el remitente envíe más.
  4. No tengo experiencia con esto.
  5. Definitivamente el primero, en lugar de tener que enviar varios bytes, solo envía un byte, y no tiene que verificar el final de un comando, solo cada valor (0x00, 0x01) es un solo comando. Solo envíe mensajes de texto a través de canales de comunicación si realmente necesita el texto; de lo contrario, decodifíquelo a un número único. Haría lo mismo por el valor de retorno, por ejemplo, Estoy listo es 0x00 y estoy ocupado ix 0x01.
respondido por el Michel Keijzers
2
  1. Sí, absolutamente. De hecho, use dos buffers de anillo, uno para los bytes recibidos y otro para los bytes que se transmitirán.
  2. Debe definir un protocolo que especifique la cantidad de bytes que contiene cada mensaje. El propósito del protocolo es que ambas partes puedan programarse para reconocer e interpretar los mensajes correctamente. El número de bytes no debe ser menor de lo necesario. El número de bytes dependerá de si elige un protocolo binario o ASCII. Por ejemplo, si el rango de VALUE es +/- 2 ^ 15, entonces podría enviar ese mensaje con solo dos bytes en un protocolo binario, pero un protocolo ASCII podría requerir hasta siete bytes ("-32768 \ n"). Para los protocolos binarios, debe definir el orden de los bytes (endianness) de los valores de múltiples bytes.
  3. El tamaño del búfer debe ser al menos lo suficientemente grande como para contener el mensaje más grande. Pero ¿por qué no hacerlo mucho más grande? Probablemente tengas un montón de RAM que no vas a usar. Si el tamaño del búfer es una potencia de dos, entonces puede restablecer los punteros del búfer más rápidamente con una operación de máscara bit a bit (en lugar de operaciones de comparación y configuración). Así que haz tu búfer de 64, 128 o 256 bytes.
  4. El protocolo maestro / esclavo que describiste es semidúplex: solo un dispositivo está transmitiendo en un momento dado. ¿Por qué consideraría dúplex completo? Si te dijera que debes usar dúplex completo, ¿qué harías de manera diferente?

  5. Si desea que el protocolo sea legible para las personas, utilice un protocolo ASCII. Es posible que desee que sea legible para los humanos para que pueda participar fácilmente desde una aplicación de terminal o verlo en un monitor / snooper de puerto serie. O tal vez vas a publicar el protocolo y quieres que sea fácil de entender para el público. Pero un protocolo binario será más fácil de programar. Entonces, si la legibilidad humana no es importante, utilice un protocolo binario.

  6. Lo que aún no has considerado es el manejo de errores. ¿Cuáles son las posibilidades de que un byte se caiga o se corrompa por el ruido en el cable? ¿Cómo reconocerán y manejarán sus programas un error de protocolo? Si el manejo de errores es importante, entonces debería considerar el enmarcado de mensajes. Los delimitadores de cuadros permiten que sus programas reconozcan cuándo comienza o termina un mensaje. Y una secuencia de verificación de cuadros le permite a sus programas verificar que el mensaje se recibió correctamente.

respondido por el kkrambo

Lea otras preguntas en las etiquetas

¿Cómo mostrar señales de alta frecuencia en una pantalla pequeña? ¿Cuáles son las posibilidades de que un interruptor BJT se dañe si un capacitor se descarga a tierra?