Deferred interrupt with STM32: release semaphore in the ISR handler or in the callback function?

I am wondering which of the two following implementation is better:

// Implementation A
void USART2_IRQHandler(void) {
  HAL_UART_IRQHandler(&huart2);

  // Signal the semaphore to notify the task of data reception
  BaseType_t xHigherPriorityTaskWoken = pdFALSE;
  xSemaphoreGiveFromISR(xSemaphoreUsart2Rx, &xHigherPriorityTaskWoken);
  portYIELD_FROM_ISR(xHigherPriorityTaskWoken);
}


// Implementation B
void USART2_IRQHandler(void) {
  HAL_UART_IRQHandler(&huart2);
}

void HAL_UART_RxCpltCallback(UART_HandleTypeDef *UartHandle) { /* Set transmission flag: transfer complete*/

  // Signal the semaphore to notify the task of data reception
  BaseType_t xHigherPriorityTaskWoken = pdFALSE;
  xSemaphoreGiveFromISR(xSemaphoreUsart2Rx, &xHigherPriorityTaskWoken);
  portYIELD_FROM_ISR(xHigherPriorityTaskWoken);
}

I would say implementation B because it releases a semaphore only upon a well defined event (“all data are received”), whereas in implementation A the semaphore is released for any event that trigger any UART interrupt, but due to my beginner level I am afraid that I could be missing something.

Like a few others on the forum, I do not like HALs, in particular not the ST HAL. It is poorly written with a number of design and implementation problems, its main purpose being to make migrating to other platforms than ST unattractive.

As long as it is guaranteed that your RxCplt callback is only called upon successful receive, your argument is legitimate, but you need to consider that the infrastructure to evaluate the receive and eventually dispatch to the callback is beyond your control and may eat up many useless CPU cycles.

The first implementation is of course incomplete, but if you leave out the HAL altogether and do the necessary pre processing yourself, you may end up with more efficient and easier to maintain code.

I think I can kinda confirm based on a small test I did right now, your claim. It certainly needs a deeper investigation, but observing the messages displayed on the serial port monitor I felt a certain sloppiness. Perhaps this is due to cone consumption of such “useless CPU cycles” that you mentioned. Or perhaps something unrelated - this is why I think it needs more investigation.