How to avoid the initial service delay for STM32 unit tests?

utkarshverma · July 30, 2024, 3:30am

I have recently started doing more of TDD for my firmware projects and I noticed the following line:

platformio/platformio-examples/blob/develop/unit-testing/stm32cube/test/test_led/test_main.c#L51


      
              TEST_ASSERT_EQUAL(HAL_GPIO_ReadPin(LED_GPIO_PORT, LED_PIN), GPIO_PIN_SET);
          }
          
          void test_led_state_low(void) {
              HAL_GPIO_WritePin(LED_GPIO_PORT, LED_PIN, GPIO_PIN_RESET);
              TEST_ASSERT_EQUAL(HAL_GPIO_ReadPin(LED_GPIO_PORT, LED_PIN), GPIO_PIN_RESET);
          }
          
          int main() {
              HAL_Init();
              HAL_Delay(2000);
              
              UNITY_BEGIN();
              RUN_TEST(test_led_builtin_pin_number);
              for (unsigned int i = 0; i < 5; i++)
              {
                  RUN_TEST(test_led_state_high);
                  HAL_Delay(500);
                  RUN_TEST(test_led_state_low);
                  HAL_Delay(500);
              }

What I don’t like about it is that each test requires at least 2 seconds to run, and it’s hardcoded. Since the host machine (my PC) can drive the UART however it wants. Why do we not use a hardware handshake where the host waits for the MCU to send an INIT_DONE message?

Please let me know how this could be accomplished.