HC-SR04 con STM32 da valores inesperados

0

En un Arduino es fácil hacer que un sensor ultrasónico HC-SR04 funcione. Sin embargo, en mi STM32 (F103C8T6) obtengo valores extraños.

Supuse que lo conecté correctamente, ya que obtengo valores en el pin de activación. Verifiqué que el voltaje en el pin de 5V que va a VCC del HC-SR04 es de 4.87 V.

El siguiente programa que utilicé (solo las partes más importantes y con los comentarios generados eliminados):

// PA10 US1 Trigger
#define US1_Trigger_Port GPIOA
#define US1_Trigger_Pin  GPIO_PIN_10
// PA9 US1 Echo
#define US1_Echo_Port GPIOA
#define US1_Echo_Pin  GPIO_PIN_9

uint32_t us1_duration;
uint32_t us1_distance;

uint32_t raw_values[1024];
uint32_t n = 0;

Y para el bucle (parte predeterminada, generada automáticamente por CubeMX):

int main(void)
{
  HAL_Init();
  SystemClock_Config();
  MX_GPIO_Init();
  MX_SPI1_Init();
  MX_USART1_UART_Init();
  MX_NVIC_Init();

  while (1)
  {
    HAL_GPIO_WritePin(US1_Trigger_Port, US1_Trigger_Pin, SET);
    HAL_Delay(10);
    HAL_GPIO_WritePin(US1_Trigger_Port, US1_Trigger_Pin, RESET);

    uint8_t state;
    do
    {
      state = HAL_GPIO_ReadPin(US1_Echo_Port, US1_Echo_Pin);
    } while (state == RESET);
    uint32_t us1_start = HAL_GetTick();

    do
    {
      state = HAL_GPIO_ReadPin(US1_Echo_Port, US1_Echo_Pin);
    } while (state == SET);

    uint32_t us1_end = HAL_GetTick();
    us1_duration = us1_end - us1_start;

    us1_distance = (us1_duration / 2) / 29.1; // cm (?)
    raw_values[n] = us1_duration;

    n++;
    if (n == 1024)
    {
      break;
    }

    HAL_Delay(1000);
  }
}

Puse un punto de interrupción en la instrucción break para detener el programa para verificar los valores. Moví mi mano a una distancia de entre 10 y 20 cm (4-8 pulgadas) del sensor, pero los valores brutos que obtengo son:

Name : raw_values
Details:{195, 196, 1, 1, 196, 1, 4, 1, 1, 1, 197, 0 <repeats 1013 times>}
Default:0x20001070 <raw_values>
Decimal:536875120
Hex:0x20001070
Binary:100000000000000001000001110000
Octal:04000010160

Los valores sin procesar que espero se encuentren en un rango de 10 a 20 cm (al menos la mayoría de ellos), lo que resultaría de acuerdo con la hoja de datos en valores sin procesar de 10 * 58 a 20 * 58, que es de 580 a 1060. Especialmente no alrededor 0 y no todos los mismos valores en torno a un determinado valor (esta vez 200).

La información de la hoja de datos que utilicé se puede encontrar aquí: hoja de datos

Actualizar Lo comprobé con un analizador lógico y noté que las partes altas de las duraciones de eco son menores a 1 ms. No sé por qué todavía obtengo valores de 200 a veces, tal vez cuando no hay eco.

    
pregunta Michel Keijzers

1 respuesta

0

Descubrí que HAL_getTick devuelve milisegundos, y los ecos son menos de 1 ms (a veces).

Sin embargo, lo cambié solo contando las iteraciones de bucle y obtengo valores mucho mejores:

Name : raw_values
    Details:{118, 233, 797, 971, 268, 15, 290, 854, 455, 62, 258, 525, 867, 865, 866, 581, 576, 576, 587, 588, 581, 0 <repeats 1003 times>}

Los últimos 8 valores (excepto el 0) que obtuve cuando coloqué una caja de manera constante frente al sensor.

Creo que si calculo la duración exacta (en ms) de un bucle, debería estar bien y me olvido de la mala resolución de los ticks HAL. O debería usar un temporizador de hardware que comienzo y reviso.

    
respondido por el Michel Keijzers

Lea otras preguntas en las etiquetas