La interrupción de USART no funciona como se esperaba [STM32 Nucleo]

¿Alguien podría explicar por qué solo puedo recibir 13 caracteres con la interrupción de USART? Uso '\n' para detectar el final de la cadena.ingrese la descripción de la imagen aquí

#define BUFFER_SIZE 100

char receive_buffer[BUFFER_SIZE];
char receive_data;
int receive_index = NULL;
int data_ready_index = NULL;

void USART2_receive(void const * argument){
         for(;;){
                if(data_ready_index == 1){
                HAL_UART_Transmit_IT(&huart2, (uint8_t *)"Received data: ", strlen("Received data: "));
                HAL_Delay(50);
                HAL_UART_Transmit_IT(&huart2, (uint8_t *)receive_buffer, strlen(receive_buffer));
                memset(receive_buffer, NULL, sizeof(receive_buffer));
                HAL_Delay(50);
                HAL_UART_Transmit_IT(&huart2, (uint8_t *)"\r\n", strlen("\r\n"));
                data_ready_index = NULL;
                }
         }
     }

    void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) {

        if (huart->Instance == USART2){
            if (receive_data != 13){
                receive_buffer[receive_index++]=receive_data;
            }else{
                    receive_index = NULL;
                    data_ready_index = 1;                                                               
                    // Received data ready to be processed
            }
      }
    }

    void USART2_IRQHandler(void){

      HAL_UART_IRQHandler(&huart2);
      HAL_UART_Receive_IT(&huart2, (uint8_t *) &receive_data, 1);
    }
¿Qué sucede cuando lo envía sin el CR o en trozos más pequeños?
Es gracioso que digas que verificas \npero tu código está verificando \rcuál es 13 y solo procesas 13 bytes, pero entonces, ¿por qué está strlendando más de 13 y envía algunos 0x00 bytes con ellos (<0>)? El mensaje que recibes es la longitud del mensaje transmitido, solo el contenido de los últimos 3 bytes es incorrecto.
@Trevor_G si envío fragmentos más pequeños (menos de 14) está bien, todo funciona bien. Y si envío sin CR no aparece en absoluto.
Sí, quise decir si envías 12345678 y luego envías 12345678 + CR, ¿qué obtienes de vuelta?
@Trevor_G esto es lo que obtuve: Datos recibidos: 1<0><0><0><0><0><0><0><0><0><0><0><0><0> <0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0 ><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0>< 0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0> <0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0 ><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0 16:06:36.636> >231231231231231231234567812345678
hazlo de nuevo... (o dos veces) obtienes lo mismo
Después de enviar 1 vez sin CR y 1 vez con CR. Repetido dos veces. 16:12:57.286> Datos recibidos: 1234567812345<0><0><0> 16:13:00.722> Datos recibidos: 1234567812345<0><0><0
YA Creo que la primera porquería es porque no inicializas el búfer... Pero también creo que estás recibiendo los datos en el lugar equivocado. Consulte esta publicación cruzada electronics.stackexchange.com/a/266976/139766
¿Qué sucede si intenta enviar "abcdefghijklmno"?
@Trevor_G STM32 CubeMX no genera la función void HAL_UART_MspInit(UART_HandleTypeDef* huart) , así que tal vez no sea necesario. @MITU RAJ Si envío "abcdefghijklmno", obtengo abcdefghijklm<0><0>
¿Puedes reducir la velocidad en baudios y comprobar de nuevo?
@MITURAJ Reduje la velocidad en baudios a 9600 y luego envío la misma cadena y obtengo ab<0><0><0><0><0><0><0><0><0><0><0 ><0><0> . Entonces, ¿tal vez sea un problema con la velocidad en baudios?
¿Cambió tanto su stm32 como la velocidad de transmisión del terminal a 9600?
Sí, ambos son 9600.
Si hubiera funcionado a 9600, podríamos haber concluido que el problema era la alta tasa de baudios.
Buena captura... es exactamente por eso que las cosas empeoraron a una velocidad de transmisión más lenta, se produjo un desbordamiento en el rxbuffer en el lado de la PC.
Supongo que ahora puede escribir la respuesta a su propia pregunta.
Esta no es la primera vez que los retrasos lo estropean todo.

Respuestas (2)

Encontré el problema. En la función void USART2_receive (void const * argument) aumenté el retraso de 50 a 100 y luego todo funciona bien. Como mencionó @MITURAJ, esto puede deberse a un desbordamiento del búfer.

void USART2_receive(void const * argument){
    for(;;){
        if(data_ready_index == 1){
            HAL_UART_Transmit_IT(&huart2, (uint8_t *)"Received data: ", 
            strlen("Received data: "));
            HAL_Delay(100);
            HAL_UART_Transmit_IT(&huart2, (uint8_t *)receive_buffer, 
            strlen(receive_buffer));
            HAL_Delay(100);
            HAL_UART_Transmit_IT(&huart2, (uint8_t *)"\r\n", strlen("\r\n"));
            data_ready_index = NULL;
            memset(receive_buffer, NULL, sizeof(receive_buffer));
        }
    }
}
¿Cuál es el propósito de la demora y por qué su aumento solucionó el problema?
Simplemente no sé cómo marcar el comentario de alguien como respuesta útil.

Descubrir que necesita un retraso más prolongado debería indicarle que no está esperando a que finalice el Tx. HAL_UART_Transmit_IT usa una interrupción para enviar bytes (no es bloqueante). Básicamente, le está diciendo que transmita, espere un poco y vuelva a meter datos en el búfer antes de que finalice la transmisión.

En su lugar, le sugiero que supervise la devolución de llamada a HAL_UART_TxCpltCallback y, una vez que eso suceda, establezca algún indicador. En su función USART2_receive, espere a que se establezca la bandera antes de pedirle que envíe cosas nuevamente. Recuerde borrar la bandera antes de esperar a que se establezca nuevamente :)

Gracias por la explicación detallada, fue bastante difícil implementar estos cambios ya que soy un desarrollador junior. ¿Tal vez hay algún ejemplo que podría seguir para esta característica?
@Into_Embedded, es bastante sencillo, es como la función HAL_UART_RxCpltCallback. El CubeMx probablemente genera la función TxCpltCallback para usted y solo tiene que completarla. Eche un vistazo a los ejemplos de STM32 también, debería haber algo allí para UART sin bloqueo.
Definitivamente investigaré ahora que no se ve tan enseñado como se veía al principio.
La interrupción de USART no funciona como se esperaba [STM32 Nucleo]
RespuestasAquíPolítica de privacidad1y, 1v